インシデント対応とポストモーテム

インシデント対応とは

インシデント とは、サービスに実害（停止・劣化・データ問題など）が出ている、または出かけている事態を指します。インシデント対応 は、これを 段取りよく収束させる一連の動き です。

混乱の最中に行き当たりばったりで動くと、「誰が何をしているか分からない」「同じ調査を二重にやる」「決定が二転三転する」といった二次災害が起きます。だからこそ、事前に決めた型 に沿って動くことが重要です。

対応の流れ：まず「止血」

インシデント対応は、おおむね次の段階を踏みます。原因究明より先に復旧（止血） を優先するのが鉄則です。

1. 検知（Detection）：監視・アラートやユーザー報告で異常に気づく。検知が速いほど被害は小さい（/devops/observability/）。
2. トリアージ（Triage）：影響範囲と深刻度を見極め、優先度を決める。「全停止」か「一部劣化」かで動きが変わる。
3. 復旧（Mitigation）：まず止血。原因が完全に分からなくても、ロールバック・フェイルオーバー・機能の一時停止（/devops/feature-flags/ のキルスイッチ）でユーザー影響を止める。
4. 恒久対応（Resolution）：止血後に根本原因を調査し、本質的な修正を行う。
5. 振り返り（Postmortem）：収束後に学びを残す（後述）。

役割を決める

規模の大きい障害ほど、役割分担 が効きます。一人で抱えると、調査も指揮も連絡も中途半端になります。

役割	担当すること
インシデント指揮官 (IC)	全体を統括し、意思決定する。自分では手を動かさない
作業担当	実際の調査・復旧オペレーションを行う
記録担当	時刻つきで起きたこと・やったことを書き留める
連絡担当	関係者・経営・顧客への状況連絡を担う

特に 指揮官（IC）が「作業をしない」 のが肝です。指揮官まで手を動かすと、全体を見る人がいなくなります。記録担当が残すタイムラインは、後のポストモーテムの一次資料になります。

ポストモーテムとは

ポストモーテム（postmortem、事後検証） は、インシデントが収束した後に作る振り返り文書 です。「何が起きたか」「なぜ起きたか」「どう直すか」を記録に残し、組織の資産 にします。

典型的な構成は次の通りです。

• 概要：何が・いつ・どれだけの影響で起きたか（影響範囲・継続時間）。
• タイムライン：検知から復旧までの出来事を時刻つきで列挙。
• 根本原因：表面的な引き金だけでなく、なぜそれが起きたのかを掘り下げる。
• 検知と対応の評価：早く気づけたか、対応はスムーズだったか。
• 再発防止策（アクションアイテム）：担当者と期限を明記 した具体的な改善項目。

非難なきポストモーテム（Blameless）

ポストモーテム文化の核心が 「非難なき（blameless）」 という原則です。これは 「個人を責めない。代わりに、その人がなぜそう判断したのか、なぜミスが通ってしまったのかを問い、仕組みを直す」 という姿勢です。

なぜ非難しないのか。人を責める文化では、人は失敗を隠す からです。隠されれば学べず、同じ障害が繰り返されます。逆に「正直に話しても罰されない」と分かれば、本当の経緯が共有され、組織全体が学べます。

• ❌ 非難あり：「○○さんが設定をミスしたのが原因」→ 個人攻撃で終わり、隠蔽を生む。
• ✅ 非難なし：「危険な設定変更が、確認なしに本番へ反映できてしまう 仕組み が原因」→ ガードレールを足す。

前提は 「関わった全員は、その時点の情報で最善を尽くした」 と考えること。ミスが起きたなら、それは個人の不注意ではなく、ミスを許してしまったシステム側の欠陥 とみなします。

SRE 文化との関係

これらは SRE（/devops/sre-slo/）の文化と深く結びつきます。SRE では障害を「学習の機会」と捉え、ポストモーテムを通じて信頼性を継続的に高めます。再発防止策を IaC や CI/CD のガードレールに落とし込むことで、同じ失敗を 仕組みで 封じていきます。

まとめ

• インシデント対応は 検知 → トリアージ → 復旧（まず止血）→ 恒久対応 の流れ。役割分担（指揮・作業・記録・連絡）で混乱を防ぐ。
• ポストモーテムは タイムライン・根本原因・再発防止策 を残す振り返り文書。アクションは 担当と期限つき で。
• 核心は 非難なき（blameless）：個人を責めず、ミスを許した 仕組みの欠陥 を直す。
• 障害を 学習機会 に変えるこの文化が、再発を防ぎ信頼性を底上げする。