キャリアの初期、私は雰囲気でデバッグしていました。何かが壊れ、コードを凝視し、何かを変更し、再デプロイし、祈る。うまくいくこともありました。多くの場合、事態は悪化しました。
人々が依存するシステムを構築している場合、推測に頼る余裕はありません。私は体系的なデバッグのためのフレームワークを開発しました。華やかではありませんが、毎回機能します。
フレームワーク：ISOLATE
I — 症状を特定する（原因ではない） S — 影響範囲を特定する O — データを観察する（ログ、メトリクス、トレース） L — 仮説を列挙する（最低3つ） A — 各仮説を証拠に基づいて評価する T — 修正を隔離された環境でテストする E — 何が起こったのか説明する（ポストモーテム）
実際の例を見ていきましょう。
実例：ダッシュボードの読み込みに30秒
I — 症状を特定する。 ユーザーから品質ダッシュボードの読み込みに30秒以上かかると報告があります。ローカルでは2秒で読み込まれます。本番環境のみ。
「データベースの問題だ」「ネットワークの問題だ」とまだ飛びつかないでください。ただ、目に見えるものを説明するだけです。
S — 影響範囲を特定する。 全ユーザーか特定のユーザーか？すべてのブラウザか？いつから始まったか？デプロイと相関関係があるか？
このケース：全ユーザー、3日前から開始、その期間にデプロイなし。これにより「壊れたコードをリリースした」という原因は除外されます。
O — データを観察する。
\\
