I. Learning¶
How to learn from failures and anomalies.
Take the Learning quiz when you have read the examples.
P80. Blameless root cause analysis¶
The rule: find the root cause in the system, not a person to blame
Illustrative, not evidence.
Scenario. A payments API is down for 40 minutes after an engineer runs a cleanup script against production instead of staging. The incident is above the team's severity-2 line, so it needs a postmortem.
Applying the rule. The postmortem asks why the script could reach production at all. It finds that both environments share one credential and that the prompt does not show which environment it is in. It lists three system actions with owners: separate credentials, a coloured prompt, and a confirmation step for destructive scripts. The engineer is not named as the cause. The check is met: the failure has a postmortem with system-level actions.
Violating the rule. The report closes with the root cause "operator error" and the action "remind the engineer to be careful". Nothing in the system changes. The next engineer who can reach production with the same credential makes the same mistake, and people stop reporting their slips.
Management variant.
Scenario. A company reorganizes its support and billing teams. Within a month handoffs fail and customers wait days for refunds.
Applying the rule. The company holds an after-action review with everyone affected. They discuss without blame what was meant to happen, what happened, why, and how to improve. The output is a short list of process changes, such as a named owner for each handoff.
Violating the rule. The director asks each team lead to write down who caused the delays. The leads blame each other, nobody shares what they saw, and the handoffs stay broken.
Real case: Space Shuttle Columbia foam strike and its organizational causes (2003).
A piece of insulating foam from the External Tank struck Columbia's left wing after launch. During re-entry, the breach it made in the Thermal Protection System let superheated air in, and the orbiter and its crew were lost. During the flight, engineers assessed the strike with Crater, a model calibrated on far smaller debris. Program management cancelled a request for images of the wing. The Columbia Accident Investigation Board did not stop at the part that broke or the people closest to it, and looked for causes in the organization as a whole. It found that the causes of the institutional failure behind Challenger, 17 years earlier, had not been fixed.
What it shows for P80. The board warns that many investigations stop at the part that broke and the person closest to it, and that such corrections lead to a misguided belief that the underlying problem has been solved. Its own cause model took in NASA as an organizational whole.
The physical cause of the loss of Columbia and its crew was a breach in the Thermal Protection System on the leading edge of the left wing.
Source: Columbia Accident Investigation Board: Report, Volume I, Chapter 3, Accident Analysis (2003)
The breach was initiated by a piece of insulating foam that separated from the left bipod ramp of the External Tank and struck the wing in the vicinity of the lower half of Reinforced Carbon-Carbon panel 8 at 81.9 seconds after launch.
Source: Columbia Accident Investigation Board: Report, Volume I, Chapter 3, Accident Analysis (2003)
During re-entry, this breach in the Thermal Protection System allowed superheated air to penetrate the leading-edge insulation
Source: Columbia Accident Investigation Board: Report, Volume I, Chapter 3, Accident Analysis (2003)
When used within its validated limits, Crater provides conservative predictions
Source: Columbia Accident Investigation Board: Report, Volume I, Chapter 6, Decision Making at NASA (2003)
engineers used Crater during STS-107 to analyze a piece of debris that was at maximum 640 times larger in volume than the pieces of debris used to calibrate and validate the Crater model
Source: Columbia Accident Investigation Board: Report, Volume I, Chapter 6, Decision Making at NASA (2003)
When asked why he did not send this e-mail, Rocha replied that he did not want to jump the chain of command.
Source: Columbia Accident Investigation Board: Report, Volume I, Chapter 6, Decision Making at NASA (2003)
this is the wrong (and bordering on irresponsible) answer from the SSP and Orbiter not to request additional imaging help from any outside source.
Source: Columbia Accident Investigation Board: Report, Volume I, Chapter 6, Decision Making at NASA (2003)
Even after the imagery request had been cancelled by Program management
Source: Columbia Accident Investigation Board: Report, Volume I, Chapter 6, Decision Making at NASA (2003)
empowered any employee to stop an operation at the mere glimmer of a problem.
Unfortunately, NASAʼs views of its safety culture in those briefings did not reflect reality.
Even after it was clear from the launch videos that foam had struck the Orbiter in a manner never before seen
were largely silent during the events leading up to the loss of Columbia.
Many accident investigations make the same mistake in defining causes. They identify the widget that broke or malfunctioned, then locate the person most closely connected with the technical failure
Such corrections lead to a misguided and potentially disastrous belief that the underlying problem has been solved.
A central piece of our expanded cause model involves NASA as an organizational whole.
That silence was not merely a failure of safety, but a failure of the entire organization.
the causes of the institutional failure responsible for Challenger have not been fixed.
Seventeen years separated the two accidents.
problems cannot be solved simply by retirements, resignations, or transferring personnel.
The Board had a hard time understanding how, after the bitter lessons of Challenger, NASA could have failed to identify a similar trend.
P81. Plan-Do-Check-Act¶
The rule: repeat the cycle Plan → Do → Check → Act
Illustrative, not evidence.
Scenario. A team of six runs two-week sprints. In three sprints in a row, a release is delayed by the same flaky deployment step.
Applying the rule. Each retrospective turns its findings into tickets with an owner and a due date. The next retrospective starts by reviewing the open tickets from earlier cycles. The team checks whether the last change worked and then acts: it keeps the fix, or changes it. After the third delay the team changes the process by adding an automated deployment test. The check is met: actions from earlier cycles are tracked until they are completed.
Violating the rule. The team lists "make deployments more reliable" in every retrospective and never opens a ticket for it. Nobody looks at earlier notes. The same failure happens again with no process change.
Management variant.
Scenario. A department of 40 people holds a retrospective at the end of each quarter. Last quarter it agreed to shorten its approval chain.
Applying the rule. The department runs the cycle at fixed intervals: plan, do, check and act. It tracks every action to completion on a shared list. At the next quarterly review, the first agenda item is the status of last quarter's actions.
Violating the rule. The department holds the review only when something goes wrong. The actions are written in the minutes and never looked at again. The approval chain is as long as it was a year ago.
Real case: Space Shuttle Columbia foam strike and its organizational causes (2003). Read the full case above.
What it shows for P81. Seventeen years after Challenger, the board found that the causes of the institutional failure behind it had not been fixed, and that NASA had failed to identify a similar trend. P81's check closes that loop: actions from earlier cycles are tracked until they are completed.
P82. Investigate anomalies¶
The rule: record the anomaly and investigate it before you accept it as normal
Illustrative, not evidence.
Scenario. An integration test fails about one run in twenty. Developers rerun the pipeline until it goes green. Nobody has been hurt and no release has been blocked for more than an hour.
Applying the rule. A developer records the flaky test as an anomaly ticket on the day it is noticed. The team investigates and finds a race condition in test setup, which could also appear in production. The ticket ends with a decision: fix it, which they do. If the cause had been harmless, the ticket would carry a written reason for accepting it. The check is met: each anomaly has a ticket with a decision.
Violating the rule. The team adds an automatic retry that hides the failure and mutes the alert permanently. No ticket exists and no one has looked at the cause. The odd behaviour becomes normal, and the race condition ships to production unseen.
Management variant.
Scenario. Three projects in a row finish about two weeks late. Each one has a different stated reason, and none caused a serious problem.
Applying the rule. A programme manager records the three misses as one deviation and investigates them as a pattern. The study finds that estimates ignore the time taken by a shared testing team. The planning method is changed before the slip becomes the accepted norm.
Violating the rule. Each late project is closed on its own with "unlucky timing". Later plans quietly add two weeks, so the delay becomes normal. Nobody asks why it keeps happening.
Real case: Space Shuttle Challenger O-ring joint and launch decision (1986).
The Space Shuttle Challenger was lost when the seals in a joint of the right Solid Rocket Motor failed. The joint's O-rings had shown erosion and blow-by on earlier flights, and NASA and its contractor, Morton Thiokol, came to accept this as an acceptable flight risk instead of solving it. For this launch, the contractor's engineers had first recommended against launch below 53 degrees Fahrenheit. Their management reversed that position at the urging of NASA's Marshall Space Flight Center. The Rogers Commission found the decision to launch flawed, and found that it was based on incomplete and sometimes misleading information.
What it shows for P82. As O-ring damage recurred, NASA and Thiokol accepted escalating risk, apparently because they "got away with it last time." Tracking only the anomalies outside prior flight experience let major problems drop out of the reporting system. A recurring anomaly needs an investigation and a decision, not quiet acceptance.
the loss of the Space Shuttle Challenger was caused by a failure in the joint between the two lower segments of the right Solid Rocket Motor.
The decision to launch the Challenger was flawed.
the initial written recommendation of the contractor advising against the launch at temperatures below 53 degrees Fahrenheit
a decision to launch 51-L based on incomplete and sometimes misleading information
The waiving of launch constraints appears to have been at the expense of flight safety.
the Thiokol Management reversed its position and recommended the launch of 51-L, at the urging of Marshall and contrary to the views of its engineers in order to accommodate a major customer.
we were being put in a position to prove that we should not launch rather than being put in the position and prove that we had enough data to launch.
The genesis of the Challenger accident-the failure of the joint of the right Solid Rocket Motor-began with decisions made in the design of the joint
Morton Thiokol, Inc., the contractor
as tests and then flights confirmed damage to the sealing rings, the reaction by both NASA and Thiokol was to increase the amount of damage considered “acceptable.”
Neither organization developed a solution to the unexpected occurrences of O-ring erosion and blow-by even though this problem was experienced frequently during the Shuttle flight history. Instead, Thiokol and NASA management came to accept erosion and blow-by as unavoidable and an acceptable flight risk.
NASA and Thiokol accepted escalating risk apparently because they “got away with it last time.”
Tracking and continuing only anomalies that are “outside the data base” of prior flight allowed major problems to be removed from, and lost by, the reporting system.
P83. Preserve evidence¶
The rule: document and preserve the as-found state before you repair or restart anything, and record who handled the evidence (chain of custody)
Illustrative, not evidence.
Scenario. A service in a cluster starts crash-looping. Users see slower pages, but the team estimates it will be hours before real harm. The on-call engineer wants to restart the pods.
Applying the rule. Before any repair, the engineer captures the logs, a heap dump and a disk snapshot. She writes in the incident record what she captured, when, and who handled it. Only then does she restart the pods. The check is met: the incident record lists the evidence captured before the first repair action.
Violating the rule. The engineer restarts the service first. The new pods start with clean memory and rotated logs. When the team asks later what went wrong, nothing is left to examine and the cause stays a guess.
Management variant.
Scenario. A dismissed employee files a complaint. The company's chat tool deletes messages after 30 days, and a related channel is 25 days old.
Applying the rule. Once the complaint makes a dispute reasonably likely, the company stops routine deletion for the related mailboxes and channels. It preserves the records and logs who exported them and when. This is a legal hold.
Violating the rule. The company waits for a formal letter before changing anything. The auto-delete job runs five days later and the relevant messages are gone.