インシデント対応入門 — 「バグ修正」で終わらせない組織レジリエンスの高め方

@MacopeninSUTABA 氏のポストが、SRE Lounge Hiroshima #1 で発表されたスライド資料『インシデント対応入門』を紹介しています。

『インシデント対応入門』が、全エンジニア・PMに刺さる。単なる「バグ修正」で終わらせない、組織としてのレジリエンスの高め方を徹底解説している。

著者の gr1m0h 氏は、インシデントマネジメント SaaS「Waroom」を開発する Topotal 社のソフトウェアエンジニア兼 SRE です。このスライドは閲覧数 5,600 を超え、エンジニアやPMの間で広く共有されています。本記事では、スライドの内容を軸に、インシデント対応の5つのフェーズとその実践方法を掘り下げます。

なぜ「バグ修正」では不十分なのか

障害が起きたとき、コードを直して「修正完了」で終わりにしていないでしょうか。しかし、同じ種類のインシデントが繰り返し発生する組織は少なくありません。その原因は、インシデント対応を「技術的な修正」だけで完結させてしまうことにあります。

gr1m0h 氏のスライドが提示するのは、インシデント対応を5つのフェーズで捉えるフレームワークです。修正は全体のプロセスの一部に過ぎず、準備・検知・振り返り・恒久対応まで含めた組織的な取り組みが必要です。

5つのフェーズで捉えるインシデント対応

フェーズ1: 準備

インシデントが発生する前の体制整備です。「準備がないと『どうする？』から始まる」という指摘は、多くの現場で実感があるのではないでしょうか。

具体的に準備すべき項目は以下の通りです。

• 緊急度基準の策定: インシデントの重大度（SEV）を定義する
• 連絡ルールの文書化: 誰が、誰に、どの手段で連絡するかを明文化する
• 手順書の作成: 初動対応の手順を事前に整備する
• 監視設定: アラートの閾値やエスカレーション条件を設定する

SEV（重大度）レベルの定義例

スライドでは4段階の重大度レベルが紹介されています。

重要なのは、この基準が事前に合意されていることです。インシデント発生時に「これはSEV1なのか2なのか」を議論している時間はありません。

フェーズ2: 検知・初動

「『様子見』している間にも被害は広がる」というスライドの指摘は、初動の遅れがインシデントの影響を拡大させる現実を端的に表しています。

検知・初動で行うべきことは以下の4つです。

1. 状況確認: 何が起きているかを把握する
2. 影響範囲の特定: どのユーザー・機能に影響しているかを確認する
3. 緊急度の判定: SEV レベルを判断する
4. 関係者への連絡: 定められたルールに従ってエスカレーションする

フェーズ3: 対応・復旧

対応フェーズで最も重要な原則は、指揮と作業の分離です。

スライドでは3つの役割が定義されています。

インシデントコマンダー（IC）の役割

インシデントコマンダーは、PagerDuty の Incident Response Guide でも詳細に定義されている重要な役割です。IC の本質は「対応を解決に向けて前進させ続けること」にあります。

IC に求められるのは以下の能力です。

• 優れたコミュニケーション能力（口頭・文書の両方）
• サービス間の相互作用に関する高レベルの知識
• 状況を素早く把握し迅速に意思決定する力
• 専門家の意見を聞き、計画を柔軟に修正する力

注目すべきは、深い技術的知識は必須ではないという点です。IC は修復作業を行うのではなく、対応全体をリードする役割です。技術的な判断は専門家に委ね、IC は意思決定とコーディネーションに集中します。

また、このフェーズでは根本原因の究明より、サービス復旧を優先します。ロールバックで復旧できるならまずロールバックし、原因調査は復旧後に行います。

フェーズ4: 振り返り（ポストモーテム）

「犯人探し NG、仕組みの問題として捉える」。これがポストモーテムの最も重要な原則です。

ポストモーテム（postmortem）は「死後検死」が語源の振り返り手法です。インシデント発生後に原因・影響・対応プロセスを分析し、文書化する活動です。

ポストモーテムで行うこと

1. タイムラインの整理: いつ何が起きたかを時系列で記録する
2. 根本原因の分析: なぜそれが起きたかを掘り下げる
3. 成功・失敗点の検討: 対応プロセスの良かった点・改善点を洗い出す
4. 再発防止策の立案: 具体的なアクションアイテムを定める

非難のない文化（Blameless Culture）

効果的なポストモーテムの前提は、個人を責めないことです。「Aさんがデプロイを間違えた」ではなく「デプロイプロセスにミスを防ぐガードレールがなかった」と捉えます。

