第40章: 根本原因

インシデントが軽減された後、最も重要な作業が始まります：なぜ起きたのかを理解することです。根本原因分析は、何が壊れたかを特定するだけでなく、障害が発生することを許した深いシステム的条件を理解することです。サーバーのディスク容量が不足したことは直接的な原因です。根本原因はキャパシティアラートが存在しなかったこと、または新しいサービスにログローテーションが設定されていなかったことかもしれません。

「5つのなぜ」技法はシンプルですが効果的な方法です：なぜ障害が発生したかを問い、なぜその条件が存在したかを問い、システム的な原因に到達するまで繰り返します。答えが単一の根本原因であることは稀です。ほとんどのインシデントには複数の寄与要因——潜在的なバグ、設定のギャップ、モニタリングの盲点——が重なって障害を生み出しています。すべての寄与要因を特定することは、1つの「根本原因」を特定して責任を問うことよりも価値があります。

責任追及は学習の敵です。エンジニアがミスに対する罰を恐れると、情報を隠し、組織は障害から学ぶ能力を失います。責任を問わないポストインシデントレビューは、個人ではなくシステムに焦点を当てます。「誰がこれを引き起こしたか？」ではなく「どのような条件がこれを許したか、そしてシステムをどう変えれば二度と起きないようにできるか？」が問いです。

調査結果の文書化は不可欠です。よく書かれたポストインシデントレビューは、タイムライン、寄与要因、影響、是正措置を記録します。これらの文書は組織の機関記憶の一部となり、将来のエンジニアが過去のインシデントを直接経験することなく学べるようにします。