John Allspaw, a former Etsy engineering leader, writes about operations, incident analysis, resilience and what being a senior engineer means.
Commenters repeatedly call his post On Being a Senior Engineer the best article on the subject, and his root cause writing gets cited too.
This article is older now but is still a great read. It has a different list which I liked a lot (the below is directly from the article):
Self-Serving Bias – basically: if something is good, it’s probably because of something I did or thought of. If it’s bad, it’s probably the doing of someone else.
Fundamental Attribution Error – basically: the bad results that someone else got from his work must have something to do with how he is, personally (stupid, clumsy, sloppy, etc.) whereas if I get bad results, it’s because of the context that I was in, the pressure I was under, the situation I was in, etc.
Hindsight Bias – (it is said that this is the most-studied phenomenon in the history of modern psychology) basically: after an untoward or negative event (a severe bug, an outage, etc.) “I knew it all along!”. It is the very strong tendency to view the past more simply than it was in reality. You can tell there is Hindsight Bias going on when descriptions involve counterfactuals, or “…they should have…”, or “…how did they not see that, it’s so obvious!”.
Outcome Bias – like above, this comes up after a surprising or negative event. If the event was very damaging, expensive to clean up, or severe, then the decisions or actions that contributed to that event are judged to be very stupid, reckless, or negligent. The judgement is proportional to how severe the event was.
Planning Fallacy – (related to the point about making estimates under uncertainty, above) basically: being…
There is a really, really interesting breakdown of this document on kitchensoap.com [0]
The writer breaks down why this document is not a post-mortem despite superficial similarities.
>Again, the purpose of the doc is to point out where Knight violated rules. It is not: 1) a description of the multiple trade-offs that engineering at Knight made or considered when designing fault-tolerance in their systems, or 2) how Knight as an organization evolved over time to focus on evolving some procedures and not others, or 3) how engineers anticipated in preparation for deploying support for the new RLP effort on Aug 1, 2012.
>To equate any of those things with violation of a rule is a cognitive leap that we should stay very far away from.
>It’s worth mentioning here that the document only focuses on failures, and makes no mention of successes. How Knight succeeded during diagnosis and response is unknown to us, so a rich source of data isn’t available. Because of this, we cannot pretend the document to give explanation.
He also makes an interesting point related to what you're saying: the SEC says the risk management controls were inappropriate, but clearly Knight thought they were appropriate or they would have fixed it.
>What is deemed “appropriate”, it would seem, is dependent on the outcome. Had an accident? It was not appropriate control. Didn’t have an accident? It must be appropriate control. This would mean that Knight Capital did have appropriate controls the day…
This comment has now been both down-voted and up-voted multiple times. Would one of you down-voters care to explain why you feel this point is unworthy of discussion?
A blog post [0] that was up-voted near the top of Hacker News last week made the same point in terms that apparently are more palatable to some readers. If you haven't read it, I encourage you to do so. Two of the academic papers/book chapters [1, 2] that the blogger cites specifically discuss risk assessment of nuclear power stations in the context I described.
All of this stuff is well known. It's why web-sites' uptimes are never anywhere near the five nines advertised and why we have "flash crashes" in our financial markets.
The focus of my original comment is not only on identifying and assigning probabilities to causes of failures that are inherently difficult to discern, but also on the inadequacy of metrics like expected value in quantifying the effect of rare but spectacular outcomes. Is it really not even worth discussing these problems with our risk-assessment methodologies when the price of failure is as high as it is in case of an uncontrolled meltdown of a nuclear reactor?
0. http://www.kitchensoap.com/2012/02/10/each-necessary-but-only-jointly-sufficient/
1. http://csel.eng.ohio-state.edu/woods/error/fund_surp.pdf
2. http://crpit.com/confpapers/CRPITV86Qureshi.pdf
First, I highly recommend "Deployment is just a part of dev/ops cooperation" http://www.kitchensoap.com/2009/12/12/devops-cooperation-doesnt-just-happen-with-deployment/
Second, this isn't a question unique to the dev/ops relationship. What about the dev v. project manager? If you have a good team of developers, why have a PM? Having worked as a dev, a system engineer, and newly in the PM department, everything I've done since being a 'code monkey' is motivated by a desire to make the dev's jobs easier. Maybe that's because of my roots, but I think it makes the most sense.
Where I work, we have a useful distinction between Sysadmins and System Engineers. Broadly speaking, admins are the i-dotters and t-crossers and do things with well-defined processes while engineers are responsible for everything else. As an engineer, I wanted to make as much information about the production environment available to the developers as possible. I also worked to make sure the dev environment would mirror production as closely as possible given that we only had one dev sandbox (requests for a staging environment were declined). These two things, combined with being a good teacher, meant I rarely had requests for CLI access to any of our environments.
Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate.
Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/
From The Unwritten Laws of Engineering, quoted in the article:
Promises, schedules, and estimates are necessary and important instruments in a well-ordered business. Many engineers fail to realize this, or habitually try to dodge the irksome responsibility for making commitments. You must make promises based upon your own estimates for the part of the job for which you are responsible, together with estimates obtained from contributing departments for their parts. No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors."
Also from the article:
Avoiding responsibility for estimates is another way of saying, “I’m not ready to be relied upon for building critical pieces of infrastructure.”
It's a sign of poor management that someone has to be fired when something goes wrong, outages are learning situations for all involved, and it is widely held that the person who took the action that caused an outage is not responsible, but that all involved are responsible.
See John Allspaw's Swiss Cheese Theory : http://www.kitchensoap.com/2012/02/10/each-necessary-but-only-jointly-sufficient/ .
[ Edit: I guess it's not Allspaw's model, but he applies it to systems engineering rather well - http://en.wikipedia.org/wiki/Swiss_cheese_model ]
"Accidents emerge from a confluence of conditions and occurrences that are usually associated with the pursuit of success, but in this combination—each necessary but only jointly sufficient—able to trigger failure instead."
The person who pushed the button is not at fault, the manager is not at fault, the guy who designed the button is not at fault - all are jointly responsible.
Blaming the intern does, however, reflect extremely poorly on Itoh and everyone else in the chain of command. A superior who demands retribution for a simple mistake that happened to cause him or her pain is basically worthless.
But, I forget, we're talking about Ronald Reagan.