The writer is trying to convey issues in Reliability Engineering, Human Factors and Systems Theory, but with a lot of shortcuts that muddle the message. 7 /I b

The writer is trying to convey issues in Reliability Engineering, Human Factors and Systems Theory, but with a lot of shortcuts that muddle the message. 7 /I believe the intent was to talk about holistic problem solving, not suggesting low performance get a pass. The most contemporary understanding of human error is that although people can introduce errors, in complex systems (software included) most situations go downhill due to multiple issues. In many industries people do get fired as a way to fix the 'cause' of an incident. The Silicon Valley equivalent would be firing the human closest to the faulty configs that interacted with a bug and caused Google Cloud’s June outage, without addressing the issues that allowed the network to come to a halt; or firing a Cloudfare engineer who pushed a change that led to Cloudfare losing most of its traffic for a while in July instead of digging deep into the reasons that brought their system to its knees. 6/"...we have a strong case that thorough documentation...actually provide little value in preventing incidents." There are 2.5 ideas conflated here: 1/ complex systems are dynamic, and documentation/practices have to to be just as dynamic otherwise will documents a past state. 2/ complex systems are dynamic and incidents will be most likely caused by unexpected interactions not covered in runbooks. 2.5/ Expertise involves explicit and implicit knowledge; translating implicit knowledge is a challenge. 5/ The central issue with RCA is that in complex systems there is not a single, isolated 'cause'. There are often multiple reasons an incident happened, and these reasons ripple through the whole organization. Adding mitigation strategies to address a prior incident can worsen a situation (or create a new one) especially when the choice of mitigation strategy does not address the actual reasons that created the initial incident. 4/"...people designing the procedures have a theory..." Whenever reviewing incidents, find out how the work is _done_, not written. Chances are the written procedure has mutated to make it more efficient. That change can now have highlighted a previously-unknown weakness in the system design. (Corollaries: procedures are a living document; people doing the work should write the procedures) 3/This is not about operational risk mitigation... It is about knowing how systems work at their safety boundary. One idea is that not having to deal with the system at its safety edge leads engineers to solutions that ignore that boundary or to a decrease in skills. An example from aviation is automation diminishing a pilot's ability to aviate manually. 2/ A slight edit would have helped here. Basically some systems at their simplest work ok but will work better if complexity is added, for a particular vector of 'better'. So simplicity is not always best. There may be an assumption that all complexity is unnecessary. While complexity limits observability, there is such a thing as thoughtful system design without unnecessary complexity. 1/"...redundancy is often orthogonal to robustness,..." This item is conjoining system reliability, robustness, observability. The super short version: redundancy is one aspect of robustness. It alone will not make your system robust or reliable.