徹底した事後分析を行う

Google Cloud Well-Architected Framework の信頼性の柱におけるこの原則では、障害やインシデントの後に効果的な事後分析を実施するうえで役に立つ推奨事項が示されています。

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

原則の概要

事後調査はインシデントに関する書面の記録で、インシデントの影響、インシデントの緩和または解決のためにとったアクション、根本原因、インシデント再発防止のためのフォローアップ アクションが記載されます。事後検証の目的は、ミスから学び、責任を追及しないことです。

次の図は、事後分析のワークフローを示しています。

事後分析のワークフローには、次の手順が含まれます。

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

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

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

推奨事項

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

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

責任転嫁のない事後分析を実施する

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

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

• 責任を追及するフィードバック: 「複雑なバックエンド システム全体を書き直す必要があります。この 3 四半期は毎週のように壊れており、その都度修正するのにうんざりしている人もいるでしょう。もう一度ページングされたら、自分で書き直すぞ…」
• 非難のないフィードバック: 「バックエンド システム全体を書き直すアクション アイテムは、これらのページが引き続き発生するのを防ぐ可能性があります。このバージョンのメンテナンス マニュアルは非常に長く、完全にトレーニングを受けるのは非常に困難です。将来のオンコール エンジニアは、きっと私たちに感謝してくれるでしょう。」

事後分析レポートを対象読者全員が読めるようにする

レポートに含める予定の各情報について、その情報が何が起こったかを理解するうえで重要かつ必要であるかどうかを評価します。補足データと説明はレポートの付録に移動できます。追加の情報が必要な審査担当者は、その情報をリクエストできます。

複雑なソリューションや過剰なエンジニアリングは避ける

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

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

問題を未解決のままにしないために、事後分析の結果を幅広いユーザーに公開し、経営陣のサポートを得ます。事後検証の価値は、事後検証後に得られる学びの量に比例します。より多くの人がインシデントから学ぶことで、同様の障害が再発する可能性が低くなります。