In the post-mortems I've taken part in, one of the components of the report is:
What happened, and when did it happen?
Which includes a timeline. Timelines are incredibly useful for debugging process faults and providing context to people reading it long after it happened. Since humans are responding to whatever happened (if not kicked it off entirely), there will be references to humans in it. However, indirections that mention a role like an operations engineer are preferred.
Depending on the severity of the incident undergoing review, there may be chat-logs, tickets, and code-commits attached to the post-mortem as artifacts. Those will by definition name-names. The point of the blameless post-mortem is to keep the tone of it from assigning blame directly, and to avoid where possible assigning it indirectly. Indirect blaming is entirely cultural, though.
You can't stop people from assigning blame in their heads, but you can avoid assigning blame in the report. Also, by not including extensive membership in the post-mortem archive during performance reviews. If someone wants to assign blame, make them work for it.
The other area where names sometimes come up in the report itself is in the short and long descriptions of what happened.
NAME merged to master before authorized, triggering a CD pipeline. While attempting to prevent the unauthorized change from reaching production, NAME caused the CD system to be mistakenly recycled stopping all deploy pipelines for six hours.
Which is clearly blamey. Compare this to:
A Release Manager merged to master before authorized, triggering a CD pipeline. The mistake was realized immediately. While attempting to prevent the change from deploying, the CD system was destroyed by accident. Restoration by the CD team took six hours.
A certain kind of nerd will notice that this is very passive-voice. You can tell those nerds that this is very much intentional. Passive-voice has been the voice of deflecting blame for a very long time now, so go ahead and passive it up.
Mistakes were made.
Yes, indeed. And which nebulous, not well defined people were involved in this?
A Release Manager.
Doing what, vaguely?
Merging to the master branch of a project.
And what, unspecifically, did they do in response to this?
Broke the deploy system.
What, generally, was the impact of this?
The deploy pipleine system was unavailable for a period of about six hours.
And how was this rectified?
The CD team rebuilt the pipelines.
Very good. Now give me some action items.
- A process should be put in place to prevent merges to master before authorization.
- A circuit-breaker should be introduced in the deploy pipelines to allow a build to be safely blocked.