個人のミスを追及する文化では、インシデントの報告が遅れたり、情報が隠蔽されたりするリスクがあります。仕組みの問題として捉えることで、根本的な改善につながります。

実施のタイミング

ポストモーテムは、インシデント対応の直後に実施するのが最も効果的です。対応者が詳細を鮮明に覚えているうちに行うことで、より正確な振り返りが可能になります。一般的には、インシデント収束から24〜48時間以内が推奨されています。

フェーズ5: 恒久対応

ポストモーテムで洗い出されたアクションアイテムを確実に実行するフェーズです。

• 再発防止策の実行: 具体的な技術的・プロセス的改善を実施する
• 手順書の更新: 今回の経験を反映して対応手順を改訂する
• 監視の改善: 検知の精度や速度を向上させる

重要なのは、アクションアイテムを Jira や GitHub Issues などのチケット管理システムで起票し、「担当者」と「完了期限」を必ず設定することです。起票されないアクションアイテムは実行されません。

インシデント対応のメトリクス

スライドでは、インシデント対応の改善を定量的に追跡するためのメトリクスが紹介されています。

基本メトリクス

MTTR の細分化

MTTR を1つの数値として扱うだけでは、どのフェーズに改善余地があるかが見えません。スライドでは MTTR を以下の3つに分解する方法が紹介されています。

• TTAssemble（チーム招集時間）: アラートから対応チームが揃うまでの時間。シフト体制やオンコール通知の改善で短縮できます
• TTInvestigate（調査時間）: 調査開始から原因特定までの時間。ダッシュボードの整備やランブックの充実で短縮できます
• TTFix（修復時間）: 原因特定から復旧完了までの時間。ロールバック手順の自動化で短縮できます

この分解により、「MTTR を短縮したい」という漠然とした目標が「オンコールの通知を改善して TTAssemble を5分短縮する」という具体的なアクションに変わります。

SLI / SLO / SLA — サービス品質の数値管理

スライドの附録では、SRE の基本用語として SLI・SLO・SLA の関係が解説されています。

SLO はインシデントの SEV レベル判定にも使えます。たとえば「SLO を下回ったら SEV2」「SLA に抵触する見込みなら SEV1」といった基準を設けることで、緊急度判定を客観的に行えます。

よくある課題と最初の一歩

スライドでは、多くの組織に共通する課題が3つ挙げられています。

1. 対応担当者が不明確: 誰が対応するか決まっておらず、初動が遅れる
2. 情報の分散: Slack、電話、口頭が混在し、状況把握が困難になる
3. 同一問題の繰り返し: 振り返りが行われず、同じインシデントが再発する

これらを改善する最初のステップとして、スライドでは以下の3つが提案されています。

1. 緊急度基準を定義する: SEV レベルと対応ルールを文書化する
2. 連絡ルールを文書化する: 誰が誰にどの手段で連絡するかを明文化する
3. 小規模インシデントから振り返りを始める: 大きなインシデントを待たず、日常的な障害から振り返りの習慣をつける

完璧な体制を一度に構築する必要はありません。小さな改善を積み重ねることが、組織のレジリエンスを高める確実な方法です。

まとめ

• 5フェーズの全体像: インシデント対応は「準備 → 検知・初動 → 対応・復旧 → 振り返り → 恒久対応」の5フェーズで構成される
• 指揮と作業の分離: インシデントコマンダーは技術作業を行わず、対応全体のコーディネーションに集中する
• 復旧優先: 根本原因の究明よりもサービス復旧を優先し、原因調査は復旧後に行う
• 非難のない振り返り: ポストモーテムでは個人ではなく仕組みの問題として捉え、再発防止策を立案する
• メトリクスで改善: MTTR を TTAssemble・TTInvestigate・TTFix に分解し、具体的な改善ポイントを特定する
• 小さく始める: 緊急度基準の定義、連絡ルールの文書化、小規模インシデントからの振り返りが最初の一歩

参考

• @MacopeninSUTABA のポスト
• インシデント対応入門 - gr1m0h（SpeakerDeck）
• PagerDuty Incident Response Documentation
• Incident Commander - PagerDuty
• インシデントの再発を防ぐ効果的なポストモーテム - PagerDuty
• ポストモーテムvsレトロスペクティブ - PagerDuty
• Common Incident Management Metrics - Atlassian
• Incident Metrics in SRE - Google
• 防御からレジリエンスへ - PwC Japan