インシデント対応フローチャート：最初のアラートからポストモーテムまで

午前 3 時に、10 ページもあるインシデント対応ポリシーを読む人はいません。オンコール担当のエンジニアがすぐに知るべきことは 4 つです。これは本物か、インシデントか、ほかに誰に知らせる必要があるか、そして最初に何をすべきか。1 ページのフローチャートは、これらの問いに出てくる順番どおりに答えます。ポリシーの中で実際に守られるのは、この部分です。

この記事では、本番サービスを運用するエンジニアリングチーム向けに、インシデント対応のフローチャートを作ります。トリアージ、インシデントを宣言する基準、重大度と役割、緩和、そしてループを閉じるポストモーテムを扱い、最後に、ストレスのかかる場面でも使えるフローチャートを描くためのコツを紹介します。

フローチャートが決めるべきこと

インシデント対応のプロセスは、いくつかの時間のかかる作業をはさんだ一連の判断です。判断はチャートに載せ、答えにラベルを付けた問いとして書きます。

• アラートは本物で、対応可能か。 そうでなければ、問題はアラートそのものです。
• インシデントか。 そうでなければ、チケットで扱う通常の作業です。
• どのくらい深刻か。 重大度によって、誰を呼び出し、誰に知らせるかが決まります。
• サービスは復旧したか。 していなければ、次の緩和策を試すか、エスカレーションします。

デプロイのロールバックやデータベースのフェイルオーバーの手順など、それ以外のことはすべて、チャートからリンクするランブックに書きます。

インシデントを宣言するタイミング

宣言はチームがためらいがちなステップであり、そのためらいは高くつきます。Google の SRE 本のインシデント管理の章は、早めの宣言を勧めています。問題が大きくなってから何時間も経ってプロセスを始めるより、宣言して簡単な修正を見つけ、インシデントを閉じるほうがよいというのです。この章のチームは、次のいずれかに当てはまるときにインシデントを宣言します。

1. 問題の解決に 2 つ目のチームが必要である。
2. 障害が顧客から見えている。
3. 1 時間集中して分析しても問題が解決しない。

自分たちの基準を、判断の横にチャートに書き込みましょう。基準が明確なら、宣言に伴う気まずさがなくなります。

役割

同じ章は、Incident Command System に基づく体制を説明しています。小さなチームでも役割に名前を付けておくと役立ちます。最もよくある失敗は、1 人がすべての役割を抱え込むことだからです。

インシデントコマンダーは、生きたインシデントドキュメントも管理し、シフトの終わりには明示的に引き継ぎます。交代するコマンダーが引き継ぎを宣言し、相手の了承を待つのです。

インシデント管理のスキルは、使わなければ衰えます。同じ章は、複数のチームやタイムゾーンにまたがる運用上の変更にもこの枠組みを適用することや、過去のインシデントをロールプレイすることを勧めており、そうすれば次の本番のインシデントの前にプロセスに慣れておけます。新しいオンコール担当者と一緒に、過去のインシデントを題材にフローチャートをたどるのは、手軽な始め方です。

重大度レベル

重大度の定義は会社によって異なります。以下は例として扱い、自分たちの定義をチャートに書きましょう。

フローチャートを順に見る

1. 受領とトリアージ。 アラートが発火したら、呼び出しのエスカレーションが止まるように受領し、範囲と影響を確認します。
2. 本物で、対応可能か。 誤ったアラートや対応できないアラートは、調整または削除してから閉じます。
3. インシデントか。 基準に当てはめます。当てはまらなければ、チケットで通常の作業として扱います。
4. 宣言。 インシデントコマンダーを決め、チャンネルとインシデントドキュメントを開きます。
5. 重大度。 SEV-1 と SEV-2 では、コミュニケーション担当がステータスページに投稿し、定期的に状況を伝えます。
6. まず緩和する。 ロールバック、フェイルオーバー、フィーチャーフラグの無効化、負荷の切り捨てを行います。SRE 本が最優先とするのは、出血を止め、サービスを復旧させ、証拠を保全することです。根本原因はその後です。
7. 復旧したか。 していなければ、次の緩和策を試すかエスカレーションし、ループを繰り返します。
8. 解決。 メトリクスで確認し、監視を続け、システムを通常の運用に戻します。
9. ポストモーテムとアクションアイテム。 非難なしのポストモーテムを書いてレビューし、アクションアイテムが追跡されるようになったらインシデントを閉じます。

図の読み方は次のとおりです。

