インシデント事後分析プロセス: 追跡、文書化、改善

重要ポイント

• インシデントの事後分析は、何が起こったのか、なぜ起こったのか、そして同じ問題の再発を防ぐために何を改善すべきかをチームが理解するのに役立ちます。

• Jira Service Management、Confluence、Jira を組み合わせて使用することで、対応、ドキュメント化、フォローアップを連携させたワークフローを構築できます。

• 一貫した事後分析テンプレートを使用することで、インシデント レビューを文書化しやすくなり、時間をかけて比較や振り返りを行うことが容易になります。

• 是正措置を担当者と期限付きの Jira 作業項目に落とし込むことで、チームは学んだ教訓を実際の改善につなげやすくなります。

本番環境で問題が発生した場合、その修正はあくまで始まりに過ぎません。同じくらい重要なのは、なぜそれが起こったのかを理解し、同じ問題が二度と起こらないようにすることです。

インシデントの事後分析とは、何が問題だったのか、チームがどのように対応したのか、そして今後何を改善すべきかを網羅し、インシデントを最初から最後まで振り返る構造化されたレビューのことです。

インシデント対応計画テンプレートに沿ってプロセスを進めることで、チームはすべてのインシデントを一貫した方法で記録できるようになり、重要な点を見落とすことなく、すべてのレビューを実際の改善につなげることができます。

仕組み: インシデント対応と事後分析の記録方法

優れたインシデント管理とは、単に火消しをすることではありません。すべてのインシデントを、より良いプロセス、より良いツール、そして次回に向けたより良い準備につながる仕組みを構築することです。Jira Service Management、Confluence、Jira を組み合わせて使用することで、アラート発生の瞬間から事後分析、さらにその後のフォローアップ作業まで、インシデント対応ライフサイクル全体をカバーする連携ワークフローをチームで実現できます。

このアプローチにより、インシデントごとのドキュメントを一貫した状態で維持でき、責任の所在も明確になります。インシデントの詳細が Slack のメッセージやメール、あるいは誰かの記憶の中に散らばっているのではなく、すべてが単一の連携された環境に集約されるため、レビュー、参照、対応を容易に行えます。また、この一貫性によって、インシデント対応計画テンプレートがプロセスの中心に据えられ、チームが手の空いたときに埋めるだけの存在になることを防げます。

各段階におけるプロセスの流れは次のとおりです。

Jira Service Management でインシデント対応を実施する

Jira Service Management は、インシデント対応の出発点です。問題が発生したらすぐに JSM に記録し、重大度レベルを設定して、適切な対応担当者を割り当てます。

インシデント対応中、チームは JSM を使用して次のことを行えます。

• アクション、意思決定、エスカレーションをリアルタイムで追跡する

• 誰が対応に関与し、何が変更されたのかを明確に記録する

• 後の事後分析に役立つ詳細情報を記録する

• 対応担当者の作業を妨げることなく、経営陣に情報を共有する

JSM は Confluence や Jira と連携しているため、インシデント対応中に収集したデータを事後分析のドキュメントやフォローアップ作業にそのまま引き継ぐことができます。また、より広範な ITSM ソフトウェア環境の一部として JSM を利用しているチームでは、インシデント データがより大きなサービス管理全体の可視化にも活用されます。

JSM は、対応全体を通じてインシデント通知を強化する機能も備えており、チームが次のことを行えるよう支援します。

• 顧客、サポート チーム、ステークホルダーに最新情報を共有する

• インシデント対応中の混乱を軽減する

• ステータスや影響範囲の可視性を高める

• 重大インシデントや危機管理シナリオにおいて、より明確なコミュニケーションを実現する

インシデントが解決する頃には、チームにはその経過の詳細な記録がすでに揃っているため、事後分析の文書化が容易になり、今後の改善にもより役立つものになります。

Confluence で事後分析を記録する

インシデントが解決したら、まだ記憶に新しいうちに内容を文書化しましょう。理想的には 24 ～ 48 時間以内に行ってください。時間が経つほど状況の詳細が失われ、事後分析の有用性が低下します。

インシデント事後分析テンプレートを使用して専用の Confluence ページを作成し、タイムライン、根本原因分析、影響評価、教訓といった各セクションを順に記録していきます。このページに含まれるインシデント対応テンプレートには、チームが新しいインシデントごとにコピーして記入できる完全なフレームワークが用意されているため、毎回ゼロから何を記録すべきかを考える必要がありません。

Confluence で事後分析を管理することで、次のような実務上のメリットがあります。

• チーム全体での可視性: エンジニアリング部門から経営陣まで、オンコール担当者を追いかけて口頭で説明を受けなくても、誰でも何が起こったのかを確認できます。

• パターンの特定: すべてのインシデントが同じ形式で記録されることで、四半期をまたいだ繰り返し発生する障害や、システム全体の弱点を発見しやすくなります。

• 非難を目的としないドキュメント化: 構造化されたインシデント対応テンプレートにより、責任追及ではなくシステムやプロセスに焦点を当てた議論が可能になり、より率直で有用なレポートにつながります。

• 新規メンバーの立ち上がりを迅速化: 新しいチーム メンバーは過去の事後分析を読むことで、システムが障害時にどのように動作するのか、またチームが過去のインシデントから何を学んできたのかを理解できます。

より効果的な事後分析レビューの進め方について詳しく知りたい場合は、インシデント事後分析ハンドブックをお読みください。

フォローアップを Jira の作業項目として追跡する

事後分析の価値は、そこからどのようなアクションにつながるかによって決まります。レビュー中に特定されたすべての是正措置や繰り返し発生する問題は、明確な担当者と期限を設定した Jira 作業項目へ落とし込む必要があります。

このステップこそが、実際に改善を続けるチームと、同じ問題を繰り返し抱え続けるチームを分けるポイントです。是正措置を Jira で追跡可能な作業項目として管理することで、マネージャーは進捗を把握でき、チームは合意した改善事項の完了に対して互いに責任を持てるようになります。また、優先順位付けにも役立ちます。インシデント起因の作業を他のバックログと並べて管理することで、他の優先事項とのバランスを取りやすくなり、気づかないうちにリストの下位に埋もれてしまうのを防ぐことができます。

適切なインシデント管理ツールは、このワークフロー全体をエンドツーエンドで連携させます。対応、ドキュメント化、フォローアップの各システムが統合されていれば、問題を検知してから再発防止策を講じるまでのギャップを大幅に縮小できます。

インシデント対応テンプレート

以下は、チームが新しいインシデントごとにコピーして調整できるインシデント対応計画テンプレートです。初期サマリーやタイムラインから、根本原因分析、教訓、是正措置に至るまで、事後分析の各フェーズを順を追って整理できるようになっています。すべてのインシデントで一貫した構成を使用することで、重要事項の見落としを防ぎ、事後分析を長期的に簡単に比較できるようになります。

テンプレート内の例は出発点であり、厳格なスクリプトではありません。自社の運用方法に合わせて、表現や詳細レベルを調整してください。重要なのは、数か月後に事後分析を読む人でも、何が起こったのか、チームがどのように対応したのかを正確に理解できるよう、十分な文脈を記録することです。

インシデントの概要

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

例：

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