インシデントの事後分析テンプレート

明確なドキュメントは、効果的なインシデントの事後分析プロセスの鍵です。多くのチームは包括的なテンプレートを使用して、各事後分析レビューで一貫した詳細を収集します。

以下に示すのは、Incident Handbook に概説されている事後分析に基づくインシデントの事後分析テンプレートの例です。これを切り取って貼り付けることで、自分の事後分析を文書化できます。

インシデントの概要

インシデントを数行に要約する。起こったこと、それが起こった理由、インシデントの重大度、影響が続いた期間を含めます。

例：

{DATE} の {time range of incident, e.g. 15:45 and 16:35} の時間範囲に、{NUMBER} 人のユーザーが {EVENT SYMPTOMS} に遭遇しました。

このイベントは {TIME OF CHANGE THAT CAUSED THE EVENT} に {CHANGE} によってトリガーされました。

{CHANGE} には {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system} が含まれていました。

このコードのバグが原因で {DESCRIPTION OF THE PROBLEM} が発生しました。

このイベントは {MONITORING SYSTEM} によって検出されました。チームは {RESOLUTION ACTIONS TAKEN} によってイベントへの対応を開始しました。

この {SEVERITY LEVEL} のインシデントは {X%} のユーザーに影響を及ぼしました。

起票された {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS} に記載のとおり、このインシデントに関連してさらに影響がありました。

きっかけ

インシデントを引き起こした状況を説明します。例: 以前の変更で発生したバグが検出されていなかった。

例：

{MM/DD/YY} の {16:00} ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}) に、{THE CHANGES THAT LED TO THE INCIDENT} する変更が {PRODUCT OR SERVICE} に導入されました。

この変更により {DESCRIPTION OF THE IMPACT OF THE CHANGE} が発生しました。

不具合

実行された変更が、どのように想定外の結果になったのかを説明します。可能な場合は、障害を示す関連データ可視化のスクリーンショットを添付します。

例：

{NUMBER} 件の応答が {XX%} のリクエストに誤送信されました。これは {TIME PERIOD} の間続きました。

影響

インシデントが内外のユーザーに与えた影響を説明して、提出されたサポート ケースの数を含めます。

例：

{MM/DD/YY} の {XX:XX UTC and XX:XX UTC} の間、{XXhrs XX minutes} にわたって、ユーザーがインシデント {SUMMARY OF INCIDENT} を経験しました。

このインシデントは、{XX} 人の顧客 ({SYSTEM OR SERVICE} ユーザーの X%) に影響を及ぼし、これらのユーザーは {DESCRIPTION OF SYMPTOMS} を経験しました。

{XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS} が送信されました。

検出

チームがインシデントを検出したのはいつですか? 彼らはそれが起こっていることを、どうやって知りましたか? 検出までの時間を、どのように短縮できますか? 検討事項: そうすれば、その時間を半分に短縮できましたか?

例：

{ALERT TYPE} がトリガーされたときにこのインシデントが検出され、{TEAM/PERSON} が呼び出されました。

その後、{FIRST PERSON} はディスクへのサービス書き込みの担当でなかったため、{SECONDARY PERSON} が呼び出されました。このため対応が {XX MINUTES/HOURS} 遅れました。

{EXPECTED IMPROVEMENT} を実現できるよう、{DESCRIBE THE IMPROVEMENT} が {TEAM OWNER OF THE IMPROVEMENT} によって準備されます。

回答

そのインシデントに対応したのは誰ですか? 彼らはいつ対応しましたか? 彼らは何をしましたか? 対応の遅延や障害をメモします。

例：

{XX:XX UTC} に呼び出しを受信した後、{XX:XX UTC} に {ON-CALL ENGINEER} が {SYSTEM WHERE INCIDENT INFO IS CAPTURED} でオンラインになりました。

このエンジニアは {AFFECTED SYSTEM} の対応経験がなかったため、{XX:XX UTC} に 2 回目のアラートが {ESCALATIONS ON-CALL ENGINEER} に送信され、このエンジニアが {XX:XX UTC} に入室しました。

リカバリ

どのようにしてサービスが復元されて、インシデントが解決したとみなされたかを説明します。どのようにサービスを正常に復元したか、どのようにして復元に必要なステップを把握できたかを詳細に説明します。

シナリオに応じて、次の質問を検討してください。緩和までの時間をどのように改善できますか? どうすればその時間を半分に短縮できましたか?

例：

私たちは、システムの回復に 3 つのアプローチを使用しました。

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME}

例: BuildEng EC3 ASG の容量を増やして、ワークロードを処理できるノード数を増やす。また、定数を超えたノードのスケジューリングの可能性を減らす。

