{"id":272,"date":"2021-08-31T14:40:46","date_gmt":"2021-08-31T14:40:46","guid":{"rendered":"https:\/\/fde.cat\/?p=272"},"modified":"2021-08-31T14:40:46","modified_gmt":"2021-08-31T14:40:46","slug":"how-not-why-an-alternative-to-the-five-whys-for-post-mortems","status":"publish","type":"post","link":"https:\/\/fde.cat\/index.php\/2021\/08\/31\/how-not-why-an-alternative-to-the-five-whys-for-post-mortems\/","title":{"rendered":"How, Not Why: An Alternative to the Five Whys for Post-Mortems"},"content":{"rendered":"

When I got into the DevOps field, I was exposed to The Five Whys<\/a>\u200a\u2014\u200aa popular analytical method used in incident postmortems. The Five Whys is one type of root cause analysis<\/a> (RCA): \u201cThe primary goal of the technique is to determine the root cause<\/a> of a defect<\/a> or problem by repeating the question \u2018Why?.\u2019 Each answer forms the basis of the next question (link<\/a>).\u201d <\/p>\n

In a body of research about how systems really<\/em> fail, I discovered a powerful critique of root cause analysis. The critique is known as \u201cthe new view<\/a> of human error<\/a>.\u201d Any place where accidents or unwanted outages can occur has a lot in common with managing information technology systems. While most readers of this post will be in the software industry, much of the research comes from other fields such as industrial accidents, medicine, shipping, and aeronautics. After learning about this research, I came to the conclusion that root cause analysis is misleading, and even harmful. In this piece, I will explain their critique of RCA, and I will present what I think is a better\u00a0idea.<\/p>\n

\"\"<\/figure>\n

To illustrate the conventional thinking, I will start with media coverage of one IT outage. There is nothing special about the story that I have chosen\u200a\u2014\u200aevery company that operates software in production has had something similar happen. On Business Insider <\/em>can be seen the headline Amazon took down parts of the internet because an employee fat-fingered the wrong command<\/a>. According to writer Kif Leswing, an employee made a mistake and consequently, a part of Amazon\u2019s cloud crashed. It sounds very simple. Every story turns out to be about how some careless\u200a\u2014\u200aor perhaps incompetent\u200a\u2014\u200aperson spilled their coffee on a network switch and the internet went down. But in reality, it\u2019s not that simple.<\/p>\n

Writing about the same story for The New Stack<\/em>, Lee Atchison leads with Don\u2019t Write Off the AWS S3 Outage as a Fat-Finger Folly.<\/a> In my opinion, Atchison had a better explanation than the other writer. He points out that AWS follows DevOps best practices, such as scripting instead of typing, validation of inputs, and audit trailing. While it was not entirely untrue that the ops engineer made a mistake (the engineer typed the wrong command). However, there was a bug in the validation part of the script, so it did not reject the incorrect command. The command kicked off a cascade of failures that took down part of their system. The full story shows a reality more complex than one user: one mistake. <\/p>\n

An important distinction in the research about failures is the division between simple and complex systems. Simple systems are linear and sequential. Each part is connected to one adjacent part. Simple systems fail in simple ways\u200a\u2014\u200alike a row of dominoes falling over. Researcher Dr. Eric Hollnagel has noted the pervasiveness of the \u201crow of dominoes\u201d metaphor in the coverage of all kinds of incidents. It\u2019s the easiest metaphor to reach for. Hollnagel has a great slide<\/a> on this point that incorporates pictures of dominoes from a variety of sources. <\/p>\n

The computer systems that that include our applications are complex, not simple. As Kevin Heselin says in Examining and Learning from Complex Systems Failures<\/a>, \u201ccomplex systems fail in complex ways.\u201d Heselin continues \u201cthe hallmarks of complex systems are a large number of interacting components, emergent properties, difficult to anticipate from the knowledge of single components, ability to absorb random disruptions and highly vulnerable to widespread failure under adverse conditions\u201d. Some of the best thinking in this area is from Dr. Richard L. Cook, a medical doctor and author of the landmark paper How Complex Systems Fail<\/a>. In this source, Dr. Cook covers 18 points that characterize complex systems. I\u2019ll go through some of them below, but I encourage everyone to read the entire paper to get the others. <\/p>\n

John Allspaw, another one of the thought leaders in this field, characterizes<\/a> complex systems as those systems built from components having certain properties: diversity interdependence, adaptive, and connected. Allspaw emphasizes that complex systems exhibit very nonlinear behaviors, meaning a small action or small change can lead to what seems like a disproportionate and unpredictably large event.<\/p>\n

In a complex system, it is difficult\u200a\u2014\u200aor impossible\u200a\u2014\u200ato understand the relationships between all of the parts, and therefore how the system as a whole will respond to one single small disturbance. One of the constant themes in this literature is that there is no single cause for an incident<\/em>. Dr. Cook says: \u201csmall, apparently innocuous failures join to create [the] opportunity for a systemic accident.\u201d He continues, \u201ceach small failure is necessary, but only the combination is sufficient to permit failure.\u201d Multiple things must go wrong in order to produce a systemic outage. <\/p>\n

Dr. Cook emphasizes that we\u200a\u2014\u200adesigners and operators of systems\u200a\u2014\u200atake proactive steps to protect our systems, and we are pretty good at it. A big part of our job consists of designing systems to be resilient. We have a good idea of many of the things that can go wrong, and we have a \u201cPlan B\u201d in place for the more common failure modes\u200a\u2014\u200aand a good many of the less common ones too. Our efforts succeed\u200a\u2014\u200aoften: the systems we manage don\u2019t fall over at the slightest sign of trouble. If one thing goes wrong, we are pretty good at preventing that from turning into a complete outage. If a server fails, a database host, or even a datacenter, most production systems will keep humming along. According to Dr. Cook, \u201cthere are many more failure opportunities than overt system accidents.\u201d<\/p>\n

I hope it is now evident why the idea of a single cause does not reflect reality. Mathias Lafeltdt writes in The Myth of the Root Cause<\/a> that \u201cSingle-point failures alone are not enough to trigger an incident. Instead, incidents require multiple contributors, each necessary but only jointly sufficient. It is the combination of these causes\u200a\u2014\u200aoften small and innocuous failures like a memory leak, a server replacement, and a bad DNS update\u200a\u2014\u200athat is the prerequisite for an incident. We therefore can\u2019t isolate a single root cause.\u201d <\/p>\n

For example, let\u2019s look at a well known accident<\/a> in which a ship capsized in the port of Zeebrugge. Researcher, Takafumi Nakamura looked at the entire system<\/a>. He created a diagram explaining how the failure occurred with the failure on the far right. You can see the multiple causes and the relationships between them. All of the contributing causes and relationships, in some way, contributed to the failure. If you take away maybe even just one of them, then you might have avoided the\u00a0failure.<\/p>\n

\"\"<\/figure>\n

Systems contain what Dr. Cook refers to as latent failures. When a realized failure requires multiple interacting causes, complex systems are always in in a state in which some\u200a\u2014\u200abut not all\u200a\u2014\u200aof the multiple contributing causes, necessary for a complete failure, have already occurred, only not enough of them for a systemic failure. It is as if a few threads in your sweater are broken, but you don\u2019t see the hole, yet. It is impossible to eliminate all of these partial failures. <\/p>\n

According to Dr. Cook, \u201cdisaster can occur at any time and in nearly any place. The potential for catastrophic outcome is a hallmark of complex systems. It is impossible to eliminate the potential for such catastrophic failure; the potential for such failure is always present; by the system\u2019s own nature.\u201d <\/p>\n

Some examples of latent failures\u00a0are:<\/p>\n