4 ms·
That … seems like a company that isn’t doing postmortems correctly. You’re not supposed to robotically implement every “what would have prevented this”. It’s ju
by SilasX 5y ago
That … seems like a company that isn’t doing postmortems correctly. You’re not supposed to robotically implement every “what would have prevented this”. It’s just there to explore the space of such things and provide your options. “This is so rare and low impact that we change nothing” is a valid option!
The purpose of keeping a record of past postmortems is that you can potentially go back and say “oh gosh, it isn’t actually rare, and so maybe the more elaborate countermeasures are justified”.
I’ve seen the opposite extreme happen, where a devops guy was adamantly against writing a postmortem at all, because “it wasn’t our fault” and “it probably won’t happen again”. Facepalm.
- yojo 5y agoOh this is definitely me describing a failure mode of postmortems, not an indictment of the process generally. It usually happens with well intentioned junior teams that lack experience/perspective. I’m a firm believer in learning from mistakes, and making the right trade offs between reliability and velocity. Postmortems are a fantastic tool for facilitating this. As you point out though, the implementation matters and you need to be conscious of the cost/benefit of the recommendations that come out of the exercise.