John Allspaw applied concepts from The Field Guide to Understanding Human Error to software post mortems. When I was at Etsy, he taught a class explaining this whole concept. We read the book and discussed concepts like the Fundamental Attribution Error.

I've found it very beneficial, and the concepts we learned have helped me inn almost every aspect of understanding the complicated world we live in. I've taken these concepts to two other companies now to great effect.

https://www.amazon.com/Field-Guide-Understanding-Human-Error...

https://codeascraft.com/2012/05/22/blameless-postmortems/

https://codeascraft.com/2016/11/17/debriefing-facilitation-g...

https://www.oreilly.com/library/view/velocity-conference-201...

So much fantastic reading I hadn't seen before in this discussion. Mucho thanks to all for sharing!

Incidentally, Amazon does this. Particularly, they've adopted into the culture the concept of "good intentions don't work, mechanisms do." A decent summary can be found at this link:

http://nickfoy.com/blog/2018/4/7/good-intentions-dont-work

For example, if an admin bungles a copy/paste shell command and it causes an outage, instead of punishing the admin for not wanting hard enough to do it correctly, they'll change the process so it doesn't rely on admins copy/pasting shell commands.

That's awesome. I'm guessing it's limited to software Amazon themselves develops and doesn't extend to software deployed to AWS?

How could it? AWS will happily run whatever code you want, using whatever good or bad development practices you care to choose.

Fair. More just wondering if that have any sort of process for investigating data breaches involving software hosted on their servers.

Look at the “shared responsibility model” - if someone got in through the host then I guess they’d investigate. If you leak your SSH private key it’s on you.

It’s not their software to investigate.