incident-postmortem

インシデントのポストモーテム

本番環境のインシデント後に、チームが構造化された、誰も責めないポストモーテムを作成できるよう導きます。出力されるドキュメントは、共通理解を深め、責任を追及せずに根本原因を特定し、再発防止に向けた具体的なアクションアイテムを作成します。

誰も責めない原則

失敗するのはシステムであり、人ではありません。目的は、インシデントを引き起こした「誰か」ではなく、インシデントがどのように発生したかを理解することです。「X が忘れた」「Y は知っているべきだった」のような表現は避けてください。「システムが対応できなかった」「プロセスに不足があった」「アラートが発報しなかった」のように記述します。

使用するタイミング

• 本番環境の停止やサービスの品質低下が解決した
• 重大なニアミスが発生した（発見が遅れていればインシデントになっていた）
• ユーザーに影響するエラー、データ損失、SLA 違反が発生した
• コンテキストが薄れる前に、チームで学びを記録したい

対象外： ステージングで発見された軽微なバグ、計画済みのメンテナンス時間、学びにつながる要素のないインシデント。

入力要件

ポストモーテムを書く前に、以下の詳細を集めます。不足している情報があれば質問してください。

インシデントのメタデータ

• インシデントのタイトル（簡潔で内容がわかるもの）
• 検知日時（タイムゾーンを含む）
• 解決日時
• 深刻度／影響レベル（P1～P4 または同等のもの）
• インシデントコマンダー／オンコール担当者

影響

• 影響を受けたサービスとシステム
• ユーザーへの影響（エラー、応答の遅延、完全停止）
• 影響を受けたユーザー数の推定
• データの損失または破損（あり／なし、範囲）
• SLA/SLO 違反（あり／なし、違反の程度）

タイムラインのイベント

再構成する主な時点：

• 最初の兆候が発生した
• アラートが発報した（または手動で気づいた）
• オンコール担当者にページが送られた／インシデントが宣言された
• 調査を開始した
• 根本原因を特定した
• 緩和策を適用した
• 完全な解決を確認した
• 顧客への連絡を送信した（該当する場合）

寄与要因

チームには「何が原因で、事態が必要以上に悪化しましたか？」と尋ね、「誰が失敗しましたか？」とは尋ねないでください。例：

• アラートのしきい値が高すぎた／アラートが発報しなかった
• ランブックがなかった、または古くなっていた
• デプロイにロールバック用のフィーチャーフラグがなかった
• 監視がこの障害モードをカバーしていなかった
• オンコールの引き継ぎでコンテキストが共有されなかった

プロセス

ステップ 1 — メタデータを集める

ユーザーからインシデントの詳細がすべて提供されていない場合は、セクションごとに質問してください。タイトル、時刻、深刻度、影響を受けたサービス、少なくとも大まかなタイムラインを把握するまでは、執筆に進まないでください。

ステップ 2 — タイムラインを再構成する

ユーザーと協力して、正確な時系列のタイムラインを作成します。各イベントについて、以下を記録します。

• 正確な時刻（UTC を推奨）
• 起きたこと（システムイベントまたは人の行動）
• 誰が観測したか、または行動したか
• ログ／アラート／Slack メッセージへのリンク（あれば）

空白を指摘してください：「14:32 から 14:47 の間に何が起きたかわかりません。ログを確認する価値があります。」

ステップ 3 — 根本原因の分析

**なぜなぜ分析（5 Whys）**を繰り返し使います。

Why did users see 500 errors?
→ The API pods were crash-looping.

Why were they crash-looping?
→ Memory limit was exceeded.

Why was the limit exceeded?
→ A new query was loading full result sets into memory.

Why wasn't this caught before deploy?
→ Load tests only covered the p50 case, not high-cardinality accounts.

Why did load tests only cover p50?
→ We had no test fixtures for large accounts.

修正可能なシステムやプロセスの不足にたどり着いたら、そこで止めます。最後の「なぜ」は、アクションアイテムにつながるものでなければなりません。

以下を区別します。

