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

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：SREとは・SLI/SLO/エラーバジェット　|　関連：監視とアラート設計・GitOpsと自動化

要点（BLUF）

インシデント対応の目的は「まず止血（影響の最小化）、原因究明は後」。役割（指揮官・対応者・記録/連絡）を明確にし、混乱を防ぐ。
復旧の最優先はロールバック（デプロイ戦略（ローリング・ブルーグリーン・カナリア））。原因が分からなくても、直前のデプロイを戻せば多くは収まる。
終わったらポストモーテム（事後分析）を非難なし（blameless）で書く。人でなく仕組みを直し、再発を防ぐ。学習が成果物。

概念 ── 止血が先、原因は後

障害中にやりがちな失敗が「原因究明に没頭してユーザー影響を放置」。SREの鉄則は逆——まず影響を止める（mitigate）。ロールバック・トラフィック迂回・機能フラグ停止で症状を消し、根本原因の調査は落ち着いてから。

flowchart LR
    detect["検知（アラート：07-02）"] --> triage["重大度の判定"]
    triage --> mitigate["止血（ロールバック・迂回）"]
    mitigate --> recover["復旧確認（SLI が戻る）"]
    recover --> postmortem["ポストモーテム（再発防止）"]

仕組み ── 役割分担（インシデント指揮）

規模が大きい障害ほど、全員が同じことをして混乱します。役割を分けます。

役割	責任
インシデント指揮官（IC）	全体統括・意思決定・優先順位。自分では手を動かさない
対応者（Ops）	実際の調査・復旧作業
記録/連絡（Comms/Scribe）	時系列の記録・関係者/顧客への状況連絡

ICは「交通整理」に徹し、対応者が作業に集中できるようにする。小規模なら兼任でも、役割という概念を持つだけで動きが整います。

仕組み ── ポストモーテムと非難なき文化

復旧後、何が起き・なぜ起き・どう直すかを文書化するのがポストモーテム。重要なのが blameless（非難なし）——「誰がミスしたか」でなく「なぜその仕組みがミスを許したか」を問う。

flowchart TB
    fact["時系列の事実（いつ何が起きたか）"] --> cause["根本原因（なぜ・5 Whys）"]
    cause --> impact["影響（エラーバジェット消費・ユーザー影響）"]
    impact --> action["再発防止アクション（担当・期限つき）"]
    action --> system["仕組みを直す（人を責めない）"]

なぜ非難しないか——人を責める文化では、人は事実を隠す。隠れた事実からは学べない。「誰でも同じ状況なら同じミスをした」と捉え、**仕組み（プロセス・自動化・ガードレール）**を直すから、再発が本当に止まります。アクションは「担当者と期限」を付けて追跡し、やりっぱなしにしない。

なぜこうするのか

影響を最小化するため：ユーザーが困っている時間を1秒でも短く。原因究明より止血が先。MTTR（DevOps文化とDORA 4指標）を縮める。
混乱を防ぐため：役割分担で「誰が決め、誰が動き、誰が伝えるか」が明確になり、二重作業や指示の空白が消える。
組織が学習するため：非難なきポストモーテムで事実が集まり、仕組みが改善される。同じ障害を繰り返さないことが最大の信頼性向上。

⚠️ よくある誤解・落とし穴

「原因が分かるまで復旧しない」→ ユーザー影響が伸びる。先に止血（ロールバック）、原因は後で。
「ポストモーテムで犯人探し」→ 事実が隠れ学習が止まる。blameless を徹底し仕組みを直す。
「アクションアイテムを書いて満足」→ 担当・期限なしは実行されない。追跡してクローズまで。
「小さい障害はポストモーテム不要」→ ニアミスこそ学びの宝庫。閾値を決めて軽量版でも残す。
「対応の属人化」→ ランブック（監視とアラート設計）と役割定義で、特定個人がいなくても回るように。

対応ラボ

なし（運用プロセストピック）。素早い復旧の手段はデプロイ戦略（ローリング・ブルーグリーン・カナリア）・GitOpsと自動化（git revert）のラボで、検知はメトリクス・ログ・トレース（3本柱）のラボで体験できる。