Postmortem

Date

Version

Changes

Date

Version

Changes

2022-04-12

v1.0.0

 

The purpose of a postmortem is for the organization to avoid reoccurrence of incidents, and to become better at managing new incidents.

1.1 Every incident MUST be followed up with a postmortem.

2 Incident Management

Details on incident management can be found in the Incident Playbook and Incident Response Workflow. These details are important for the postmortem.

2.1 Once an outage is considered an incident, an incident manager MUST be assigned.

2.2 The incident manager SHOULD make sure that events and correspondence is documented for the postmortem timeline.

3 Retrospective

Please see the Postmortem Template for an idea on how to conduct the retrospective, find the correct questions to ask, and find viable outcomes.

3.1 The retrospective meeting MUST occur after the incident has been resolved, and SHOULD occur no more than a week hence.

3.2 The retrospective SHOULD include people reporting the incident, responding to the incident, system owners, users and stakeholders.

3.3 Participants in the retrospective SHOULD prepare a timeline of events during the incident. Everyone’s timeline will be merged into a complete timeline during the retrospective.

3.4 The retrospective SHOULD be facilitated by a professional facilitator that has not been involved in the incident and has no stake in its outcome.

3.5 The retrospective MUST be conducted as a blameless postmortem. It is not constructive to point out someone responsible for the incident. The blameless postmortem seek to find a root cause and make sure the incident won’t reoccur.

3.6 Participants MUST NOT take responsibility for the incident during the retrospective. It is not constructive and serves only as impediment in finding the root cause.

3.7 The retrospective MUST result in a list of actions, people responsible for conducting those actions, and a deadline when those actions must have been carried out. When actions has been completed, a reoccurrence of the incident should no longer be plausible.

4 Aftermath

The hardest part of a postmortem is for the organization to learn from the incident. Beyond the people that were involved, learnings must become rooted in system and routine, to avoid reoccurrence even after people involved have left.

4.1 After the retrospective, the facilitator MUST create a report that is reviewed by the incident manager and then made available for the whole organization.

4.2 Actions from the retrospective SHOULD be prioritised over planned work.

4.3 KPIs from the postmortem SHOULD be followed up upon the next retrospective, to make sure that we improve in our incident management.