118 lines
2.6 KiB
Markdown
118 lines
2.6 KiB
Markdown
# Postmortem — Template
|
|
|
|
Use for incident write-ups. The structure follows the standard blameless
|
|
format: what happened, what was supposed to happen, why it didn't, what we
|
|
change.
|
|
|
|
## Sections
|
|
|
|
- Summary (two or three sentences: who was affected, for how long, by what)
|
|
- Impact (the numbers: users, requests, dollars, internal teams)
|
|
- Timeline (UTC timestamps, one row per significant event)
|
|
- Root cause (the chain of decisions and conditions that produced the
|
|
incident; not a single "the bug")
|
|
- Detection (how we found out, and how long after it started)
|
|
- Response (what we did, what worked, what didn't)
|
|
- Recovery (what we did to get back to a steady state)
|
|
- Lessons (the things we want to remember)
|
|
- Action items (table with owner, due date, status)
|
|
- Related (links to the incident ticket, runbook, and follow-up docs)
|
|
|
|
## Anti-patterns
|
|
|
|
- Don't assign blame. The postmortem is about the system, not the person.
|
|
- Don't hide the timeline. The reader's first question is "how long"; the
|
|
timeline is the answer.
|
|
- Don't list action items without owners. An action item without an owner
|
|
is a wish.
|
|
|
|
## Storage template
|
|
|
|
```xml
|
|
<h1>{Incident title — short, dated}</h1>
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<th>Date</th>
|
|
<td>{YYYY-MM-DD}</td>
|
|
</tr>
|
|
<tr>
|
|
<th>Severity</th>
|
|
<td>{SEV-1 / SEV-2 / SEV-3}</td>
|
|
</tr>
|
|
<tr>
|
|
<th>Duration</th>
|
|
<td>{start} → {end} (UTC)</td>
|
|
</tr>
|
|
<tr>
|
|
<th>Incident commander</th>
|
|
<td>{name}</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h2>Summary</h2>
|
|
<p>{two or three sentences}</p>
|
|
|
|
<h2>Impact</h2>
|
|
<ul>
|
|
<li>{users affected}</li>
|
|
<li>{requests failed / throttled}</li>
|
|
<li>{internal teams paged}</li>
|
|
</ul>
|
|
|
|
<h2>Timeline (UTC)</h2>
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<th>Time</th>
|
|
<th>Event</th>
|
|
</tr>
|
|
<tr>
|
|
<td>{HH:MM}</td>
|
|
<td>{event}</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h2>Root cause</h2>
|
|
<p>{chain of decisions and conditions}</p>
|
|
|
|
<h2>Detection</h2>
|
|
<p>{how we found out, and how long after the incident started}</p>
|
|
|
|
<h2>Response</h2>
|
|
<p>{what we did}</p>
|
|
|
|
<h2>Recovery</h2>
|
|
<p>{how we got back to steady state}</p>
|
|
|
|
<h2>Lessons</h2>
|
|
<ul>
|
|
<li>{lesson}</li>
|
|
</ul>
|
|
|
|
<h2>Action items</h2>
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<th>Action</th>
|
|
<th>Owner</th>
|
|
<th>Due</th>
|
|
<th>Status</th>
|
|
</tr>
|
|
<tr>
|
|
<td>{action}</td>
|
|
<td>{owner}</td>
|
|
<td>{YYYY-MM-DD}</td>
|
|
<td>{OPEN / DONE}</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
```
|
|
|
|
## Cross-references
|
|
|
|
- Storage macros: `confluence-page/references/macros.md`
|
|
- BASS / AVP page hierarchy — see the owning team's incident process doc
|