Well-Architected Framework の信頼性の柱におけるこの原則では、障害やインシデントの後に効果的な事後検証を実施するうえで役に立つ推奨事項が示されています。Google Cloud
この原則は、信頼性の学習 の重点分野 に関連しています。
原則の概要
事後検証はインシデントに関する書面の記録で、インシデントの影響、インシデントを軽減または解決するためにとったアクション、根本原因、インシデント再発防止のためのフォローアップ アクションが記載されます。事後検証の目的は、過失を責めるのではなく、間違いから学ぶことです。
次の図に、事後検証のワークフローを示します。
事後検証のワークフローには次のステップが含まれます。
- 事後検証を作成する
- 事実を把握する
- 根本原因を特定して分析する
- 将来を見据えて計画を立てる
- 計画を実行する
次のような重大なイベントと重大でないイベントの後に事後検証分析を実施します。
- ユーザーに見えるダウンタイムやパフォーマンスの低下が一定のしきい値を超えた。
- いずれかの種類のデータが失われた。
- オンコール エンジニアの介入（リリースのロールバック、トラフィックの再ルーティングなど）。
- 解決にかかる時間が定義されたしきい値を超えた。
- モニタリングの失敗（通常、これはインシデントが手動で発見されたことを意味する）。
推奨事項
インシデントが発生する前に事後検証の基準を定義して、事後検証が必要なタイミングを全員が把握できるようにします。
効果的な事後検証を実施するには、次のサブセクションの推奨事項を検討してください。
過失を責めない事後検証を実施する
効果的な事後検証では、プロセス、ツール、テクノロジーに焦点を当て、個人やチームを責めません。事後検証分析の目的は、有罪者を特定することではなく、テクノロジーと将来を改善することです。誰でも間違いを犯します。目標は、間違いを分析してそこから学ぶことです。
次の例は、過失を責めるフィードバックと過失を責めないフィードバックの違いを示しています。
- 過失を責めるフィードバック: "複雑なバックエンド システム全体を書き換える必要があります。過去 3 四半期にわたって毎週のように障害が発生しており、断片的に修正することにうんざりしています。 もう一度ページングされたら、自分で書き換えます…」
- 過失を責めないフィードバック: "バックエンド システム全体を書き換えるアクション アイテムは、これらのページが引き続き発生するのを防ぐ可能性があります。このバージョンのメンテナンス マニュアルは非常に長く、完全にトレーニングを受けるのは非常に困難です。将来のオンコール エンジニアは私たちに感謝するでしょう。」
事後検証レポートを対象者全員が読めるようにする
レポートに含める予定の各情報について、その情報が、対象者が事象を理解するうえで重要かつ必要であるかどうかを評価します。補足データと説明は、レポートの付録に移動できます。詳細情報が必要なレビュー担当者は、リクエストできます。
複雑なソリューションや過剰なエンジニアリングは避ける
問題の解決策を検討する前に、問題の重要度と再発の可能性を評価します。二度と発生する可能性のない問題を解決するためにシステムに複雑さを加えると、不安定さが増す可能性があります。
事後検証を可能な限り広く共有する
問題が未解決のままにならないように、事後検証の結果を幅広い対象者に公開し、経営陣のサポートを得ます。事後検証の価値は、事後検証後に発生する学習に比例します。 インシデントから学ぶ人が増えるほど、同様の障害が再発する可能性は低くなります。