徹底した事後分析を行う

Last reviewed 2024-12-30 UTC

Google Cloud Well-Architected Framework の信頼性の柱にあるこの原則では、障害やインシデントの後に効果的なポストモーテムを実施するための推奨事項が示されています。

この原則は、信頼性の学習の重点分野に関連しています。

原則の概要

事後調査は、インシデント、その影響、インシデントの軽減または解決のためにとったアクション、根本原因、インシデントの再発を防ぐためのフォローアップ アクションに関する書面の記録です。事後分析の目的は、過失から学ぶことであり、責任を割り当てることではありません。

次の図は、ポストモーテムのワークフローを示しています。

ポストモーテムのワークフローには、次のステップが含まれます。

• 事後調査を作成する
• 事実を把握する
• 根本原因を特定して分析する
• 将来を見据えて計画を立てる
• 計画を実行する

次のような重大なイベントや重大でないイベントの後に、事後分析を行います。

• ユーザーに見えるダウンタイムやパフォーマンスの低下が一定のしきい値を超えた。
• あらゆる種類のデータ損失。
• オンコール エンジニアによる介入（リリースのロールバック、トラフィックの再ルーティングなど）。
• 定義されたしきい値を超える解決時間。
• モニタリングの失敗（通常、これはインシデントが手動で発見されたことを意味する）

推奨事項

インシデントが発生する前に事後調査の条件を定義して、事後調査が必要なタイミングを全員が把握できるようにします。

効果的な事後検証を行うには、次のサブセクションの推奨事項を検討してください。

責任転嫁のない事後分析を行う

効果的なポストモーテムは、プロセス、ツール、テクノロジーに焦点を当て、個人やチームに責任を負わせません。事後分析の目的は、誰が悪いかを見つけることではなく、技術と将来を改善することです。誰にでも間違いはあります。目標は、間違いを分析してそこから学ぶことです。

次の例は、責任を割り当てるフィードバックと責任を割り当てないフィードバックの違いを示しています。

• 責任を帰属させるフィードバック: 「複雑なバックエンド システム全体を書き換える必要があります。この問題は過去 3 四半期にわたって毎週発生しており、断片的に修正することに疲れていることでしょう。本当に、あと 1 回呼び出されたら自分で書き直しますよ...」
• 非難のないフィードバック: 「バックエンド システム全体を書き換えるアクション アイテムは、実際にはこれらのページの発生を防ぐことができます。このバージョンのメンテナンス マニュアルは非常に長く、完全にトレーニングするのは非常に困難です。今後オンコール エンジニアが感謝してくれるはずです。」

対象とするすべてのユーザーがポストモーテム レポートを読めるようにする

レポートに含める予定の情報について、その情報が重要で、視聴者が状況を把握するために必要かどうかを評価します。補足データと説明は、レポートの付録に移動できます。審査担当者が追加情報を必要とした場合、リクエストできます。

複雑なソリューションや過剰に設計されたソリューションは避ける

問題の解決策を検討する前に、問題の重要性と再発の可能性を評価します。再発する可能性の低い問題を解決するためにシステムの複雑さを増やすと、不安定性が高まる可能性があります。

事後調査を可能な限り広く共有する

問題が解決しないようにするには、ポストモーテムの結果を幅広いユーザーに公開し、経営陣からサポートを得てください。事後検証の価値は、事後検証後に得られる学習に比例します。より多くの人がインシデントから学ぶことで、同様の障害が再発する可能性を低減できます。