Operations | Monitoring | ITSM | DevOps | Cloud

Incident.io

A guide to post-mortem meetings and how we run them at incident.io

You've just made it through a particularly tough incident. It was a short outage affecting a subset of customers, so not exactly the end of the world, but bad enough that it involved multiple people across a number of teams to resolve. Either way, the incident was well managed, and the dust has settled. Now what? Most guidance would say that putting together a post-mortem document is a good idea, given the severity of the incident. You've also done this, so what's next?

Whose fault was it anyway? On blameless post-mortems

No one wants to be on the receiving end of the blame game—especially in the wake of a major incident. Sure, you know you were the one who made the final change that caused the incident. And hopefully, it was a small one that didn’t cause any SEV-1s. Still, the weight of knowing you caused something bad should be enough, right? Unfortunately, sometimes fingers get pointed, your name gets called, and suddenly, everyone knows that you’re the person who created more work for everyone.

Incident management vs problem management

The video explores the difference between incident management and problem management in modern organizations. It describes a common scenario where operations teams focus on immediate fixes, like rebooting systems, without addressing the root causes. Once the immediate issue is resolved, these teams pass the incident report to the developers, who are then responsible for digging deeper to prevent future occurrences.