• 根本原因 — 最も深いシステム上の不足（1 つまたは 2 つ）
• 寄与要因 — 事態を悪化させたものの、根本原因ではない条件

ステップ 4 — 影響を定量化する

ユーザーが正確に記述できるよう支援します。

• 期間：検知から解決まで（兆候の発生から解決までの時間とは分けて記録します）
• ピーク時のエラー率と通常時の基準値
• 影響を受けたトラフィックの割合
• 判明している場合は、収益／ビジネスへの影響

ステップ 5 — アクションアイテム

各根本原因と寄与要因について、少なくとも 1 つのアクションアイテムを作成します。

#	アクション	担当者	期限	優先度
1	1 万件を超えるレコードを持つアカウント用の負荷テストフィクスチャを追加する	@eng-team	2026-07-01	高
2	メモリアラートのしきい値を 90% から 75% に下げる	@platform	2026-06-23	高
3	メモリ不足で OOM になった Pod 用のランブックを追加する	@on-call-rotation	2026-06-30	中

アクションアイテムには、担当者（チームではなく個人）と期限を設定する必要があります。「監視を改善する」のような曖昧なアクションは認められません。具体的な成果物に分解してください。

ステップ 6 — ドキュメントを書く

以下のテンプレートを使用して、ポストモーテム全体を作成します。docs/postmortems/YYYY-MM-DD-<slug>.md に保存してください。

出力テンプレート

# Post-Mortem: [Incident Title]

**Date:** YYYY-MM-DD  
**Severity:** P[1-4]  
**Duration:** X hours Y minutes (HH:MM UTC – HH:MM UTC)  
**Incident Commander:** @name  
**Status:** Resolved

---

## Summary

[2–3 sentences. What happened, what was the user impact, how was it resolved. Written for someone who wasn't involved.]

## Impact

| Dimension | Value |
|-----------|-------|
| Affected services | [list] |
| User-facing impact | [errors / degraded / full outage] |
| Users affected | [estimated number or %] |
| Peak error rate | [X% vs Y% baseline] |
| Data loss | [none / describe scope] |
| SLA breach | [yes/no — by how much] |

## Timeline

All times UTC.

| Time | Event |
|------|-------|
| HH:MM | [First symptom / alert fired] |
| HH:MM | [On-call paged] |
| HH:MM | [Incident declared] |
| HH:MM | [Root cause identified] |
| HH:MM | [Mitigation applied] |
| HH:MM | [Full resolution confirmed] |
| HH:MM | [Customer communication sent] |

## Root Cause

[1–2 paragraphs. The deepest systemic gap that, if fixed, would have prevented the incident. Written in blameless language. Reference the 5 Whys chain if helpful.]

## Contributing Factors

- [Factor 1 — condition that made the incident worse]
- [Factor 2]
- [Factor 3]

## What Went Well

- [Thing that worked — good alert, fast response, clear runbook]
- [Another positive]

## What Could Have Gone Better

- [Gap in process, tooling, or coverage — no blame language]
- [Another gap]

## Action Items

| # | Action | Owner | Due Date | Priority |
|---|--------|-------|----------|----------|
| 1 | [Specific deliverable] | @person | YYYY-MM-DD | High/Medium/Low |
| 2 | | | | |

## Lessons Learned

[Optional. 2–4 bullet points capturing non-obvious insights worth sharing with the broader team.]

よくある間違い

間違い	修正
「Bob が設定の確認を忘れた」	「デプロイチェックリストに設定の検証が含まれていなかった」
根本原因が「人的ミス」である	なぜかを問い続けます。人的ミスは常に症状です
担当者のいないアクションアイテム	すべての項目に、チームではなく個人の名前を指定する必要があります
記憶をもとにタイムラインを再構成する	記述する前に、ログ、アラート、Slack、PagerDutyを確認します
アクションとして「モニタリングを改善する」とする	対象のサービス、メトリクス、しきい値、期限を具体的に指定します
数週間後にポストモーテムを書く	状況をよく覚えているうちに、48～72時間以内に作成します