シナリオ
あなたはSaaS企業 Novalite のシニアエンジニアです。昨日発生した P1 インシデント（決済サービスの503エラー、約40分のダウンタイム）の対応が完了し、今日は正式な ポストモーテムドキュメント（Postmortem Report） を英語で作成して GitHub に PR します。
postmortems/2026-06-11-payment-service-p1.md
Draft PR
このドキュメントはエンジニアリングチーム全員、PM（Sarah）、および将来の担当者が参照します。自己完結した記述にすること。
あなた
Senior Engineer（インシデントコマンダー）
ポストモーテムドキュメントの作成者。昨日のインシデント対応を主導した
読み手
エンジニアリングチーム全員 + PM Sarah
技術者と非エンジニアが混在。将来の担当者も含む
重要なコンテキスト
Blameless Postmortem
「誰が悪いか」ではなく「システムと手順の何が失敗を許したか」にフォーカスする。Lessons Learned は人を主語にしない
「誰が悪いか」ではなく「システムと手順の何が失敗を許したか」にフォーカスする。Lessons Learned は人を主語にしない
自己完結した記述
1年後に初めて読む人が文脈なしで理解できるよう書く。略語・固有名詞は初出時に説明を添える
1年後に初めて読む人が文脈なしで理解できるよう書く。略語・固有名詞は初出時に説明を添える
Action Items は必ず Owner + Due
"We will improve monitoring" は行動アイテムとみなされない。担当者と期限が揃って初めてコミットメントになる
"We will improve monitoring" は行動アイテムとみなされない。担当者と期限が揃って初めてコミットメントになる
タスク
以下のインシデント情報をもとに、英語のポストモーテムドキュメント（300〜450語） を書いてください。Markdownの見出し・箇条書き・テーブルを使って構造化すること。
含める要素 1
Incident Summary（3〜4文）
いつ・何が・どの程度の影響があったか・いつ解決したかを簡潔に記述する
含める要素 2
Timeline（時刻付き箇条書き）
10:45 / 10:52 / 11:10 / 11:25 AM JST の4点を含める
含める要素 3
Root Cause（技術的詳細）
payment-service v2.4.1 のメモリリークが根本原因。Kubernetes の OOM Killer による pod クラッシュの技術的連鎖を説明すること含める要素 4
Contributing Factors（2点）
障害を悪化・見逃しさせた要因: ① アラート閾値が高すぎた（85%） ② デプロイチェックリストにロードテストがなかった
含める要素 5
Action Items（担当者・期限付き3点）
① メモリアラート閾値を70%へ変更（Kevin / 今週金曜） ② ロードテストをデプロイチェックリストに追加（あなた / 来週末） ③ canary デプロイ導入（あなた + Alex / Q3）
含める要素 6
Lessons Learned（2点）
「システムと手順」の観点で書く。人ではなくシステムを主語にすること
Report/Doc × Engineering 必須語彙
カードをクリックすると日本語訳と例文を表示します。
blameless postmortem
クリックで詳細を表示 →
非難なしの事後検証
💡 冒頭に "This is a blameless postmortem." を置くことで文化的前提を明示。Google SRE の標準慣行
contributing factor
クリックで詳細を表示 →
寄与因子（直接原因ではなく悪化・見逃しに貢献した要因）
💡 Root Cause との区別が重要。"The alert threshold was a contributing factor." — 直接原因ではない要素
OOM killer
クリックで詳細を表示 →
Out-Of-Memory Killer — Linuxのメモリ超過時に強制終了するカーネル機能
💡 Kubernetes 環境で memory leak が pod crash につながるメカニズムの説明に必須
MTTR
クリックで詳細を表示 →
Mean Time To Recover — 障害復旧までの平均時間
💡 "Our MTTR for this incident was 40 minutes." — SRE/SLO の文脈で標準的に使われる指標
blast radius
クリックで詳細を表示 →
影響範囲（直訳: 爆発半径）
💡 "canary deployments limit blast radius" — 問題が広がる前に影響を局所化する概念
prevent recurrence
クリックで詳細を表示 →
再発防止
💡 ポストモーテムの目的を述べる定番フレーズ。"prevent this from happening again" より簡潔
downstream
クリックで詳細を表示 →
下流で（システムの後続コンポーネントや影響先）
💡 "503 errors downstream" — pod crash がユーザー側に伝播する様子を一言で表す
calibrated against
クリックで詳細を表示 →
～に基づいてキャリブレーション（調整）された
💡 "Thresholds must be calibrated against failure patterns." — 設定が根拠を持つべきという意味を含む
ヒント（段階的開示）
ヒント 1 — 構成・方向性
- 6セクション構成を守る: Summary → Timeline → Root Cause → Contributing Factors → Action Items → Lessons Learned。この順番は「事実 → 原因 → 改善」の3層構造で、読み手が必要な部分だけ読めるように設計されている
- 時制は過去形で統一: "The service began returning 503 errors..." など。Action Items のみ現在・未来形が混在してよい
- Lessons Learned の主語はシステムや手順: "The alert threshold was too high" / "The checklist lacked a load test step" — 人を主語にしない
- 冒頭に blameless 宣言を置く: ブロック引用（>）を使って "This is a blameless postmortem..." を入れると、読み手の心理的安全性を確保できる
ヒント 2 — キーフレーズ
"This is a blameless postmortem. Our goal is to understand what happened and prevent recurrence.""The root cause was a memory leak introduced in the v2.4.1 release of payment-service.""The leak caused the pods to steadily consume memory until they hit their limit and were killed by the Kubernetes OOM killer.""The alert threshold was set at 85%, allowing the memory to creep up undetected.""A load test would have surfaced this memory growth pattern in staging.""Monitoring thresholds must be calibrated against failure patterns, not arbitrary percentages."
ヒント 3 — 骨格
## Incident Summary
On [date], [service] experienced a P1 outage caused by [root cause].
The service returned [error] from [time] to [time], affecting ~[N] users.
Service was restored via [action].
## Timeline (All times JST)
- [time] — [what happened]
- [time] — [incident declared]
- [time] — [root cause identified]
- [time] — [resolved]
## Root Cause
The root cause was [technical description]. This caused [pods/service] to [effect].
## Contributing Factors
1. [Alert/monitoring gap]
2. [Process/checklist gap]
## Action Items
| # | Action | Owner | Due |
|---|--------|-------|-----|
| 1 | ... | ... | ... |
| 2 | ... | ... | ... |
| 3 | ... | ... | ... |
## Lessons Learned
1. [System/threshold insight — system as subject]
2. [Process/checklist insight — process as subject]
モデル解答
postmortems/2026-06-11-payment-service-p1.md
Resolved
Incident Summary
This is a blameless postmortem. Our goal is to understand what happened and prevent recurrence — not to assign blame.
On June 11, 2026, our payment-service experienced a P1 outage caused by a memory leak introduced in the v2.4.1 release. The service began returning 503 Service Unavailable errors at approximately 10:45 AM JST, making it impossible for users to complete checkout. Approximately 1,200 users were affected over a 40-minute window. Service was fully restored at 11:25 AM JST via a rollback to v2.4.0.
Timeline (All times JST)
- 10:45 AM
payment-servicepods started crashing in production; 503 errors began spiking in Datadog. - 10:52 AMOn-call engineer declared a P1 incident and looped in the backend team.
- 11:10 AMKevin Park identified the root cause: a memory leak in the v2.4.1 release deployed the previous day.
- 11:25 AMRolled back to v2.4.0 and restarted pods. Checkout flow fully restored. Incident resolved.
Root Cause
The root cause was a memory leak in a new feature shipped as part of the v2.4.1 release. The leak caused the payment-service pods to steadily consume memory until they hit their limit and were killed by the Kubernetes OOM killer, resulting in repeated pod crashes and 503 errors downstream.
Contributing Factors
Factor 1
Alert threshold too high
Our memory usage alert was set at
85%. The leak caused a gradual climb that crossed 90% before we were alerted — by which point the pods were already crashing. An earlier threshold (e.g., 70%) would have allowed preventive action before users were impacted.Factor 2
No load test in deploy checklist
The v2.4.1 feature was not load-tested before shipping to production. A load test would have surfaced the memory growth pattern in a staging environment, preventing the issue from reaching users.
Action Items
| # | Action | Owner | Due |
|---|---|---|---|
| 1 | Lower memory alert threshold from 85% to 70% | Kevin Park | 2026-06-13 |
| 2 | Add load testing step to the production deploy checklist | You | 2026-06-19 |
| 3 | Scope and plan canary deployment strategy to limit blast radius on future releases | You + Alex Kim | Q3 2026 |
Lessons Learned
Lesson 1
Monitoring thresholds must be calibrated against failure patterns, not arbitrary percentages.
The alerting system was configured for "high usage" but not for "gradual creep toward failure." Reviewing and tightening alerting thresholds should be part of the regular on-call review cycle.
Lesson 2
The deploy checklist is a system control, not a formality.
Load testing was an optional step. This incident shows it must be mandatory for any service touching the payment flow. Checklists only prevent failures when they are enforced.
キー表現ハイライト
"This is a blameless postmortem." — 冒頭に置いて文化的前提を宣言する
"killed by the Kubernetes OOM killer" — メモリリークからpodクラッシュへの技術的連鎖を正確に表現
"contributing factor" — Root Cause と区別した「寄与因子」の専門語
"calibrated against failure patterns" — 閾値設定の根拠を示す洗練した表現
"The checklist is a system control, not a formality." — Blameless 文化を体現した人ではなくシステムを主語にした表現
解説
構成分析
1
Blameless 宣言を冒頭に置く
引用ブロック（>）を使って "This is a blameless postmortem." を文書の最初に置くことで、読み手は「責任追及のドキュメントではない」と理解し、心理的安全性を持って読める。この1文がなければ、エンジニアは自分のミスを隠すように書き始める可能性がある。
引用ブロック（>）を使って "This is a blameless postmortem." を文書の最初に置くことで、読み手は「責任追及のドキュメントではない」と理解し、心理的安全性を持って読める。この1文がなければ、エンジニアは自分のミスを隠すように書き始める可能性がある。
2
Root Cause と Contributing Factors を分ける
Root Cause（根本原因）はメモリリーク1点。Contributing Factors（寄与因子）は「なぜ問題が検知・防止できなかったか」のシステム的・プロセス的要因。この2つを混在させると「何が一番の問題だったか」が不明瞭になる。上手なポストモーテムはこの分離が明確。
Root Cause（根本原因）はメモリリーク1点。Contributing Factors（寄与因子）は「なぜ問題が検知・防止できなかったか」のシステム的・プロセス的要因。この2つを混在させると「何が一番の問題だったか」が不明瞭になる。上手なポストモーテムはこの分離が明確。
3
Action Items はテーブル形式で Owner + Due をセットに
Action Items をテーブルで書くと、後からフォローアップするときに担当者と期限を即座にスキャンできる。"We will improve monitoring." では誰も動かない。"Owner: Kevin | Due: 2026-06-13" という形式によって初めてコミットメントとして機能する。
Action Items をテーブルで書くと、後からフォローアップするときに担当者と期限を即座にスキャンできる。"We will improve monitoring." では誰も動かない。"Owner: Kevin | Due: 2026-06-13" という形式によって初めてコミットメントとして機能する。
4
Lessons Learned はシステムを主語にする
"An engineer forgot to add a load test" ではなく "The deploy checklist lacked a load test step" と書く。前者は個人を責め、後者はシステムと手順を改善対象にしている。これがblamelessの言語的実践で、組織の心理的安全性を維持しながら継続的改善を実現する。
"An engineer forgot to add a load test" ではなく "The deploy checklist lacked a load test step" と書く。前者は個人を責め、後者はシステムと手順を改善対象にしている。これがblamelessの言語的実践で、組織の心理的安全性を維持しながら継続的改善を実現する。
重要表現
| 英語表現 | 日本語 | ポイント |
|---|---|---|
blameless postmortem | 非難なしの事後検証 | 文化的前提を宣言するフレーズ。Google SRE Book に由来 |
OOM killer | メモリ超過時の強制終了機能 | Kubernetes + memory leak の文脈で必須の技術用語 |
contributing factor | 寄与因子 | Root Cause との区別が重要。直接原因ではない要素 |
downstream | 下流で | エラーがユーザー側に伝播する様子を一言で表す |
calibrated against | 〜に基づいて調整された | 設定が根拠を持つべきというニュアンスを含む洗練した動詞句 |
not a formality | 形式的なものではない | 「意味のある手順を守れ」という強調。"should be taken seriously" より鋭い |
文化的ポイント
Blameless の言語的実践
英語でblameless を体現するには「人ではなくシステム・手順を主語にする」言語技術が必要。"The checklist is a system control" という抽象化がその例。日本語のポストモーテムは往々にして「○○さんが確認を怠り」と書いてしまいがち。
英語でblameless を体現するには「人ではなくシステム・手順を主語にする」言語技術が必要。"The checklist is a system control" という抽象化がその例。日本語のポストモーテムは往々にして「○○さんが確認を怠り」と書いてしまいがち。
定量化が信頼性を上げる
英語技術文書では数値を使った記述が評価される。"~1,200 users" / "85% threshold" / "40-minute window" のように定量化することで、文書が具体的かつ客観的になる。曖昧な "many users" や "some time" は避ける。
英語技術文書では数値を使った記述が評価される。"~1,200 users" / "85% threshold" / "40-minute window" のように定量化することで、文書が具体的かつ客観的になる。曖昧な "many users" や "some time" は避ける。
自己完結した記述の原則
ポストモーテムは「1年後に初めて読む人」を想定して書く。略語は初出時に展開し（OOM = Out-Of-Memory）、コンテキストを自己完結させることで、ドキュメントが組織の知識資産として長期間機能する。
ポストモーテムは「1年後に初めて読む人」を想定して書く。略語は初出時に展開し（OOM = Out-Of-Memory）、コンテキストを自己完結させることで、ドキュメントが組織の知識資産として長期間機能する。
よくある日本人のミス
❌ "We are deeply sorry for the inconvenience this incident caused." で始める
ポストモーテムは謝罪文書ではなく、技術的な記録と改善計画の文書。Blameless 宣言から始める
→
✅ "This is a blameless postmortem. Our goal is to understand what happened and prevent recurrence."
❌ "An engineer deployed v2.4.1 without proper testing, which caused the memory leak."
人を主語にするのは Blameless に反する。チームが萎縮し、次回の障害報告が不誠実になるリスクがある
→
✅ "The deploy checklist lacked a mandatory load test step." — システムと手順を主語にする
❌ Action Items: "We will try to improve our monitoring and add more tests in the future."
"try to" / "in the future" は期限のないコミットメントで、フォローアップ不可能。行動アイテムとして機能しない
→
✅ "Lower memory alert threshold to 70% | Owner: Kevin Park | Due: 2026-06-13"
❌ Root Cause と Contributing Factors を混在させる: "The cause was the memory leak and also the alert was too high and the checklist was incomplete."
原因の分類が不明確で、どれが一番の問題か読み手に伝わらない
→
✅ Root Cause（1点）と Contributing Factors（複数点）を別セクションで明確に分ける
❌ Lessons Learned を Summary の繰り返しにする: "We learned that the payment service was down for 40 minutes due to a memory leak."
Summary との違いがない。Lessons Learned は「構造的洞察」を書く場所
→
✅ "Monitoring thresholds must be calibrated against failure patterns." — 将来の設計に活かせる洞察
ワンランク上の表現（Phase 3 以降）
Basic
"The payment service went down. The cause was a bug. We fixed it and will be more careful next time."
↓ B2 レベルでは
B2
Structured document with Summary / Timeline / Root Cause / Contributing Factors / Action Items (Owner + Due) / Lessons Learned. Blameless framing. System as subject in Lessons Learned.
↓ C1 レベルでは（定量化 + Impact Assessment + MTTR 分析を追加）
C1
Impact Assessment table (Duration / Affected users / GMV loss / Error rate peak)
Detection & Response table (Detection: 7 min / Diagnosis: 18 min / Recovery: 15 min / Total MTTR: 40 min)
"Our MTTR of 40 minutes is above our SLO target of 30 minutes. The 18-minute diagnosis phase represents our biggest opportunity for improvement — a pre-built runbook for memory-related incidents would have reduced this to under 5 minutes."
Detection & Response table (Detection: 7 min / Diagnosis: 18 min / Recovery: 15 min / Total MTTR: 40 min)
"Our MTTR of 40 minutes is above our SLO target of 30 minutes. The 18-minute diagnosis phase represents our biggest opportunity for improvement — a pre-built runbook for memory-related incidents would have reduced this to under 5 minutes."
※ C1表現のポイント: ① Impact を GMV・エラー率で定量化 ② MTTR をフェーズ別に分解して改善余地を特定 ③ SLO との対比で組織目標との乖離を可視化 ④ Runbook 言及で具体的な改善手段を示す
次のステップ
- 発展: このポストモーテムを元に、ステークホルダー（CEO・顧客）向けの簡潔な障害報告メールを書く（Email × Engineering）
- さらに発展: Runbook（インシデント対応手順書）を英語で作成する（Report × Engineering 応用）
- 次回予告: Day 060 — Conversation × Engineering（Phase 2）
自己評価（解いた後に記入）
理解度
自分の回答
ポストモーテムドキュメント全文（300〜450語）