I'm a broken record on how important I think this document is, and that it's hard to appreciate it until you've had extended experience with complex systems actually failing.
The most commonly cited subtext or thrust of it is that "root cause analysis", at least on complex systems, is a fools errand. Something goes wrong, say, in a distributed lock system, and your whole deployment system enters a metastable failure state. Naturally, the "root cause" seems like lock system resiliency. But definitionally a metastable failure is one that persists after the inciting condition is resolved. Now you have two "root causes", the lock failure and the metastability of the deployment system fault. Keep looking and you'll find more.
But to me the biggest brick to the forehead in this piece is further observation that random things are failing all the time in any complex system. "Complex systems run in degraded mode". Resilient components are good, but it's the resiliency of the overall process that orchestrates the whole system that determines whether things are going to blow up.
All practitioner actions are gambles. I should have that inked somewhere.
>The most commonly cited subtext or thrust of it is that "root cause analysis", at least on complex systems, is a fools errand.
It's only an issue when people take that phrase very literally. People have common sense to understand that things have multiple causes and a chain of events. NASA has "Root Cause Analysis" (singular) all over various official documentation and it doesn't stop them from understanding that the failed O-rings were not the single root cause of the Challenger explosion. Another cause was management normalizing the deviations of previous unsafe datapoints of prior launches which let them greenlight the launch in freezing temperatures. Another cause was the unrealistic flight schedules which can subconsciously pressure management into normalizing dangerous deviations. It wasn't The Rogers Commission that found the multiple causes; it was NASA engineers and management themselves explaining the multiple causes as they were interviewed by the Rogers Commission members.
For whatever reason, alternative jargon such as "Root Causes Analysis" (plural) or "Proximate and Distal Causes Analysis" isn't as widely used.
> Another cause was the unrealistic flight schedules which can subconsciously pressure management into normalizing dangerous deviations.
In the case of Challenger, I think it's pretty clear this was the "root cause":
> According to testimony by Kilminster and Boisjoly, Mason finally turned to Bob Lund and said, "Take off your engineering hat and put on your management hat." Joe Kilminster wrote out the new recommendation and went back on line with the teleconference.
> The new recommendation stated that the cold was still a safety concern, but their people had found that the original data was indeed inconclusive and their "engineering assessment" was that launch was recommended, even though the engineers had no part in writing the new recommendation and refused to sign it.
If you want to take the "system" view here, as is often the case, it is the organizational power structure and incentives therein that comprise the dangerous system. You had engineering experts easily predicting the disaster, but they had no decision making power. That was the problem. But if you set up an organization like that, where the egos of "get it done" managers are allowed to gamble with other people's lives to win their own accolades, the system is doomed from the start.
If you’re doing “five* whys” analyses correctly, you don’t stop at the technical causes. You continue further to analyze the causes that precipitated the technical errors, too. This exposes the business reasons behind them and forces management to face them.
* the number five isn’t magical here. You don’t have to stop at five, and you often shouldn’t.
Same, I think this document is fundamental to our industry and understanding complex systems. We have it as a quarterly reminder to review in our Slack. I give it to everyone that makes it past the first couple of interviews when applying and tout its usefulness for thinking through systems design all the time. RIP Dr. Cook.
> "root cause analysis", at least on complex systems, is a fools errand.
Not when properly understood--which, to be fair, it often isn't. The proper purpose of root cause analysis is to answer the question: does this failure mean I need to change something about this system? If the answer turns out to be yes, the thing that you need to change gets called the "root cause" of the failure. Of course that's a misnomer, strictly speaking, but that doesn't mean you answered the actual question wrong.
Cook doesn't object to postmortems and to using hard failures as opportunities to spot interventions (though, remember, all practitioner actions are gambles). The issue is in attempting to identify a single privileged root cause.
> Until you start to pull management decisions into your analysis, of course.
Meaning, having something like "management will decide not to fund maintenance for this component in the future, causing a failure" in your fault tree?
> Otherwise you're still facing the single cause trap.
"Something" does not have to mean "one single thing". But I would be fine with your phraseology if it ended up making it clearer to whoever was doing the analysis.
Root Cause Analysis is an organizational ritual that makes people feel like they're doing something. It's more about politics than about engineering. Not only is the process not useful- more often than not the correct root cause isn't even correctly identified.
Basically a poorly designed system is going to fail somewhere. I like to think about it either as the part of the iceberg that's visible or my other analogy is lighting doesn't strike twice at the same place. A robust/well designed system is just very different than a brittle/poorly designed system. The brittle system will exhibit random failures and trying to chase them is counterproductive.
We do have systems that are fairly complex and reliable. Take an internal combustion engine as one example or an entire car or an airplane (well, one of the well designed ones). Then we build bigger systems on top of that, a city's transportation system, where we do get to scales where things "fail" all the time. Yes, some bus somewhere or some train somewhere doesn't get to a station at the correct time, because a bus breaks down or heavy traffic or whatnot. But still a well designed system is robust to those. The parts we build the systems out of are well understood and so the resulting reliability can also be understood.
With software specifically we tend to not design and build that well. We throw stuff together. Then we're surprised when they fail. And we make excuses by saying "complex systems". I often feel it's our lack of discipline and skill vs. other domains and not really that our systems are that much more complex.
EDIT: Some might argue that mechanical systems like engines are just fundamentally simpler than software. But look at something like a bearing. Just one bearing is an incredibly complex system. Bearing failure is a statistical event, some bearings fail sooner, some fail later. There are centuries of know-how in the bearings used in said engine. Mechanical engineers generally use well understood components/designs and build in margin to meet the requirements of the engine they're designing. In software we often re-invent the "bearing" or we'll pick some new unproven design for a "bearing" and we'll generally build without a good understanding of the performance or failure modes of our "bearings" and without a known pattern as to how to use them and when to use them. And then we're surprised when our "car" fails in weird ways. We also don't test to the same standard that a mechanical engineer would use for a new design. They would have a room full of widgets doing ten million cycles before they accept the design as part of a larger system. We "yolo" it...
It's notable how many more engineers are paying attention to the details in mechanical systems. Take a random electrical connector in your car. Likely dozens of engineers were involved in its design and manufacturing. Dozens were involved with incorporating it into the vehicle design and installing it during manufacturing. There are entire teams who specialize in e.g. high-vacuum flange seal design. It's pretty rare to find similar teams in software.
I will argue that mechanical systems are fundamentally simpler than software, though. Try writing a datasheet for some library as an exercise. Thoroughly documenting the interface is tedious, but straightforward. You need graphs though, so maybe performance under load? But that's assuming a lot about hardware and runtimes, so you need to characterize it under all of those possible degrees of freedom. That's a much larger space than physical components have. Imagine characterizing/qualifying parts under disparate manufacturing methods that include "some sleep-deprived rando who's never heard of a lathe needs to build this successfully in his garage" (i.e. the norm in OSS).
And even if you successfully write a datasheet, some unrelated component elsewhere in the system can remotely interfere with your software through chained vulnerabilities, memory pressure, contention, etc. Mechanical engineers rarely worry about entirely disconnected parts interfering in undocumented ways, because reality limits how things can interact. RF engineers consider this kind of problem more regularly, and need correspondingly more animal sacrifices. The larger the software the worse this problem becomes, and small software systems are increasingly endangered these days.
A root cause investigation that concludes 'the system as a whole is fragile and poorly designed' sounds highly valuable - and they do happenl; I've seen them in healthcare
> I'm a broken record on how important I think this document is, and that it's hard to appreciate it until you've had extended experience with complex systems actually failing.
If you want a bit of cheese to go with that wine, this article pairs nicely with The Grug-Brained Developer: https://grugbrain.dev/
My Grug-brained hill to die on is that there are many pieces of technology like the LM741 opamp, the Rover V8, Morris A-series and Peugeot XUD engines, and a big SQL database running on a thumping great Unix box, that have remained essentially unchanged for decades, worked well when they were new, and are still a perfectly good solution today for so much of what you want to do.
You know what they have in common? A lack of complexity. Lovely simple technology, fix it with a hammer. Drive it to the moon and back. Drive it across the desert. Bring tools though!
All things equal you're always better off ruthlessly killing complexity. Cook (I know you're not rebutting him) is focused on the problem of unavoidably complex systems. A big server running a single instance of Postgres is great, and you should absolutely use that architecture if you can. But real-world constraints can break the architecture: need it running in multiple locations, with a single global view, with strictly bounded propagation times (for instance: because you're running a routing protocol): it's still just a database problem, but now it's a much more complex one.
And then, naturally, you can get complexity just by building stuff on top of that big database server, and other things that depend on those things.
"The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws. After accident reviews nearly always note that the system has a history of prior ‘proto-accidents’ that nearly generated catastrophe. Arguments that these degraded conditions should have been recognized before the overt accident are usually predicated on naïve notions of system performance. System operations are dynamic, with components (organizational, human, technical) failing and being replaced continuously."
This very much resembles Admiral Cloudberg's write-up of the National Airport collision:
"No human being can look at a complex system and predict with any degree of accuracy how exactly it will fail. But with sufficient data, prediction becomes possible because of something known in the occupational safety field as Heinrich’s Law, which states that there are approximately 300 “near misses” for every serious accident; or as the latest version of the law puts it, each fatal accident is accompanied by about 3,000 near misses and about 30,000 “at-risk behaviors.”[39] Statistically, hundreds or thousands of at-risk behaviors and near misses are likely to occur prior to the first fatal accident, providing an opportunity to identify the risk before lives are lost."
> After accident reviews nearly always note that the system has a history of prior ‘proto-accidents’ that nearly generated catastrophe. Arguments that these degraded conditions should have been recognized before the overt accident are usually predicated on naïve notions of system performance.
What does that mean? If you knew that the precursors were why did you not set alerts?
The "naive notion of system performance" is that the system is primarily operating in the ideal regime, and thus all deviations deserve alerts (and receive attention). The reality is that often the system is operating often enough in some failure mode that any such alerts would be regularly triggered by accepted behavior, and thus the alerts are systematically ignored/disabled/normalized.
E.g. nominally you should never be mixing traffic types (aircraft and helicopters, civilian and military) in close proximity to a major airport and in a regime where TCAS is unlikely to offer sufficient protection. So in theory, any mixing should immediately trigger an alert and investigation to develop new procedures. But in practice, if you routinely allow such mixing under what you believe are "safe" practices (and get away with such mixing for a long time) then when a real accident happens you will have plenty of "proto-accidents" to look back on, but the warning signs from those near-accidents will have become accepted practice.
> Failure free operations require experience with failure.
This is why we created Chaos Engineering. By constantly forcing failure, it made us always create systems in defense of that failure, and gave us great data on where the tipping point is for different systems within a particular failure mode.
It's much more universal and complicated than that. One of the big issues schools and pedagogy in general struggle with is that our environment is far too safe in too many ways. For kids there is too few ways to learn from failures. Attempts to solve the issue look often like "Hey, kids, let's fall over now all at once in safest way possible and learn from it!". But it doesn't work at all. Real failures have to be unexpected, related to your decisions and really hurt so that you can learn from them.
PS. Btw, I am certain that this is the main cause of the mental health crisis amongst young people.
> One of the big issues schools and pedagogy in general struggle with is that our environment is far too safe in too many ways. For kids there is too few ways to learn from failures.
Its cause we already learned from our failures and make the world a safer place. In my youth we climbed on trees, one of my friend fall down broke his arm, the doctor couldn't fix it and he can not move the hand for the rest of his live. My friend would be happy do not been allowed to climb, or at least under safer conditions but have his hand moveable still. I burned myself really heavy with fireworks as teenager and have a huge scar from it. I never touched any firework after this but also never bought it for my kids, so they never had the chance to "learn" from making the the same mistake.
Keep in mind that while claiming the world is too safe you say this from a perspective of an survivor.
No. I'm making a claim that the world is too safe from a perspective of my students. I see it very clearly that a lot of anxiety actually originates from fear. They are afraid to explore environment because they are not allowed to do it. They are afraid of conflicts because they are not allowed to learn to resolve these themselves. They are afraid of resolve any of their problems themselves because they are not allowed to discover the power to do it etc.
There's a fine line between "we made the world safer" and "we made the world too constricting to learn". I would like my kids to be allowed to fail a bit more often, while still staying safe. I think we've swung too far in the safe direction.
I agree with you. Kids aren't allowed to fail anymore. And as a parent, when I try to let my kid fail, I get scolded for being a bad parent. Broken bones used to be a right of passage for kids. Now it happens far less. While a broken bone sucks, it teaches you important lessons! Don't do that again, and hey, you messed up but you're fine now.
As someone who broke a wrist by rear-ending a car on my 100cc scooter I must respectfully disagree. A broken bone is way superior learning experience compared to some bruises.
I've always struggled to apply this to the systems I work on. If the system fails, someone potentially dies, though in practice they've never been more than hospitalized. To avoid that, huge amounts of effort are expended on failure modelling and testing, but that doesn't eliminate unknown unknowns. That discrepancy has made front page news a couple times.
When I was at Netflix and reddit, one thing I said often was, "Luckily, we are not a bank". And it sounds like you are working on even more critical systems than that.
Chaos engineering doesn't really apply to data critical or safety critical systems. You can't just break them in the real world to see how they fail.
You have it exactly right -- it has to be modeled and tested in lab conditions. Safety critical systems are not a place for YOLO development.
It's still a tool in the tool box. Somewhat analogous to accelerated life testing in non-software products. You induce conditions that make failures more likely to occur.
I may have shared this before on a different submission: John Gall’s books are really good on this topic: General Systemantics [https://en.wikipedia.org/wiki/Systemantics]
Gall's law is amongst my favorite ones and with decades of experience in software development, I have to say it holds absolutely true:
> “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” — John Gall, Systemantics (1975)
This is very important work. If it interests you, and you want to dig further, it's broadly called "Safety II". You probably want to read Erik Hollnagel [1] or Sydney Dekker. I put together a presentation once about how this translates to IT security [2]. But broadly:
Safety I Learn from Errors, Safety defined by absence,Reactive approach, Understanding what goes wrong, Accident causation models, Avoidance of errors, Reducing losses
Safety II Learn from successes, Safety defined by presence, Proactive approach, Understanding what goes right, Repeat what goes right, Enforce successful behaviours, Create new processes based on successful behaviour
If anything, think long and hard about this: "Post-accident attribution to a ‘root cause’ is fundamentally wrong." It's a true statement. If you truly understand this sentence, you have mastered Safety II to the level that a light bulb will come on, and you won't be able to un-see it. This light bulb is a curse, a beautiful curse.
I think, part of the point is that it’s not possible to have a recipe to prevent failures. They are cascades of many events coming together to fail in an a priori non obvious way.
Overall a good collection on the complex systems, somehow it missed the part how complex system came into the existence in the first place itself.
> Human expertise in complex systems is constantly changing
I feel this is single most important factor responsible to both making system complex and at the same time improving them depending on who the people are and how they take failures and breakdowns. I find it funny but we are in an era where folks building ML systems do not seem to remember the direction in which to open the screws. They do have clear expertise in something new but clearly lack in some other areas
A hazardous system does not necessarily has to be complex. The article is a generalized list which makes it bit harder to reason with on this topic. A big part of the complexity gets added over the time as a part of failures, effort to introduce more fail safes, processes to avoid the same failure again. Complexity begets complexity, which is why I was referring to the dependency on the human elements who are involved in evaluating the failure and remedies.
tldr; Removing a process is risky and thankless for most part, no one wants to take that risk. So after every failure a new process gets added and thus you end up with an ever growing complex system
Richard Cook was a UChicago anaesthesiologist who took up safety systems research after studying patient safety; some of his work is rooted in Three Mile Island, and some of it comes from aviation safety.
And industrial accident investigation (except the ones with low regulation or whatever). And market or supply chain collapse, and civilization collapse (late Bronze Age anyone?)
I'm a broken record on how important I think this document is, and that it's hard to appreciate it until you've had extended experience with complex systems actually failing.
The most commonly cited subtext or thrust of it is that "root cause analysis", at least on complex systems, is a fools errand. Something goes wrong, say, in a distributed lock system, and your whole deployment system enters a metastable failure state. Naturally, the "root cause" seems like lock system resiliency. But definitionally a metastable failure is one that persists after the inciting condition is resolved. Now you have two "root causes", the lock failure and the metastability of the deployment system fault. Keep looking and you'll find more.
But to me the biggest brick to the forehead in this piece is further observation that random things are failing all the time in any complex system. "Complex systems run in degraded mode". Resilient components are good, but it's the resiliency of the overall process that orchestrates the whole system that determines whether things are going to blow up.
All practitioner actions are gambles. I should have that inked somewhere.
>The most commonly cited subtext or thrust of it is that "root cause analysis", at least on complex systems, is a fools errand.
It's only an issue when people take that phrase very literally. People have common sense to understand that things have multiple causes and a chain of events. NASA has "Root Cause Analysis" (singular) all over various official documentation and it doesn't stop them from understanding that the failed O-rings were not the single root cause of the Challenger explosion. Another cause was management normalizing the deviations of previous unsafe datapoints of prior launches which let them greenlight the launch in freezing temperatures. Another cause was the unrealistic flight schedules which can subconsciously pressure management into normalizing dangerous deviations. It wasn't The Rogers Commission that found the multiple causes; it was NASA engineers and management themselves explaining the multiple causes as they were interviewed by the Rogers Commission members.
For whatever reason, alternative jargon such as "Root Causes Analysis" (plural) or "Proximate and Distal Causes Analysis" isn't as widely used.
> Another cause was the unrealistic flight schedules which can subconsciously pressure management into normalizing dangerous deviations.
In the case of Challenger, I think it's pretty clear this was the "root cause":
> According to testimony by Kilminster and Boisjoly, Mason finally turned to Bob Lund and said, "Take off your engineering hat and put on your management hat." Joe Kilminster wrote out the new recommendation and went back on line with the teleconference.
> The new recommendation stated that the cold was still a safety concern, but their people had found that the original data was indeed inconclusive and their "engineering assessment" was that launch was recommended, even though the engineers had no part in writing the new recommendation and refused to sign it.
-- https://onlineethics.virginia.edu/cases/engineering-ethics-c...
If you want to take the "system" view here, as is often the case, it is the organizational power structure and incentives therein that comprise the dangerous system. You had engineering experts easily predicting the disaster, but they had no decision making power. That was the problem. But if you set up an organization like that, where the egos of "get it done" managers are allowed to gamble with other people's lives to win their own accolades, the system is doomed from the start.
If you’re doing “five* whys” analyses correctly, you don’t stop at the technical causes. You continue further to analyze the causes that precipitated the technical errors, too. This exposes the business reasons behind them and forces management to face them.
* the number five isn’t magical here. You don’t have to stop at five, and you often shouldn’t.
Same, I think this document is fundamental to our industry and understanding complex systems. We have it as a quarterly reminder to review in our Slack. I give it to everyone that makes it past the first couple of interviews when applying and tout its usefulness for thinking through systems design all the time. RIP Dr. Cook.
> "root cause analysis", at least on complex systems, is a fools errand.
Not when properly understood--which, to be fair, it often isn't. The proper purpose of root cause analysis is to answer the question: does this failure mean I need to change something about this system? If the answer turns out to be yes, the thing that you need to change gets called the "root cause" of the failure. Of course that's a misnomer, strictly speaking, but that doesn't mean you answered the actual question wrong.
Cook doesn't object to postmortems and to using hard failures as opportunities to spot interventions (though, remember, all practitioner actions are gambles). The issue is in attempting to identify a single privileged root cause.
I don’t blame people for being confused about the term in software — it’s a bit more straightforward in manufacturing, for example.
That said, if you look at a system that failed and determine a root cause analysis is pointless, you may have just stumbled upon your root cause.
> it’s a bit more straightforward in manufacturing
That's because manufacturing is a simpler environment where causes and consequences are more conceptually distinct.
Until you start to pull management decisions into your analysis, of course. Then it becomes just as complex as software.
> Until you start to pull management decisions into your analysis, of course.
Meaning, having something like "management will decide not to fund maintenance for this component in the future, causing a failure" in your fault tree?
does this failure mean I need to change something about this system?
It's safer to say 'does this failure mean I need to change the system?'. Otherwise you're still facing the single cause trap.
> Otherwise you're still facing the single cause trap.
"Something" does not have to mean "one single thing". But I would be fine with your phraseology if it ended up making it clearer to whoever was doing the analysis.
Root Cause Analysis is an organizational ritual that makes people feel like they're doing something. It's more about politics than about engineering. Not only is the process not useful- more often than not the correct root cause isn't even correctly identified.
Basically a poorly designed system is going to fail somewhere. I like to think about it either as the part of the iceberg that's visible or my other analogy is lighting doesn't strike twice at the same place. A robust/well designed system is just very different than a brittle/poorly designed system. The brittle system will exhibit random failures and trying to chase them is counterproductive.
We do have systems that are fairly complex and reliable. Take an internal combustion engine as one example or an entire car or an airplane (well, one of the well designed ones). Then we build bigger systems on top of that, a city's transportation system, where we do get to scales where things "fail" all the time. Yes, some bus somewhere or some train somewhere doesn't get to a station at the correct time, because a bus breaks down or heavy traffic or whatnot. But still a well designed system is robust to those. The parts we build the systems out of are well understood and so the resulting reliability can also be understood.
With software specifically we tend to not design and build that well. We throw stuff together. Then we're surprised when they fail. And we make excuses by saying "complex systems". I often feel it's our lack of discipline and skill vs. other domains and not really that our systems are that much more complex.
EDIT: Some might argue that mechanical systems like engines are just fundamentally simpler than software. But look at something like a bearing. Just one bearing is an incredibly complex system. Bearing failure is a statistical event, some bearings fail sooner, some fail later. There are centuries of know-how in the bearings used in said engine. Mechanical engineers generally use well understood components/designs and build in margin to meet the requirements of the engine they're designing. In software we often re-invent the "bearing" or we'll pick some new unproven design for a "bearing" and we'll generally build without a good understanding of the performance or failure modes of our "bearings" and without a known pattern as to how to use them and when to use them. And then we're surprised when our "car" fails in weird ways. We also don't test to the same standard that a mechanical engineer would use for a new design. They would have a room full of widgets doing ten million cycles before they accept the design as part of a larger system. We "yolo" it...
It's notable how many more engineers are paying attention to the details in mechanical systems. Take a random electrical connector in your car. Likely dozens of engineers were involved in its design and manufacturing. Dozens were involved with incorporating it into the vehicle design and installing it during manufacturing. There are entire teams who specialize in e.g. high-vacuum flange seal design. It's pretty rare to find similar teams in software.
I will argue that mechanical systems are fundamentally simpler than software, though. Try writing a datasheet for some library as an exercise. Thoroughly documenting the interface is tedious, but straightforward. You need graphs though, so maybe performance under load? But that's assuming a lot about hardware and runtimes, so you need to characterize it under all of those possible degrees of freedom. That's a much larger space than physical components have. Imagine characterizing/qualifying parts under disparate manufacturing methods that include "some sleep-deprived rando who's never heard of a lathe needs to build this successfully in his garage" (i.e. the norm in OSS).
And even if you successfully write a datasheet, some unrelated component elsewhere in the system can remotely interfere with your software through chained vulnerabilities, memory pressure, contention, etc. Mechanical engineers rarely worry about entirely disconnected parts interfering in undocumented ways, because reality limits how things can interact. RF engineers consider this kind of problem more regularly, and need correspondingly more animal sacrifices. The larger the software the worse this problem becomes, and small software systems are increasingly endangered these days.
A root cause investigation that concludes 'the system as a whole is fragile and poorly designed' sounds highly valuable - and they do happenl; I've seen them in healthcare
Check out the book called, The Logic of Failure. I think you’ll like it
Two other great books on failures in inevitably complex military operations are:
1. Command in War (1985) by Martin van Creveldt. He dissects may complex but common military failure causes up to the Vietnam War.
2. Team of Teams (2015) by Stanley McChrystal that is focused on what he and teams learned in Iraq but extrapolating to most organizations.
> I'm a broken record on how important I think this document is, and that it's hard to appreciate it until you've had extended experience with complex systems actually failing.
If you want a bit of cheese to go with that wine, this article pairs nicely with The Grug-Brained Developer: https://grugbrain.dev/
I am also a broken record about Grug-brainedness, but I don't need to be so repetitive about it because so many other people are too.
My Grug-brained hill to die on is that there are many pieces of technology like the LM741 opamp, the Rover V8, Morris A-series and Peugeot XUD engines, and a big SQL database running on a thumping great Unix box, that have remained essentially unchanged for decades, worked well when they were new, and are still a perfectly good solution today for so much of what you want to do.
You know what they have in common? A lack of complexity. Lovely simple technology, fix it with a hammer. Drive it to the moon and back. Drive it across the desert. Bring tools though!
All things equal you're always better off ruthlessly killing complexity. Cook (I know you're not rebutting him) is focused on the problem of unavoidably complex systems. A big server running a single instance of Postgres is great, and you should absolutely use that architecture if you can. But real-world constraints can break the architecture: need it running in multiple locations, with a single global view, with strictly bounded propagation times (for instance: because you're running a routing protocol): it's still just a database problem, but now it's a much more complex one.
And then, naturally, you can get complexity just by building stuff on top of that big database server, and other things that depend on those things.
"The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws. After accident reviews nearly always note that the system has a history of prior ‘proto-accidents’ that nearly generated catastrophe. Arguments that these degraded conditions should have been recognized before the overt accident are usually predicated on naïve notions of system performance. System operations are dynamic, with components (organizational, human, technical) failing and being replaced continuously."
This very much resembles Admiral Cloudberg's write-up of the National Airport collision:
"No human being can look at a complex system and predict with any degree of accuracy how exactly it will fail. But with sufficient data, prediction becomes possible because of something known in the occupational safety field as Heinrich’s Law, which states that there are approximately 300 “near misses” for every serious accident; or as the latest version of the law puts it, each fatal accident is accompanied by about 3,000 near misses and about 30,000 “at-risk behaviors.”[39] Statistically, hundreds or thousands of at-risk behaviors and near misses are likely to occur prior to the first fatal accident, providing an opportunity to identify the risk before lives are lost."
https://admiralcloudberg.medium.com/reaping-the-whirlwind-in...
> After accident reviews nearly always note that the system has a history of prior ‘proto-accidents’ that nearly generated catastrophe. Arguments that these degraded conditions should have been recognized before the overt accident are usually predicated on naïve notions of system performance.
What does that mean? If you knew that the precursors were why did you not set alerts?
The "naive notion of system performance" is that the system is primarily operating in the ideal regime, and thus all deviations deserve alerts (and receive attention). The reality is that often the system is operating often enough in some failure mode that any such alerts would be regularly triggered by accepted behavior, and thus the alerts are systematically ignored/disabled/normalized.
E.g. nominally you should never be mixing traffic types (aircraft and helicopters, civilian and military) in close proximity to a major airport and in a regime where TCAS is unlikely to offer sufficient protection. So in theory, any mixing should immediately trigger an alert and investigation to develop new procedures. But in practice, if you routinely allow such mixing under what you believe are "safe" practices (and get away with such mixing for a long time) then when a real accident happens you will have plenty of "proto-accidents" to look back on, but the warning signs from those near-accidents will have become accepted practice.
My response would be to use more sophisticated anomaly detection.
Problems managing a complex system? Why not consider adding another complex system!
> Failure free operations require experience with failure.
This is why we created Chaos Engineering. By constantly forcing failure, it made us always create systems in defense of that failure, and gave us great data on where the tipping point is for different systems within a particular failure mode.
It's much more universal and complicated than that. One of the big issues schools and pedagogy in general struggle with is that our environment is far too safe in too many ways. For kids there is too few ways to learn from failures. Attempts to solve the issue look often like "Hey, kids, let's fall over now all at once in safest way possible and learn from it!". But it doesn't work at all. Real failures have to be unexpected, related to your decisions and really hurt so that you can learn from them.
PS. Btw, I am certain that this is the main cause of the mental health crisis amongst young people.
> One of the big issues schools and pedagogy in general struggle with is that our environment is far too safe in too many ways. For kids there is too few ways to learn from failures.
Its cause we already learned from our failures and make the world a safer place. In my youth we climbed on trees, one of my friend fall down broke his arm, the doctor couldn't fix it and he can not move the hand for the rest of his live. My friend would be happy do not been allowed to climb, or at least under safer conditions but have his hand moveable still. I burned myself really heavy with fireworks as teenager and have a huge scar from it. I never touched any firework after this but also never bought it for my kids, so they never had the chance to "learn" from making the the same mistake. Keep in mind that while claiming the world is too safe you say this from a perspective of an survivor.
No. I'm making a claim that the world is too safe from a perspective of my students. I see it very clearly that a lot of anxiety actually originates from fear. They are afraid to explore environment because they are not allowed to do it. They are afraid of conflicts because they are not allowed to learn to resolve these themselves. They are afraid of resolve any of their problems themselves because they are not allowed to discover the power to do it etc.
There's a fine line between "we made the world safer" and "we made the world too constricting to learn". I would like my kids to be allowed to fail a bit more often, while still staying safe. I think we've swung too far in the safe direction.
The difficult part is judging where that "happy medium" is. (And then how to get there.)
I agree with you. Kids aren't allowed to fail anymore. And as a parent, when I try to let my kid fail, I get scolded for being a bad parent. Broken bones used to be a right of passage for kids. Now it happens far less. While a broken bone sucks, it teaches you important lessons! Don't do that again, and hey, you messed up but you're fine now.
I feel like painfully falling without breaking bones are pretty good lessons already, and I don't quite see what the broken bones add there.
As someone who broke a wrist by rear-ending a car on my 100cc scooter I must respectfully disagree. A broken bone is way superior learning experience compared to some bruises.
I've always struggled to apply this to the systems I work on. If the system fails, someone potentially dies, though in practice they've never been more than hospitalized. To avoid that, huge amounts of effort are expended on failure modelling and testing, but that doesn't eliminate unknown unknowns. That discrepancy has made front page news a couple times.
When I was at Netflix and reddit, one thing I said often was, "Luckily, we are not a bank". And it sounds like you are working on even more critical systems than that.
Chaos engineering doesn't really apply to data critical or safety critical systems. You can't just break them in the real world to see how they fail.
You have it exactly right -- it has to be modeled and tested in lab conditions. Safety critical systems are not a place for YOLO development.
It's still a tool in the tool box. Somewhat analogous to accelerated life testing in non-software products. You induce conditions that make failures more likely to occur.
I may have shared this before on a different submission: John Gall’s books are really good on this topic: General Systemantics [https://en.wikipedia.org/wiki/Systemantics]
Gall's law is amongst my favorite ones and with decades of experience in software development, I have to say it holds absolutely true:
> “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” — John Gall, Systemantics (1975)
Whenever I see this [excellent] paper, I am always struck by the first sentence, in the first section:
> All of the interesting systems (e.g. transportation, healthcare, power generation) are inherently and unavoidably hazardous by THE own nature.
(Emphasis mine)
I am not sure if that's a typo, or some writing convention that my uneducated mind can't grok.
Is it not merely an example of such failure?
This is very important work. If it interests you, and you want to dig further, it's broadly called "Safety II". You probably want to read Erik Hollnagel [1] or Sydney Dekker. I put together a presentation once about how this translates to IT security [2]. But broadly:
Safety I Learn from Errors, Safety defined by absence,Reactive approach, Understanding what goes wrong, Accident causation models, Avoidance of errors, Reducing losses
Safety II Learn from successes, Safety defined by presence, Proactive approach, Understanding what goes right, Repeat what goes right, Enforce successful behaviours, Create new processes based on successful behaviour
If anything, think long and hard about this: "Post-accident attribution to a ‘root cause’ is fundamentally wrong." It's a true statement. If you truly understand this sentence, you have mastered Safety II to the level that a light bulb will come on, and you won't be able to un-see it. This light bulb is a curse, a beautiful curse.
[1] https://safety4sea.com/cm-safety-i-vs-safety-ii-an-overview [2] https://www.msoos.org/largefiles/safety2.pdf
The definitive work on this topic is Normal Accidents, with a modern retelling in Meltdown.
https://en.wikipedia.org/wiki/Normal_Accidents
https://en.wikipedia.org/wiki/Meltdown_(Clearfield_and_Tilcs...
Highly recommend "The Logic of Failure" by Dietrich Dörner (1997)
I think there are a few common themes to the failure reasons, but cannot get my hands on it.
This seems like a list of reasons while I am looking for more abstract directions on how to prevent them.
---
I am trying not to use AIs to just do that for me to tinkle my neurons.
I think, part of the point is that it’s not possible to have a recipe to prevent failures. They are cascades of many events coming together to fail in an a priori non obvious way.
Or so I read the [site? article?]
Overall a good collection on the complex systems, somehow it missed the part how complex system came into the existence in the first place itself.
> Human expertise in complex systems is constantly changing
I feel this is single most important factor responsible to both making system complex and at the same time improving them depending on who the people are and how they take failures and breakdowns. I find it funny but we are in an era where folks building ML systems do not seem to remember the direction in which to open the screws. They do have clear expertise in something new but clearly lack in some other areas
Literally the first item in the list addresses the necessity of complexity in the systems it's discussing.
A hazardous system does not necessarily has to be complex. The article is a generalized list which makes it bit harder to reason with on this topic. A big part of the complexity gets added over the time as a part of failures, effort to introduce more fail safes, processes to avoid the same failure again. Complexity begets complexity, which is why I was referring to the dependency on the human elements who are involved in evaluating the failure and remedies.
tldr; Removing a process is risky and thankless for most part, no one wants to take that risk. So after every failure a new process gets added and thus you end up with an ever growing complex system
Worth reading Leveson’s works on safety engineering.
All of this sounds just like any air crash investigation I ever read
Richard Cook was a UChicago anaesthesiologist who took up safety systems research after studying patient safety; some of his work is rooted in Three Mile Island, and some of it comes from aviation safety.
And industrial accident investigation (except the ones with low regulation or whatever). And market or supply chain collapse, and civilization collapse (late Bronze Age anyone?)
I can't tell if the article is describing how complex systems fail or if they are using failure characteristics to define complex systems.
It’s more about failure. It’s right there on top.
One of the great documents of our civilisation
Good take, no notes