# ポストモーテムの教科書 本教科書は wiki に蓄積された 25 以上のソースと 15 以上のコンセプトページを横断し、ポストモーテムとインシデント分析の理論・実践・研究を体系的に構成したものである。初学者が基礎から読み進め、実践者が深化し、研究者が未解決の問いを探索できることを目指す。 --- ## 第 I 部　基礎——ポストモーテムとは何か ### 第 1 章　定義と目的 ポストモーテム（Postmortem）は、インシデント発生後に行う**非難なき事後振り返り**である。何が起きたか、なぜ起きたか、どう対応したか、そして再発をどう防ぐかを構造化して記録し、**個人でなくシステムの欠陥**に焦点を当てる（Source: [[ポストモーテム]]）。 語源はラテン語の「死後の検査（post mortem）」だが、ソフトウェアの文脈では「サービスの死」を調べるのではなく、**組織としての学習を行う営み**である。Google の SRE Book（2016）がこの用語を業界に広め、多くの組織が採用した（Source: [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]]）。 ポストモーテムの目的は多層的である。Sidney Dekker（2015）は 4 つの目的を定式化した（Source: [[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]]）。 | 目的 | 内容 | SRE での位置づけ | | -------- | --------------- | ----------------- | | **認識論的** | 何が起きたかを確立する | タイムライン、ログ、影響範囲の記録 | | **予防的** | 回避への経路を特定する | 再発防止策、アクションアイテム | | **道徳的** | 逸脱を跡付け境界を強化する | 運用規範の再確認 | | **実存的** | 発生した苦痛への説明を見つける | 関係者の心理的クロージャー | 従来の SRE ポストモーテムは (1) と (2) に集中し、(3) と (4) を「非難文化になるから避ける」として抑制する傾向がある。しかし (3)(4) を全否定するのではなく、**非難でなく学習に向ける**ことが現代的な理解である。 ### 第 2 章　三つの柱 ポストモーテムは以下の三つの柱で成り立つ（Source: [[ポストモーテム]]）。 **第一の柱: ブレームレス文化** 人でなくシステムの欠陥に焦点を当てる。ポストモーテムを書いた人を賞賛し、広く共有する。 ただし「ブレームレス（非難なし）」という表現には落とし穴がある。[[Will Gallego]]（Etsy）は、この表現が「責任の否定」と誤解されやすく、「誰がどのような判断をしたか」という必要な情報が隠蔽される問題を指摘した。代替概念として「ブレーム・アウェア（非難認識）」を提唱する——非難感情の存在を認めつつ、それを指差しとして表出させない（Source: [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]）。 **第二の柱: 構造化プロセス** タイムライン中心の文書作成、SEV 別の会議スケジュール、ステータスワークフロー（Draft → In Review → Reviewed → Closed）、アクションアイテムの追跡。PagerDuty は SEV 別に 15〜30 分の会議を処方する（Source: [[@PagerDuty__Post-Mortem Process]]）。 **第三の柱: ツーリングと発見可能性** データの一元化、自動生成テンプレート、リビングドキュメントとしての運用、タグベースの検索。Datadog は 4 つの実践——データ一元化・自動テンプレート・リビングドキュメント・発見可能性——を提示した（Source: [[@2021__Datadog Blog__Best Practices for Writing Incident Postmortems]]）。 ### 第 3 章　ポストモーテムの基本プロセス 典型的なプロセスは以下の通りである。 1. **インシデントの終了判定**: 緩和・復旧が完了し、サービスが安定している 2. **ポストモーテム文書の作成**: タイムライン・影響範囲・根本原因（寄与因子）・対応内容・再発防止策を記録 3. **レビュー会議の実施**: 関係者が集まり、文書の内容を議論し深掘りする 4. **アクションアイテムの設定と追跡**: 再発防止に必要な具体的作業を特定し、所有者と期限を設定 5. **共有と発見可能性の確保**: 関係者以外も含めて広く共有し、検索可能にする #### 再発防止策の 4 分類 mixi が示した構造化フレームワークは、再発防止策を場当たり的に列挙するのではなく、4 つのカテゴリで網羅的に検証する（Source: [[@mixi developers__インフラ障害対応とポストモーテム]]）。 | カテゴリ | 問い | |---|---| | **予防** | この障害の発生自体を防げるか | | **検出** | もし発生したら、より早く検知できるか | | **緩和** | 検知した後、影響をより早く小さくできるか | | **修正** | 根本的な修正を行い、同種の問題を解消できるか | --- ## 第 II 部　理論的基盤——なぜ事故は起きるのか ### 第 4 章　事故モデルの進化 ポストモーテムでどのような分析を行うかは、意識するしないにかかわらず、「なぜ事故が起きるのか」に関する**事故モデル**に依存する（Source: [[事故モデル]]）。 #### 4.1 Bad Apples モデル 最も原始的なモデル。「システムは基本的に安全であり、信頼性のない人間が障害を引き起こす」と仮定する。「悪いリンゴを取り除けばよい」という結論に至るため、個人への制裁（懲罰・解雇・降格）が改善策となる。Amazon・NASDAQ・ドイツ鉄道の公開インシデント報告がすべて「Human Error」と結論づけていた事実が、このモデルの根強さを物語る（Source: [[@2016__SREcon16Europe__Accident Models in Post Mortems]]）。 #### 4.2 ハインリッヒのドミノ理論（1931） 事故を「社会環境 → 人間の欠陥 → 不安全行為 → 事故 → 怪我」の連鎖ドミノとして説明する。直線的因果連鎖を前提とし、1 つのドミノを除去すれば連鎖が止まるという楽観的仮定を持つ。 #### 4.3 スイスチーズモデル（Reason, 1990） 組織の防御層（チーズのスライス）には穴（能動的失敗と潜在的条件）があり、すべての穴が揃った瞬間に危険が貫通するというモデル。Bad Apples より洗練されているが、依然として「障壁の欠陥」という静的な構造に注目し、動的なシステム適応を捉えにくい。Reason 本人も後に改訂を要求している（Source: [[@2016__SREcon16Europe__Accident Models in Post Mortems]]）。 #### 4.4 Normal Accidents（Perrow, 1984） 密接に結合した複雑系では、想定外の相互作用による大規模事故は避けられないとする。悲観的だが、サプライズが設計に内在するという洞察は現代のマイクロサービスアーキテクチャにも通じる。 #### 4.5 Systems Theory と CAST [[Nancy G. Leveson]] が提唱した CAST（Causal Analysis based on Systems Theory）は、線形因果論を離れ、「制御構造」「コントローラーの意思決定とメンタルモデル」「文脈要因」「システム的要因」を析出する。Google Maps の「都市名誤り」インシデントでは、RCA が「ツールの不備」「サンプリング戦略の欠如」と結論したのに対し、CAST は「チームのメンタルモデルの誤り」「責任拡散」「データセット変化による既存ポリシーの陳腐化」を追加で特定した（Source: [[CAST]], [[@2026__SREcon26Americas__The Case of the Misnamed Cities - CAST Analysis of a Google Maps Incident]]）。 #### 4.6 事故モデルの選択がポストモーテムを規定する **どのモデルを採用するかが、何を「原因」として記録し、何を「改善策」として立案するかを根本的に変える**。Bad Apples モデルでは個人の処分がアクションアイテムになり、スイスチーズモデルでは防御層の追加が、CAST ではメンタルモデルと組織構造の改善が改善策となる。 ### 第 5 章　Cook の 18 命題——複雑システム障害論 [[Richard I. Cook]]（1998）の 18 命題は、ポストモーテム実践者にとっての正典テキストである（Source: [[複雑システム障害論]]）。ここでは特にポストモーテムに直結する 5 つを取り上げる。 **命題 4: 潜在的障害の混合を常に内包する** 複雑システムは、障害の前兆をすでに含んだ状態で日常的に稼働している。問題は「潜在的障害があるかどうか」ではなく「いつ顕在化するか」である。 **命題 5: 劣化モードで稼働する** 完全に健全な複雑システムは存在しない。常にどこかが劣化している状態で動いている。 **命題 7: 根本原因帰属は根本的に誤りである** 複数障害が必要条件を構成するため、単一の「根本原因」は存在しない。RCA は技術的理解ではなく、「特定の原因に責任を帰属させる社会的・文化的必要性」を反映する行為。 **命題 8: ヒンドサイトバイアス** 結果を知っていることが、事故前の実践者の視点を再現する能力を損なう。「あの時こうしていれば」は事後だから言えることであり、当時の限定的な情報のもとでは判断は合理的だった可能性が高い（Source: [[ヒンドサイトバイアス]]）。 **命題 12: 人間は複雑システムの適応的要素** 人間は障害源であると同時に、脆弱部の再構成・リソースの集中投入・回復経路の確保・劣化の早期検知という 4 形態の適応で安全を生み出す存在でもある。 ### 第 6 章　ローカル合理性とヒューマンエラー批判 「ヒューマンエラー」をポストモーテムの結論にすることは、**分析の行き止まり（analytical dead end）**である。この観察は 3 人の実践者が独立に到達した収束点である（Source: [[人的要因]]）。 - **Gallego**（Etsy, 2018）: 「人はその時点の情報において最善と信じる行動をとる」——ローカル合理性（Local Rationality） - **Lund**（SREcon, 2019）: 「Human Error は analytical dead end」 - **Eckhardt**（Heroku, 2019）: 「ヒューマンエラーは調査を終わらせる場所でなく、始める場所」 いずれも Sidney Dekker の New View——人間は機能不全の源泉ではなく、システムの適応的要素——を SRE 実践に翻訳したものである。ポストモーテムで「ヒューマンエラー」と書きたくなった時は、以下の問いに展開すべきである。 1. その人間はどうエラーを起こしたか 2. エラーが起きやすかった条件は何か 3. エラーがシステムに影響した経路は何か 4. 人間がエラーに気づくまでどのくらいかかったか --- ## 第 III 部　実践——ポストモーテムの運営 ### 第 7 章　ファシリテーション技術 ポストモーテム会議の質は、ファシリテーターの言語選択と会議運営に大きく依存する（Source: [[レトロスペクティブファシリテーション]]）。 #### 7.1 Why/You を How/What に変換する 三者（Gallego・Lund・Eckhardt）が独立に収束した最も重要な言語規律である。 | 避けるべき | より良い代替 | |---|---| | 「なぜあなたは X したのか」 | 「X が行われた経緯をもう少し詳しく聞かせてください」 | | 「なぜ前回直さなかったのか」 | 「この問題が以前にも見えていたとしたら、当時どういう状況だったか教えてください」 | | always, never, should, just | 具体的な事象・数値・条件の記述 | 「なぜ前回これが起きたとき直さなかったのか？」という問いには 5 つの後知恵バイアスの前提が埋め込まれている: (1) 以前に起きた、(2) 前回直せた、(3) 容易に直せた、(4) あなたが直す人間だった、(5) 直さない正当な理由がなかった（Source: [[@2019__SREcon19 Asia__Retrospectives for Humans (a crash course)]]）。 #### 7.2 デブリーフィングの 7 カテゴリ Gallego が体系化した問いかけフレームワーク（Source: [[@2016__SREcon16Europe__Accident Models in Post Mortems]]）。 1. **Cues**: 何を見ていたか 2. **Interpretation**: 状況をどう理解していたか 3. **History**: この状況は見覚えがあるか 4. **Goals**: 何を達成しようとしていたか 5. **Action**: どう行動を選んだか 6. **Communications**: どのコミュニケーション手段を使ったか 7. **Help**: 誰かに助けを求めたか この配列は「その時点で世界がどう見えたか」を段階的に再構築するよう設計されている。 #### 7.3 会議の心得 - **個別インタビューを先行させる**: グループ設定で誰かの記憶が他者に上書きされることを防ぐ。インシデント当日ではなく前週から問い起こし、疲労・プレッシャー・文脈を引き出す（Source: [[@2019__SREcon19 Asia__A Tale of Two Postmortems - A Human Factors View]]） - **ユーモアを管理する**: 「喜劇は悲劇＋時間」——ポストモーテムには十分な時間が経っていない。ジョークの代わりに温かさ・誠実さ・感謝を示す - **沈黙者を観察する**: 沈黙は「言うことがない」ではなく「割り込む機会を得られない」ことが多い - **会議の目標を明示する**: 「この会議の目標は、このインシデントを二度と起こさないことではない。学ぶことだ。アクションアイテムがゼロで終わっても、価値のある議論だったと感じられるべきだ」（Lund） #### 7.4 Miller's Law——中核原則 「相手の言葉を理解するには、それが真だと仮定してどういう状況なら真になるかを想像しなければならない」（George A. Miller）。自分の直接経験の外にある発言——同一インシデントに関わった別の人間の体験——を理解する唯一の手法である（Source: [[@2019__SREcon19 Asia__Retrospectives for Humans (a crash course)]]）。 ### 第 8 章　インシデントレポートの書き方 #### 8.1 テンプレート型 vs ナラティブ型 多くの IR がテンプレートを機械的に埋める形で書かれ、関係者以外に読まれないまま学習機会が失われる。Laura Nolan（Stanza Systems, 2022）はナラティブ型 IR を提唱した（Source: [[インシデントレポート執筆]]）。 | 側面 | テンプレート型 | ナラティブ型 | |---|---|---| | 構造 | 定義済みセクションへの箇条書き | 謎 → 調査の試行錯誤 → 解決の 3 部構成 | | 読者性 | 関係者以外はほぼ読まない | 関心あるエンジニアなら誰でも引き込まれる | | 学習の深さ | 「何が起きたか」の事実記録 | 「その時点で何が見えていたか」の再現 | | 長期価値 | 形骸化しやすい | 年単位で語り継がれる知識になりうる | Lorin Hochstein（Airbnb, 2026）はさらに踏み込み、ポストモーテムテンプレートの中で本当に気にすべきは**ナラティブ記述のセクションだけ**であると述べた。時系列で書き、意味のある区切り（エピソード）に小見出しを付け、インシデント開始より前（数ヶ月〜数年前）から書き始めることを推奨する（Source: [[@2026__SREcon26Americas__The Power of Stories]]）。 #### 8.2 良い IR の 4 軸 1. **ナラティブ重視**: ストーリーとして書く。不確実性や「まだ分かっていなかった」状態を率直に記述 2. **読者サポート**: すべてのエンジニアが読めるよう、ジャーゴンとシステム名を説明する 3. **視覚化**: アーキテクチャ図・グラフ・タイムライン・スクリーンショットを惜しまず使う 4. **分析の共有**: 技術的修正だけでなく、システム運用の洞察まで踏み込む #### 8.3 文体の原則 - **印象的なタイトル**: 読者が後で参照できる記憶に残るタイトル（例: 「Cascade of doom: JIT, and how a Postgres update led to 70% failure on a critical national service」） - **シンプルで明確な言語**: 専門的手順も「通常であれば簡単なはずなのに」という文脈から始める - **セールスピッチにしない**: 誠実・謙虚・正直が信頼を生む #### 8.4 SRE 主導の執筆会議 [[KATO Toshiya]]（LINE）は、当事者のみで執筆・共有する既存プロセスの 5 つの構造的問題を指摘し、解法として全体共有前の 30 分執筆専用会議を SRE が主導する手法を実践した。黙読 → 質問 → 提案 → Kudo wall → 会議後編集の流れで、副次効果として共有会議が爆速で終わるようになった（Source: [[@2023__SpeakerDeck__Postmortem as a textbook]]）。 ### 第 9 章　プロセスの実装パターン 各組織の実装を比較する（Source: [[ポストモーテム]]）。 | 側面 | PagerDuty | Datadog | mixi | Hatena | カヤック | |---|---|---|---|---|---| | 文書の中核 | タイムライン | インタラクティブグラフ | テンプレート 5 項目 | 報告 5 項目 | Slack 月次投稿 | | 再発防止策 | フォローアップチケット | タグベース検索 | 4 分類 | 予防策 + 備考 | sre-advisor | | 会議体 | 15-30 分 SEV 別 | 明示なし | 明示なし | 明示なし | 月刊ポストモーテム | | 共有範囲 | IC + 対応者 | チーム | 関係者 | **全社エンジニア** | 全社 Slack | | 文化的強調点 | ブレームレス | 効率化 | 賞賛文化 | 横展開学習 | 知見のコード化 | #### Blameless の 6 要素 [[Ashar Rizqi]]（Blameless, 300 社以上の事例）が体系化した成功要件（Source: [[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]]）。 1. **Ownership**: サービスオーナー = ポストモーテムオーナー 2. **Context & Key Details**: コンテキストと詳細情報の記録 3. **On Time Completion**: 期日内の完了（Slack 上での非同期実施で負荷軽減） 4. **Follow-up Action Items Tracked to Completion**: 完了までの追跡 5. **Blameless Language**: ブレームレスな言語 6. **Referenceability**: 再参照性（未解決の問題として残る） --- ## 第 IV 部　パラダイムシフト——「修復」から「学習」へ ### 第 10 章　Repeat Incident Fallacy 「このインシデントが二度と起こらないよう……」というポストモーテムの定型結語は、根本的に誤った前提に立つ。[[Emily Ruppe]]（Jeli.io, 2022）はこれを **Repeat Incident Fallacy（再発インシデントの誤謬）** と名づけた（Source: [[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]]）。 Laura Maguire の命題: CI/CD = 継続的変化ゆえに、規模のある複雑社会技術システムで「同一インシデント」は二度と起きない。ジュラシックパーク式の恐竜再生と同程度にありえない。 この認識は 4 人の実践者が独立に収束した同一のパラダイムシフトである。 | 実践者 | 定式化 | |---|---| | **Gallego** (2018) | 修復をポストモーテムの定義に含めない | | **Lund** (2019) | 「このインシデントの再発防止」を会議目標から外す | | **Ruppe** (2022) | Repeat Incident Fallacy | | **Partington** (2022) | learning > fixing | 代替目標として Ruppe が提案するのは **"Insights from the Past = Options in the Future"**——「修復の保証」でなく「選択肢の蓄積」を目標にする。 ### 第 11 章　根本原因・アクションアイテム・MTTx の除外 [[Tom Partington]]（ANZx, 2022）は、根本原因の特定・アクションアイテムの作成・MTTx 指標の追跡をすべて意図的に除外した Post Incident Review（PIR）プロセスを、高度規制産業（金融）・1,000 人超の組織で実践し、**再発インシデントがまれ**であると報告した（Source: [[@2022__SREcon22APAC__A Post Incident Review Review]]）。 Lesson セクションの 5 問は修復を問わず経験的知識の抽出を促す。 1. What surprised us?（何が驚きだったか） 2. What went well?（何がうまくいったか） 3. What was difficult?（何が困難だったか） 4. Where did we get lucky?（どこで幸運だったか） 5. What don't we understand?（何がまだ分かっていないか） これは John Allspaw の「How learning is different from fixing」と同一テーゼを設問構造レベルで具現化したものである。 ### 第 12 章　インシデント法律主義 [[Will Larson]]（Calm CTO）は、プロセスが信頼性でなくコンプライアンスに焦点を移す病理パターンを **Incident Legalism（インシデント法律主義）** と名づけた（Source: [[@ReadME__Will Larson__Move Past Incident Response to Reliability]]）。 症状: - 繰り返しのレビュー質問 - 過度な重篤度分類の議論 - メタデータ収集への過度の注力 - 実行不可能な修復提案の積み上げ 処方: ポストモーテムの数を増やすことではなく、**対応・分析・修復への投資バランス**を是正する。 --- ## 第 V 部　測定——メトリクスの功罪 ### 第 13 章　MTTR 批判と TTX メトリクス MTTR（Mean Time To Recovery）は DORA の 4 指標の 1 つとして広く使われてきたが、モンテカルロシミュレーション（有名インターネット企業 3 社、10 万回）により、各インシデントの修復時間を 10% 短縮しても MTTR が 10% 以上改善されるのは 49〜64% のケースのみと判明した。分布がべき乗則に近く、外れ値 1 件で平均が大きく動くためである（Source: [[TTXメトリクス]]）。 この MTTR 批判は 3 つの異なる立場から一致する。 1. **Davidovič**（Google SRE, 2021）: 定量的シミュレーションで実証 2. **Takamura**（Topotal, 2025）: 日本語圏で展開し TTX 代替指標を体系化 3. **Nash**（Verica, 2023）: 「shallow data」として定性的に批判 代替として TTX メトリクスは、インシデントのライフサイクルを複数フェーズ（TTDetect, TTAcknowledge, TTEngage, TTInvestigate, TTIdentify, TTMitigated, TTFix, TTRecovery）に分解し、改善対象フェーズを特定する。 ### 第 14 章　定量データの限界 ポストモーテムの定量データには構造的な限界がある。 **サンプルサイズの問題**: Byrum（Spotify）は、インシデントデータは統計的相関分析に「非常に問題が多い」——サンプルサイズが小さく母集団が不明——と指摘した。「センサスに近い」アプローチになる（Source: [[インシデント考古学]]）。 **重大性バイアス**: Spotify のポストモーテム完了率は影響度 5 で 100%、影響度 1 で 50%。「重大インシデントほど丁寧に振り返られ、軽微なインシデントは野放しになる」（Source: [[@2023__SREcon23Americas__Incident Archeology - Finding Value in the Paperwork and Narratives of the past]]）。 **数値はコンテキストなしでは意味がない**: 集計値はコンテキストなしで提示すると組織目標に転化しやすく、数値を操作する動機を生む（Source: [[クロスインシデント分析]]）。 --- ## 第 VI 部　発展——個別を超えた学習 ### 第 15 章　インシデントストーリーテリング ポストモーテムの上位概念として、[[インシデントストーリー]]——技術要素のみに焦点を当てた線形記述ではなく、豊かな社会技術的詳細を含む長形式のインシデント記録——がある（Source: [[@2023__SREcon23Americas__Far from the Shallows]]）。 4 つの特性: 1. 豊かな社会技術的詳細（人間・組織・文化・感情的側面を含む） 2. 複数の異なる視点（単一の権威ある記述ではない） 3. テーマとパターンの開示（構造的課題を明らかにする） 4. 全体システムのズームイン/アウト 有用なインシデントストーリーには **anomalous（異常性）** と **immutable（細部の保全）** の 2 条件が必要である。異常性がなければ学習は起きず、細部が失われるとモラルストーリー（単純な blame 話）に退化する（Source: [[@2026__SREcon26Americas__The Power of Stories]]）。 Airbnb の「Once Upon an Incident」（四半期ごと、3 名、キャンプファイア形式、アクションアイテム不要）は組織的ストーリーテリングの場として実証された。古いインシデントでも参加者の関心は持続し、アクションアイテムが過去のものになっても学習価値は残る。 ### 第 16 章　クロスインシデント分析 個別インシデントの学習を超え、複数インシデントを横断して共通パターンを発見する実践がクロスインシデント分析である。[[Vanessa Huerta Granda]]（Enova, 10 年の実践）がスケールに必要な 3 要素を示した（Source: [[クロスインシデント分析]]）。 1. **専任チーム**: インシデントレビューを集中型ローテーションで行い、プロダクト作業との優先度競合を回避 2. **構造化アーティファクト**: 定量フィールドとナラティブな定性フィールドを同一アーティファクトに持つ 3. **組織計画サイクルとの連動**: 四半期計画・年次計画に合わせて分析と推奨事項を提示 **アクションアイテムと推奨事項の分離**が鍵であり、アクションアイテムだけを作り続ける「アクションアイテムファクトリー」は anti-pattern である。 最も重要な単一変革は**部門横断の関係者招待**——エンジニアリングだけでなくオペレーション・マーケティング・法務・コンプライアンスをレビューに招くこと。 ### 第 17 章　インシデント考古学 [[Clint Byrum]]（Spotify, 2023）が提唱した手法。過去のインシデント記録を「アーティファクト」として考古学的に発掘・分析する（Source: [[インシデント考古学]]）。 8 ステップ: (1) アーティファクトの発見 → (2) 時間的コミットの決定 → (3) 仮説の立案 → (4) タイムボックス方法論の設計 → (5) データサイエンティストとの協働 → (6) アーティファクトのリスト化 → (7) データ分析 → (8) まとめ・学習・共有 最重要の発見: **探していなかった知見が最も価値高い**。設定した仮説よりも副産物（起動・終了時刻の 75% がデフォルト放置、業務時間中に 80% 宣言、変更起因は 30% のみ）の方が組織に大きなインパクトをもたらした。 クロスインシデント分析（継続的蓄積・自走プログラム）と考古学（過去遡及・タイムボックス探索）は相補的であり、「まず考古学で現状把握 → プログラムを整備して継続蓄積」という順序で組み合わせられる。 ### 第 18 章　知見のコード化——ポストモーテムから自動防御へ [[藤原俊一郎]]（面白法人カヤック）は「インシデント → ポストモーテム → sre-advisor → 事前検出 → インシデント予防」の閉ループを実践した。ポストモーテムの振り返りから「設定不備が発生要因として多い」という傾向を発見し、その知見を AWS リソース設定の静的チェック CLI（sre-advisor）に書き込んだ（Source: [[@2022__SRENEXT2022__1年間のポストモーテム運用とそこから生まれたツール sre-advisor]]）。 重要な洞察: **チェックシートはトイルであり、エンジニアリングで自動検出すべき**。ポストモーテムで得た設定ベストプラクティスを「リリース前チェックシート」として運用すると、サービスが増えるたびにトイルが発生する。 Ruppe が目標定式として提唱した "Insights from the Past = Options in the Future" を、ツール化によって具体的に実装した事例と見なせる。 --- ## 第 VII 部　インシデント対応の構造 ### 第 19 章　インシデント管理ライフサイクル インシデント管理は **検知 → トリアージ → 診断 → 緩和** の 4 段で処理されるライフサイクルである（Source: [[インシデント管理]]）。 Google SRE の 8 フェーズタイムラインはより細粒度で、Root Cause → Hits Production → Detect → Escalate → Mitigate → Resolve → Retrospect → Action Items を定義する。修正機会は 3 方向に分類される。 1. **STOP**: 根本原因が本番に到達する前に止める 2. **FASTER**: Detect → Mitigate を高速化する 3. **PREVENT and FIX CULTURE**: Resolve 後に予防と学習文化を醸成する #### 緩和フェーズが TTR を支配する クラウド三社（AWS・Azure・Google Cloud）の 354 件のポストモーテム分析では、MTTD=16.9 分・MTTI=77.8 分・MTTM=304.2 分・MTTR=572.8 分。**緩和フェーズが TTR の 53% を占める**（Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]）。 ### 第 20 章　調査戦略——日和見的と体系的 インシデント調査には 2 種の戦略がある（Source: [[インシデント調査戦略]]）。 **体系的戦略**: 症状から根本原因まで段階的に調査する。「なぜ」を繰り返しシステムの挙動の連鎖を追跡するか、テクノロジースタックを層ごとに下る。 **日和見的戦略**: 根本原因に概念的に直接ジャンプしようとする。過去の経験に基づく典型的な原因の確認と、時間的相関のある異常の探索。 実際のインシデント調査では両戦略を組み合わせる。日和見的戦略が調査の出発点をより特定的にし、そこから体系的調査を継続するパターンが多い。相関の発見だけでは不十分で、**因果の理解**が伴わなければ調査は失敗する。 ### 第 21 章　安全工学からの根本原因再定義 [[Laura de Vesine]]（Datadog, 2022）は、安全工学の System/Environment 境界モデルを提案した（Source: [[@2022__SREcon22 EMEA__Principled Identification of Root Causes Using Techniques from Safety Engineering]]）。 - **根本原因 = システムの脆弱性**（自分たちが制御できるもの） - **トリガー = 環境条件**（自分たちが制御できないもの） この整理は「どこに修正を施すべきか」を直接指示する点で、Dekker の哲学的命題「原因は構築される」よりも実用的である。5 Whys の病理——トリガーで止まる傾向——も診断した。 --- ## 第 VIII 部　研究のフロンティア ### 第 22 章　AI とポストモーテムの自動化 Google SRE AI はインシデント対応中の情報を自動集約してポストモーテム下書きを生成するエージェントを運用している。4 種のエージェント（コミュニケーション監視・ハンドオフ文書生成・ポストモーテム下書き・内外コミュニケーション管理）はいずれも人間 IC を置き換えない補助層である（Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]]）。 LLM によるポストモーテム自動生成には以下の課題がある。 - **ヒンドサイトバイアスの模倣**: LLM は事後データ（ログ・アラート）を入力とし、既に「障害が起きた」という結果知識を含む形で分析する。ヒンドサイトバイアスを強化するリスクは未検討（Source: [[ヒンドサイトバイアス]]） - **Cause is something you construct**: Dekker のテーゼに従えば、LLM が生成する RCA は特定のフレームを前提にした構築物。どのフレームが暗黙に選択されているかの検証が必要 - **ブレームレス言語の維持**: 自動生成テキストが規範的言語（should, just, always）を含まないことの保証 ### 第 23 章　定量研究——ポストモーテムをデータソースとして使う ポストモーテムは個別の学習文書であるだけでなく、系統分析のデータソースとしても使われ始めている。 - **クラウド三社分析**: Li+ 2022 は AWS・Azure・Google Cloud の公開ポストモーテムから TTX 値を実測し、設定ミスが最多根本原因（31.6%）であること、9 種の緩和手段分布を定量化した（Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]） - **Google 内部**: SRE Workbook Appendix C はポストモーテムの集計分析から変更起因障害やプロセス失敗の傾向を抽出した - **GQM フィードバックモデル**: [[Sue Lueder]]（Google SRE PM, 2015）は Goal Question Metric → Collect → Organize → Analyze → Socialize の 5 段サイクルを全プロダクション障害に適用した ### 第 24 章　逸脱の正常化——日常のドリフト Diane Vaughan がスペースシャトル Challenger 事故の分析で提唱した概念。既定の許容範囲を超えた状態が繰り返し発生し、「実害がない」として受け入れられることで、逸脱が通常規範として定着していく（Source: [[逸脱の正常化]]）。 SRE の文脈ではアラート閾値の繰り返し緩和が典型例。Hochstein はこれが「私たちが普通にやっていること」であり、特殊な病理ではなく**合理的意思決定の副産物**であることを強調した。 ### 第 25 章　未解決の問い 本教科書が集約した wiki の知見から浮かび上がる未解決の研究課題を以下にまとめる。 **文化と組織** - 日本企業のポストモーテム実践（mixi・Hatena・カヤック）は中小規模の事例。数千人規模でブレームレス文化が定着する条件は何か - ポストモーテムギルド（Rizqi 提案）は組織内スケールの手段として実際に機能するか - ナラティブ型 IR のコスト（時間・スキル）と学習効果のトレードオフ **測定と評価** - ナラティブ型 IR とテンプレート型 IR で「読まれた率」「組織学習への貢献」を定量比較した研究は存在するか - ポストモーテムのアクションアイテム完了率と信頼性改善の相関 - Spotify の 62% という完了率は業界平均と比べてどうか **自動化と AI** - LLM 生成ポストモーテムの品質評価——「ブレームレス記述」と「根本原因の正確な特定」の両立 - LLM はヒンドサイトバイアスを模倣・強化するか。その緩和手法は何か - sre-advisor のような静的チェックと LLM による動的 RCA の組み合わせ方 **方法論** - CAST の大規模マイクロサービスへの適用——コントローラーの粒度と組み合わせ爆発の管理 - Human Factors アプローチ（個別インタビュー → デブリーフィング）の定量的効果検証 - 非同期（Slack）と同期（ミーティング）の適用条件（重大度・チーム規模・心理的安全性の成熟度） --- ## 付録 ### A. 用語集 | 用語 | 定義 | |---|---| | ポストモーテム | インシデント後の非難なき事後振り返り | | ブレームレス | 個人でなくシステムの欠陥に焦点を当てる文化原則 | | ブレーム・アウェア | 非難感情の存在を認めつつ表出させない refinement | | ローカル合理性 | 人はその時点の情報において最善と信じる行動をとる | | ヒンドサイトバイアス | 結果知識が事前の視点再現を妨げる認知的バイアス | | Contributing Factor | 根本原因の代替概念。複数の寄与因子が組み合わさって障害を生む | | Incident Legalism | プロセスが信頼性でなくコンプライアンスに焦点を移す病理 | | Repeat Incident Fallacy | 「同じインシデントの再発防止」が不可能な前提に立つ誤謬 | | CAST | Systems Theory に基づく因果分析手法（Leveson） | | TTX メトリクス | インシデントフェーズ別経過時間指標群（MTTR の代替） | | IR | Incident Report（インシデントレポート） | | PIR | Post Incident Review（インシデント後レビュー） | | 逸脱の正常化 | 許容範囲超過が繰り返し受容され通常化する過程（Vaughan） | ### B. 推奨読書リスト **入門** - Google SRE Book Chapter 15: Postmortem Culture — Learning from Failure - Google SRE Workbook Chapter 10: Postmortem Culture — Learning from Failure - Richard I. Cook: "How Complex Systems Fail" (1998) **実践** - Will Gallego: "Architecting a Technical Post Mortem" (SREcon18 Americas) - Courtney Eckhardt: "Retrospectives for Humans" (SREcon19 Asia/Pacific) - Laura Nolan: "Ditch the Template" (SREcon22 EMEA) - Tom Partington: "A Post Incident Review Review" (SREcon22 APAC) **発展** - Tanner Lund: "A Tale of Two Postmortems — A Human Factors View" (SREcon19 APAC) - Emily Ruppe: "The Repeat Incident Fallacy" (SREcon22 EMEA) - Clint Byrum: "Incident Archeology" (SREcon23 Americas) - Vanessa Huerta Granda: "Learning from Incidents at Scale" (SREcon25 Americas) **研究** - Lorin Hochstein: "The Power of Stories" (SREcon26 Americas) - Courtney Nash: "Far from the Shallows" (SREcon23 Americas) - Ruben Barroso: "The Case of the Misnamed Cities — CAST Analysis" (SREcon26 Americas) - Laura de Vesine: "Principled Identification of Root Causes" (SREcon22 EMEA) ### C. ソースマッピング 本教科書の各章が依拠する wiki ソースの対応表。 | 章 | 主要 wiki ソース | |---|---| | 1-3 | [[ポストモーテム]], SRE Book Ch15, SRE Workbook Ch10 | | 4 | [[事故モデル]], [[CAST]] | | 5-6 | [[複雑システム障害論]], [[人的要因]], [[ヒンドサイトバイアス]] | | 7 | [[レトロスペクティブファシリテーション]] | | 8 | [[インシデントレポート執筆]], [[インシデントストーリー]] | | 9 | [[ポストモーテム]] プロセス比較表 | | 10-12 | [[ポストモーテム]] 横断的知見 | | 13-14 | [[TTXメトリクス]], [[インシデント考古学]] | | 15 | [[インシデントストーリー]] | | 16 | [[クロスインシデント分析]] | | 17 | [[インシデント考古学]] | | 18 | [[ポストモーテム]] カヤック事例 | | 19-20 | [[インシデント管理]], [[インシデント調査戦略]] | | 21 | [[事故モデル]] System/Environment モデル | | 22-24 | [[ポストモーテム]], [[ヒンドサイトバイアス]], [[逸脱の正常化]] |