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

インシデントの概要

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

例：

{日付} の {インシデントの時間範囲。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 は、根本原因を特定するテクニックです。使用方法は次のとおりです。

• 影響の説明を出発点として、なぜ起こったのかを質問します。
• その影響をメモします。
• なぜ起こったのか、なぜその影響があったのかを質問します。
• 根本原因にたどり着くまで、「なぜ」を質問し続けます。

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

例：

1. データベースがロックされているため、アプリケーションが停止しました
2. データベースへの書き込みが多すぎて、データベースがロックされました
3. エレベーションされた書き込みを想定せずに、サービスへ変更をプッシュしたため
4. 負荷テスト変更のために確立された開発プロセスがなかったため
5. このレベルに達するまで、負荷テストが必要だと感じたことがなかったため

根本原因

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

例：

<バグの原因またはバグが起こったサービス> 接続プールの処理時のバグが、接続状態への不十分な視認性と組み合わさり、障害状態での接続リークを引き起こした。

バックログチェック

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

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

例：

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

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

再発

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

例：

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

教訓

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

例：

• 作業のレートリミッタが適切に維持されていることを確認するために、ユニットテストを実施する必要がある。
• 通常の操作とは異なる一括操作ワークロードを見直すべきである。
• 一括操作はゆっくり開始して監視する必要がある。サービス指標が正常であれば増やしていく。

是正措置

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

例：

1. 不具合を制限するため、一時的にオートスケールのレート制限を手動にする。
2. ユニットテストとジョブのレート制限の再導入をする。
3. スケーリング効果を導くために、クラスタ全体の分散率情報を収集する二次的メカニズムを導入する。