Chernobyl DevOps

Living as I do, within a kilometre of a nuclear power plant, I'm interested in reading about nuclear disasters. I recently watched the TV series, Chernobyl, and am reading the excellent book, Midnight in Chernobyl, by Adam Higginbotham. So I was intrigued by the title of this article: Chernobyl DevOps: Software Engineering, Disaster Management, and Observability.

You might not think that a disaster at a badly designed, badly run, Soviet-era nuclear power plant has much to to with modern software engineering and development, but you'd be wrong. There are bad ways and good ways to respond to disasters are independent of their type and scope.

HBO’s wonderful miniseries Chernobyl—about, well, the 1986 Chernobyl Disaster—just wrapped this week, and as someone who debugs and operates computer systems for a living, and reads books about Chernobyl in his spare time, I thought I’d take the opportunity to point out some of the lessons that Chernobyl has to teach us about software engineering.

I don’t work at a nuclear power plant. The stakes when production goes down and tensions rise seem much lower, but as an industry, we experience issues similar to some of the ones that happened in the control room and its aftermath quite frequently. And some software bugs can be lethal—whether it’s in an avionics system or a car’s throttle control or a tiny piece of monitoring software installed on a Unix computer that just happens to be used in a power substation.

Obviously I’m going to spoil everything that happens in Chernobyl, much like the Wikipedia article on the real Chernobyl disaster would.

It's an interesting article and worth reading, especially if you work with large, complex systems.