インシデントの事後分析テンプレート
明確なドキュメントは、効果的なインシデントの事後分析プロセスの鍵です。多くのチームは包括的なテンプレートを使用して、各事後分析レビューで一貫した詳細を収集します。
以下に示すのは、Incident Handbook に概説されている事後分析に基づくインシデントの事後分析テンプレートの例です。これを切り取って貼り付けることで、自分の事後分析を文書化できます。
インシデントの概要
インシデントを数行に要約する。起こったこと、それが起こった理由、インシデントの重大度、影響が続いた期間を含めます。
例：
{日付} の {インシデントの時間範囲。15:45 から 16:35 など} に {数} 名のユーザーに {イベントの症状} が発生した。
イベントは、{イベントの原因となった変更の日時} の {変更} によって発生した。
{変更} には、{システムを更新するためのコードの変更などの変更の説明または理由} が含まれていた。
このコードのバグは、{問題の説明} を引き起こした。
このイベントは {監視システム} によって検出された。チームは {解決のために取られた行動} によって、このイベントへの対応を開始した。
この {重大度レベル} のインシデントは {X%} のユーザーに影響した。
このインシデントに関連して {提出されたサポート チケット、ソーシャル メディアでのメンション、アカウント マネージャーへの問い合わせの数など} で指摘されたように、さらなる影響があった。
きっかけ
インシデントを引き起こした状況を説明します。例: 以前の変更で発生したバグが検出されていなかった。
例：
{MM/DD/YY} の {16:00} に ({顧客に影響が出るまでの時間。例: 問題となっているインシデントの発生前 10 日間})、{製品またはサービス} が変更されて、{インシデントにつながった変更の内容} が行われた。
この変更によって、{変更の影響の説明} が発生した。
不具合
実行された変更が、どのように想定外の結果になったのかを説明します。可能な場合は、障害を示す関連データ可視化のスクリーンショットを添付します。
例：
{数} 回の応答がリクエストの {XX%} に送信された。これは {時間} 続いた。
影響
インシデントが内外のユーザーに与えた影響を説明して、提出されたサポート ケースの数を含めます。
例：
{MM/DD/YY} の {XX:XX UTC から XX:XX UTC} の {XX 時間 XX 分}、{インシデントの要約} 当社のユーザーがこのインシデントを経験した。
このインシデントは、経験した {XX} 人の顧客 ({システムまたはサービス} ユーザーの X%) に影響を与えた {症状の説明}。
{XX サポート チケットの数とソーシャル メディア投稿の数} が送信された。
検出
チームがインシデントを検出したのはいつですか? 彼らはそれが起こっていることを、どうやって知りましたか? 検出までの時間を、どのように短縮できますか? 検討事項: そうすれば、その時間を半分に短縮できましたか?
例：
このインシデントは、{アラートのタイプ} がトリガーされて、{チームまたは個人} が呼び出されたときに検出された。
次に、{2 人目} が呼び出された。{1 人目} はディスクへの書き込みサービスを所有していないため、対応が {XX 分/時間} 遅れた。
{改善の説明} は、{改善のチーム所有者} によって設定される。{期待される改善}。
回答
そのインシデントに対応したのは誰ですか? 彼らはいつ対応しましたか? 彼らは何をしましたか? 対応の遅延や障害をメモします。
例：
{XX:XX UTC} で呼び出しを受けた後、{オンコール エンジニア} は {XX:XX UTC } に {インシデント情報がキャプチャされたシステム} でオンラインになった。
このエンジニアは {影響を受けたシステム} に関するスキルがなかった。そのため、{XX:XX UTC} に、2 番目のアラートが、{オンコール エンジニアへのエスカレーション} のために、{XX:XX UTC} に部屋に入った人に送信された。
リカバリ
どのようにしてサービスが復元されて、インシデントが解決したとみなされたかを説明します。どのようにサービスを正常に復元したか、どのようにして復元に必要なステップを把握できたかを詳細に説明します。
シナリオに応じて、次の質問を検討してください。緩和までの時間をどのように改善できますか? どうすればその時間を半分に短縮できましたか?
例：
私たちは、システムの回復に 3 つのアプローチを使用しました。
{課題を緩和したアクション、実行された理由、その結果の説明}
例: 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 は、根本原因を特定するテクニックです。使用方法は次のとおりです。
- 影響の説明を出発点として、なぜ起こったのかを質問します。
- その影響をメモします。
- なぜ起こったのか、なぜその影響があったのかを質問します。
- 根本原因にたどり着くまで、「なぜ」を質問し続けます。
事後分析ドキュメントに、「なぜ」をリストします。
例：
- データベースがロックされているため、アプリケーションが停止しました
- データベースへの書き込みが多すぎて、データベースがロックされました
- エレベーションされた書き込みを想定せずに、サービスへ変更をプッシュしたため
- 負荷テスト変更のために確立された開発プロセスがなかったため
- このレベルに達するまで、負荷テストが必要だと感じたことがなかったため
根本原因
インシデントの最終的な根本原因。このクラスのインシデントの再発を防ぐために、変更する必要がある物事をメモします。
例：
A bug in
バックログチェック
エンジニアリング バックログを確認して、このインシデントを防げた、またはその影響を軽減できた可能性のある想定外の作業があったかを確認してください。
バックログの明確な評価によって、過去の優先度とリスクに関する決定が明確になります。
例：
このサービスを改善できた可能性のある特定の項目が、バックログにありません。フロー タイピングの改善に関する注意事項があり、これらはワークフローとともに進行中のタスクでした。
統合テストを改善するために提出されたチケットがありますが、これまでのところそれらは成功していません。
再発
根本原因が分かったので、同じ根本原因を持つ可能性のある他のインシデントを振り返って確認できますか? 確認できる場合、これらのインシデントで試行された緩和策をメモして、このインシデントが再発した理由を確認します。
例：
同じ根本原因のインシデントは、HOT-13432、 HOT-14932、HOT-19452。
教訓
インシデント対応で何がうまくいったのか、何が改善されたか、改善の余地について話し合います。
例：
- 作業のレートリミッタが適切に維持されていることを確認するために、ユニットテストを実施する必要がある。
- 通常の操作とは異なる一括操作ワークロードを見直すべきである。
- 一括操作はゆっくり開始して監視する必要がある。サービス指標が正常であれば増やしていく。
是正措置
今後このクラスのインシデントを防止するために指示された是正措置を、説明してください。誰が責任を持っていつ作業を完了する必要があるのか、その作業が追跡されている場所をメモします。
例：
- 不具合を制限するため、一時的にオートスケールのレート制限を手動にする。
- ユニットテストとジョブのレート制限の再導入をする。
- スケーリング効果を導くために、クラスタ全体の分散率情報を収集する二次的メカニズムを導入する。
Statuspage でインシデント コミュニケーションを学ぶ
このチュートリアルでは、システム停止時にインシデント テンプレートを使用して効果的にコミュニケーションを取る方法について説明します。さまざまなサービス中断に適応可能です。
このチュートリアルを読むインシデントの事後分析プロセスの重要性
インシデント後レビューとも呼ばれるインシデントの事後分析レビューは、インシデント中に何が起こったかを調査して教訓を取り込むのに最適な方法です。
この記事を読む