Hacker News Reader

Comment by spankibalt | Hacker News Reader

> The “blameless” aspect is crucial: a good postmortem avoids conclusions like “Dan wrote a bug and it brought down our service” and instead says “Dan wrote a bug and it brought down the service: we need to improve our testing and deployment processes to make sure that they catch this category of bugs in the future.”

The offending dog's name is still there...

View on HN

As it should be. The purpose of post mortems is to prevent future incidents, and obscuring the facts of what happened by removing names detracts substantially from clarity of understanding and, therefore, defeats the point.

There are two important things that make something blameless: phrasing and culture. If you've phrased something in such a way that there's a clear value judgement, your phrasing isn't blameless. And if you're writing in a culture where, no matter how precise the phrasing, the simple existence of a name will make people blame them for what happened, then your culture isn't blameless. Both are required for a blameless post mortem.

Also, think of it this way: no amount of anonymization will prevent the people involved from knowing who did what. If they're privately blaming the person for the incident, it's still not a blameless post mortem.

No amount of verbal wallpaper can fix a broken culture.

The blameless aspect of post mortem's is paradoxical. I agree with the sentiment but at the end of the day, somewhere in there, the blame is placed on one or two human made oversights or errors. If the conclusion of the PM is "This error was caused when <This PR> was submitted", then everyone's natural instinct is to go look at who authored the PR.

I guess aiming for blameless is as good as it gets sometimes.

I've always seen it as specifically being blameless of individuals. E.g. it's ok for blameless post mortems to find faults in systems, but ideally not the people that use them.

Reply on news.ycombinator.com