• クラスタの積極的なスケールダウンを防ぐために、Escalator autoscaler を無効にする。

• Build Engineering スケジューラーを前のバージョンに戻す。

タイムライン

インシデントのタイムラインを詳述します。タイムゾーンの標準化のために、UTC を使用することをお勧めします。

注目すべきリードアップ イベント、アクティビティの開始、最初の既知の影響、およびエスカレーションを含めます。決定や変更があった場合は、インシデントが終了したタイミングと注目すべき影響後のイベントを記録します。

例：

すべての時間は UTC で表示。

11:48 - K8S 1.9 制御プレーンのアップグレード完了

12:46 - V1.9 へのアップグレード完了 (クラスター オート スケーラーと BuildEng スケジューラー インスタンスを含む)

14:20 - Build Engineering が KITT Disturbed へ問題を報告

14:27 - KITT Disturbed が特定の EC2 インスタンス (ip-203-153-8-204) の不具合を調査開始

14:42 - KITT Disturbed がノードを遮断

14:49 - BuildEng が問題が複数のノードに影響を及ぼしていることを報告。問題の 86 のインスタンスが不具合はシステムに関することを示す

15:00 - KITT Disturbed が標準スケジューラーへの切り替えを提案

15:34 - BuildEng が 200 ポッドの不具合を報告

16:00 - BuildEng がすべての不具合のあるビルトを除去して、OutOfCpu レポートを作成

16:13 - 新しいビルドでも不具合が再発するため、一時的な不具合ではないことを BuildEng が報告

16:30 - KITT がこの不具合がインシデントだと認めて、インシデントとして対応

16:36 - KITT が Escalator autoscaler を無効にして、問題を軽減するために autoscaler が計算を削除しないようにする

16:40 - KITT は ASG が安定し、クラスターの負荷は正常で、顧客の影響が解決したことを確認。

テンプレート:

XX:XX UTC - インシデント アクティビティ、実行されたアクション

XX:XX UTC - インシデント アクティビティ、実行されたアクション

XX:XX UTC - インシデント アクティビティ、実行されたアクション

根本原因の特定: 5 つの Why

5 つの Why は、根本原因を特定するテクニックです。使用方法は次のとおりです。

• 影響の説明を出発点として、なぜ起こったのかを質問します。

• その影響をメモします。

• なぜ起こったのか、なぜその影響があったのかを質問します。

• 根本原因にたどり着くまで、「なぜ」を質問し続けます。

事後分析ドキュメントに、「なぜ」をリストします。

例：

1. データベースがロックされているため、アプリケーションが停止しました

2. データベースへの書き込みが多すぎて、データベースがロックされました

3. エレベーションされた書き込みを想定せずに、サービスへ変更をプッシュしたため

4. 負荷テスト変更のために確立された開発プロセスがなかったため

5. このレベルに達するまで、負荷テストが必要だと感じたことがなかったため

根本原因

インシデントの最終的な根本原因。このクラスのインシデントの再発を防ぐために、変更する必要がある物事をメモします。

例：

バグ

バックログチェック

エンジニアリング バックログを確認して、このインシデントを防げた、またはその影響を軽減できた可能性のある想定外の作業があったかを確認してください。

バックログの明確な評価によって、過去の優先度とリスクに関する決定が明確になります。

例：

このサービスを改善できた可能性のある特定の項目が、バックログにありません。フロー タイピングの改善に関する注意事項があり、これらはワークフローとともに進行中のタスクでした。

統合テストを改善するために提出されたチケットがありますが、これまでのところそれらは成功していません。

再発

根本原因が分かったので、同じ根本原因を持つ可能性のある他のインシデントを振り返って確認できますか? 確認できる場合、これらのインシデントで試行された緩和策をメモして、このインシデントが再発した理由を確認します。

例：

同じ根本原因のインシデントは、HOT-13432、 HOT-14932、HOT-19452。

教訓

インシデント対応で何がうまくいったのか、何が改善されたか、改善の余地について話し合います。

例：

• 作業のレートリミッタが適切に維持されていることを確認するために、ユニットテストを実施する必要がある。

• 通常の操作とは異なる一括操作ワークロードを見直すべきである。

• 一括操作はゆっくり開始して監視する必要がある。サービス指標が正常であれば増やしていく。

是正措置

今後このクラスのインシデントを防止するために指示された是正措置を、説明してください。誰が責任を持っていつ作業を完了する必要があるのか、その作業が追跡されている場所をメモします。

例：

1. 不具合を制限するため、一時的にオートスケールのレート制限を手動にする。

2. ユニットテストとジョブのレート制限の再導入をする。

3. スケーリング効果を導くために、クラスタ全体の分散率情報を収集する二次的メカニズムを導入する。