• Yes は右へ、No は下へ。 すべての判断が同じ規則に従うので、主経路は右へ進み、早期の出口は下へ抜けます。
• 左側は初動。 アラートを受領してトリアージします。本物でない、あるいは対応できないアラートと、インシデントではない事象は Done で終わります。
• 3 列目はインシデント。 宣言し、重大度を確認し、緩和します。SEV-1 と SEV-2 では、右側でコミュニケーション担当が加わります。
• ループ。 「Service restored?」の答えが Yes になるまで、緩和に戻ります。
• 右の列は終了。 解決し、非難なしのポストモーテムを書き、アクションアイテムが追跡されたら閉じます。
• メモ には宣言の基準と重大度レベルを書いているので、ほかのドキュメントを開く必要はありません。

ポストモーテムでループを閉じる

SRE 本のポストモーテム文化の章は、しきい値を超えるユーザーから見えるダウンタイムや性能低下、種類を問わないデータ損失など、ポストモーテムを書くよくあるきっかけを挙げています。ポストモーテムが非難なしであるとは、人を責めずに、システムとプロセスの中に寄与した原因を探すことです。そうでないと、人は問題を報告しなくなります。ポストモーテムは担当者と期限のある書類としてチャートに描き、アクションアイテムが追跡されるまではインシデントを終了扱いにしないでください。

セキュリティインシデントには、このチャート以上のものが必要です。証拠の保全、法的・規制上の手順、そして多くの場合は別のチームです。2025 年 4 月に公開された NIST SP 800-61 Rev. 3 が標準的な参考資料です。セキュリティの分岐はその場で考えるのではなく、そのプロセスにつなぎましょう。

ストレス下で使うフローチャートを描くコツ

• 開始は 1 つ、終了は明確に。 それが「Done」であっても、すべての経路はどこかで終わるようにします。
• 判断は Yes か No で答える問いにします。 両方の出口にラベルを付け、Yes と No が毎回同じ辺から出るようにします。
• ループを明示する。 「次の緩和策を試す」は脚注ではなく、ループです。
• 図形は 15 個まで。 詳細は、各ステップからリンクするランブックに書きます。
• 責任が移る場所を示す。 役割ごとのレーンを持つ版を作るなら、クロスファンクショナル・フローチャートのテンプレートから始めましょう。
• オンコール担当者が見る場所に置く。 ランブックにはスクリーンショットを貼るのではなく、リンクするかライブの図を埋め込みましょう。

多くのチームと正式な引き継ぎが関わるプロセスなら、BPMN 図のほうが正確にモデル化できます。オンコールで使うなら、フローチャートのほうがたどりやすいでしょう。

Archboard で作る

1. Google または GitHub でサインインし、図を作成します。
2. フローチャートパックから、開始と各終了用の 開始 / 終了、各ステップ用の 処理、各問い用の 判断 を追加します。
3. ポストモーテム用に 書類 を追加します。
4. 図形をつなぎます。判断の図形は右の角に Y、下の角に N を表示するので、Yes は右へ、No は下へ描き、両方にラベルを付け、「復旧していない」出口を緩和に戻します。
5. 宣言の基準と重大度レベルを書いた基本パックの メモ ノードを追加します。

この例で使うダイアグラムノードは 15 個で、Free プランの範囲に収まります。フローチャート作成のページでは、ほかの図形とスイムレーンのレイアウトを紹介しています。

よくある質問

インシデント対応フローチャートは誰が管理すべきですか？ オンコールのローテーションを運営しているチームです。次に何をすべきか分からなかった人がいたインシデントのたびに、見直しましょう。

すべてのアラートをインシデントにすべきですか？ いいえ。ほとんどのアラートは通常の作業として扱うべきです。基準を満たしたら宣言し、迷ったら早めに宣言しましょう。

小さなインシデントにもインシデントコマンダーは必要ですか？ 誰かが全体像を把握している必要があります。小さなインシデントではオンコール担当者がコマンダーです。それを口に出して伝えておけば、2 人が同じものを別々の方法で直そうとする事態を防げます。

ポストモーテムはいつ書くべきですか？ 詳細が記憶に新しいうちに、早めに書きます。チームが守れる期限を決めてチャートに書き、アクションアイテムを追跡しましょう。

フローチャートにセキュリティインシデントも含めるべきですか？ セキュリティインシデントのプロセスに引き渡す分岐を追加しましょう。そのプロセスには、証拠の保全や法務レビューなど、異なる手順があります。

無料で始める — 1 シート、クレジットカード不要。