A Postmortem Template for Nettle
Postmortem: YYYY-MM-DD - Incident
Postmortem Owner: John Doe | Incident Runner: Jane Doe
Start Time: YYYY-MM-DD HH:MM:SS TZ | End Time: YYYY-MM-DD HH:MM:SS TZ | Duration:
Postmortem Review Date: Today’s date | Postmortem Verification Date: Future Date of Verification Meeting
Executive Summary
Cover in this section what happened, why it happened, how long was the outage, what fixed it and what the action items are.
A post-mortem review is done in 2 meetings - one when the Postmortem is reviewed and discussed to figure out the right root cause (owner: Postmortem-lead or delegate) and two when the implementation of the AIs from the Postmortem are verified as implemented and deployed to production (owner: SRE-lead or delegate). The second meeting should happen no later than 1-2 weeks from the postmortem review date. The process of a postmortem needs to be tracked in a ticket. The first item of the post-mortem review meeting is to schedule the verification meeting and ticket.
Verification
Review Meeting Date: YYYY-MM-DD T HH:MM:SS
Review Meeting Scheduled? Yes / No - please schedule the meeting right now
Review Meeting Owner:
Review Meeting Verification Ticket:
Timeline
The timeline must begin with the first related change that impacted whatever happened in production. The timeline should end with the last remediation step at which 100% recovery was verified. In between, identify changes to cluster metrics and monitoring that were observed and how the team made changes.
Incident Statistics
5-Whys
We run blameless postmortems. Please indicate factually why something happened with a reference to the actual defect or symptom. Reference commits, deploys and manual changes. It is ok and encouraged to mention people as long as it’s in the right spirit and in a neutral tone. We provide trust by default, psychological safety and generate helpfulness in this process. Our goal is continuous improvement.
App.nettle.llc went down. Why?
Because build B was deployed
Why?
Because commit C included a bug in feature X.
Why?
Because issue C was not detected by person P as part of the build process.
Why?
Because E was not functional
Why?
Because missing test E
Remediation Action Items and Owners
Focus on remediation items that will prevent the incident from happening again.
All remediation items will be expected fixed by the review meeting. Postmortem owner owns the responsibility of ensuring completion of the action items before the review meeting.
Comments
Post a Comment