Advanced PostMortem Fu and Human Error 101 (Velocity 2011)

Advanced PostMortem Fu and Human Error 101 (Velocity 2011)
Advanced PostMortem Fu & Human Error 101 John Allspaw VP, Tech Ops Velocity 2011
We Want YOU etsy.com/careers
Science TimeTravel Mythbusting Reading Homework
Here To Challenge You
Resilience Engineering Dr. Erik Hollnagel Dr. David Woods Dr. Sidney Dekker Dr. Richard Cook
Complex, Dynamic
Fundamental Surprises
E.T.T.O. Efficiency Thoroughness
Organizations, Policies, Procedures, Regulations BLUNT Resources & Constraints
Organizations, Policies, Procedures, Regulations BLUNT Resources & Constraints Slips Adjustments Operators Compensations Mistakes Lapses Recoveries Violations Improvisations SHARP
FUTURE + PAST
Why Do Them?
Why? Understand the failure
Why? Understand the system
Where “System” = Networks Servers Applications Processes People
Where “System” = Networks Servers Applications Processes People
People
(Anticipation) Knowing What To Expect
(Anticipation) Knowing Knowing What What To Expect To Look For (Monitoring)
(Anticipation) (Response) Knowing Knowing Knowing What What What To Expect To Look For To Do (Monitoring)
(Anticipation) (Response) Knowing Knowing Knowing Knowing What What What What To Expect To Look For To Do Has Happened (Monitoring) (Learning)
Microphones are ON?
Event Awareness Code Deploys
TIMELINE IRC logging = Rich Data
TIMELINE Traces of Data IRC logging = Rich Data
IRC Logs Fed Into Solr
Status Blog Twitter Feed
Flight Data Recorder
Annotation Traces
Investigation Basics
Start?
TTD How?
TTR
Stable (“all clear”)
Impact Time = TTR - Start
SEVERITY
Severity 1 A. Total loss of service B. Severe degradation, effectively unusable C. Loss of a critical feature
Severity 2 A. Major degradation/feature loss for SUBSET of members B. Minor degradation/feature loss for ALL members
Severity 3 Noticeable non-critical feature loss or degradation
Severity 4 No visible impact, loss of redundancy or capacity headroom
Severity 5 No-impact but unexpected failure
5/11/2011 - Payments/Checkout system issue Start 4:10pm TTD 4:15pm TTR 4:30pm Stable 4:35pm Total Impact 20 min Severity 1
• Basic metrics • Timeline with details • Remediations/Observations
“normal” Incident PostMortem operation Time
How? Why? Prevention?
How
Crisis Patterns Problem Starts PostMortem Time
Crisis Patterns Problem Starts Detection PostMortem Time
Crisis Patterns Problem Starts Detection Evaluation PostMortem Time
Crisis Patterns Problem Starts Detection Evaluation Response PostMortem Time
Crisis Patterns Problem Starts Detection Evaluation Response Stable PostMortem Time
Crisis Patterns Problem Starts Detection Evaluation Response Stable PostMortem Confirmation Time
Crisis Patterns Problem Starts Detection Evaluation Response Stable PostMortem Confirmation All Clear Time
Crisis Patterns Problem Starts Stress Detection Evaluation Response Stable PostMortem Confirmation All Clear Time
Problem Starts Detection Evaluation Response Stable PostMortem Confirmation All Clear Time
Problem Starts Detection Evaluation Response Stable PostMortem Confirmation All Clear Time
Problem Starts Detection Evaluation Response Stable PostMortem Confirmation All Clear Time Internal and External Update Communications
Crisis Patterns Problem Starts Detection Evaluation Response Stable Confirmation All Clear Time
Crisis Patterns
Crisis Patterns Forced beyond learned roles
Crisis Patterns Forced beyond learned roles Actions whose consequences are both important and difficult to see
Crisis Patterns Forced beyond learned roles Actions whose consequences are both important and difficult to see Cognitively and perceptively noisy
Crisis Patterns Forced beyond learned roles Actions whose consequences are both important and difficult to see Cognitively and perceptively noisy Coordinative load increases exponentially
Thematic Vagabonding “butterfly minds” NOT STUCK ENOUGH
Goal Fixation (encystment) TOO STUCK
Heroism Non-communicating lone wolf-isms
Distraction Irrelevant noise in comm channels
IMPROVISATION REQUIREMENT for troubleshooting complex systems
IMPROVISATION
IMPROVISATION
Why?
Root Cause Analysis “With the unknown, one is confronted with danger, discomfort, and care; the first instinct is to abolish these painful states. First principle: any explanation is better than none.” Friedrich Nietzsche Twilight of the Idols, or How to Philosophize with a Hammer
Hindsight Bias Knowledge of the outcome influences the analysis of the process Makes steps towards failure appear foreseeable and obvious
After The Fact
After The Fact
Reality: Before and During
Hindsight Bias “Should have known better” “All the signs were there, you just needed to pay attention”
Hindsight Bias BEFORE accident: The future seems implausible AFTER accident: Obviously clear: “how could they not see what mistake they were about to make”
Hindsight Bias “...people’s need to be right is stronger than their ability to be objective.” N. Crawford American Psychological Association
Outcome Bias Judging a past decision based on its outcome.
ID Fishbone/Ishikawa FMEA Five Whys Fault Tree CED CRT
why? OUTAGE
why? because this OUTAGE
why? why? because this OUTAGE
why? why? because because this this OUTAGE
why? why? why? because because this this OUTAGE
why? why? why? because because because this this this OUTAGE
why? why? why? because because because this this this OUTAGE but: WHY?
which caused Some Caused other Action Some Things things OUTAGE to happen
Sequence-Of-Events
• Satisfyingly simple, easy to explain and document
• Satisfyingly simple, easy to explain and document • Solves for a specific case • Ignorant of surrounding circumstances • Too focused on components • Validates Hindsight and Outcome bias
NOT HELPFUL • Satisfyingly simple, easy to explain and document • Solves for a specific case • Ignorant of surrounding circumstances • Too focused on components • Validates Hindsight and Outcome bias
Epidemiological (adapted from Reason, 1990)
(adapted from Reason, 1990)
Holes = Active/Latent Failures, Bad Things™ Waiting to Happen (adapted from Reason, 1990)
Holes = Active/Latent Failures, Bad Things™ Waiting to Happen Cheese = Safety Barriers, Layers of Defense (adapted from Reason, 1990)
(adapted from Reason, 1990)
Code Servers (adapted from Reason, 1990)
Code Servers Schedule Training (adapted from Reason, 1990)
Unmonitored Disk Space (latent condition)
Capacity Unmonitored Disk Space Miscalculation (latent condition) (latent condition)
Capacity Unmonitored Disk Space Miscalculation (latent condition) (latent condition) Unit Test In Transition
Violation of known coding Capacity standards Unmonitored Disk Space Miscalculation (latent condition) (latent condition) (latent condition) Unit Test In Transition
Violation of known coding Capacity standards Unmonitored Disk Space Miscalculation (latent condition) (latent condition) (latent condition) Unit Test In Bug Introduced Transition (active failure)
Violation of known coding Capacity standards Unmonitored Disk Space Miscalculation (latent condition) (latent condition) (latent condition) Unit Test In Bug Introduced External API call Transition (active failure) (active failure)
Violation of known coding Capacity standards Unmonitored Disk Space Miscalculation (latent condition) (latent condition) (latent condition) Unit Test In Bug Introduced External API call Transition (active failure) (active failure) FAILURE!
Capacity Miscalculation (latent condition) Unit Test In Bug Introduced External API call Transition (active failure) (active failure)
Capacity Miscalculation (latent condition) Unit Test In Bug Introduced External API call Transition (active failure) (active failure) NO FAILURE!
• Better than dominoes, but still linear layers of “defense” • Helps uncover multiple contributors and latent failures (at sharp and blunt ends)
• Better than dominoes, but still linear layers of “defense” • Helps uncover multiple contributors and latent failures (at sharp and blunt ends) • Doesn’t explain lineups or orientation of holes • Only identifies defects/gaps, nothing more • Still encourages judgements of decisions
Better, but still NOT HELPFUL • Better than dominoes, but still linear layers of “defense” • Helps uncover multiple contributors and latent failures (at sharp and blunt ends) • Doesn’t explain lineups or orientation of holes • Only identifies defects/gaps, nothing more • Still encourages judgements of decisions
Multiple Contributors “each necessary but only jointly sufficient”
Resultant Versus Emergent
Systemic Database Router Memcache Webserver
Systemic Database Router Memcache Webserver Feature Roadmap
Systemic Database Router Memcache Last Round Webserver of Funding Feature Roadmap
Systemic Dashboard Design Database Router Memcache Last Round Webserver of Funding Feature Roadmap
Systemic Dashboard Design Database Router Memcache Last Round Webserver of Funding Feature Roadmap DBA’s car
Systemic Dashboard Design Database Router Memcache Last Round Webserver of Funding Feature Roadmap No Eng DBA’s car Training
Systemic Dashboard Design Database Router Memcache Last Round Webserver of Funding Feature Email is Roadmap down No Eng DBA’s car Training
Systemic Dashboard Design Database Router Memcache Last Round Webserver of Funding Feature Email is Roadmap down Entire Ops Team No Eng Is At DBA’s car Training Velocity
Systemic Dashboard Design Database Router Memcache Last Round Webserver of Funding Feature Email is Roadmap down Entire Ops Team No Eng Techcrunch Is At DBA’s car Training Article Velocity
Systemic Hiring Dashboard Design Difficulties Database Router Memcache Last Round Webserver of Funding Feature Email is Roadmap down Entire Ops Team No Eng Techcrunch Is At DBA’s car Training Article Velocity
Systemic Hiring S3 is slow Dashboard Design Difficulties Database Router Memcache Last Round Webserver of Funding Feature Email is Roadmap down Entire Ops Team No Eng Techcrunch Is At DBA’s car Training Article Velocity
Systemic Hiring S3 is slow Dashboard Design Difficulties Database Router Memcache Last Round Webserver of Funding Feature Email is Roadmap down Entire Ops Team No Eng Techcrunch Is At DBA’s car Training Article Velocity
Systemic
Systemic
Systemic
Systemic
Systemic
Systemic
Systemic
Functional Resonance In isolation, components act within bounds. Interconnected, they produce emerging behaviors.
Causes Are Constructed, Not Found WYLFIWYF Pre-conceived notions on “causes” and behaviors
Contributors, not causes
There is no root cause.
LEARNING
Quantifying Response Time to detect? Time for escalation, internal notification? Time to notify the public? Time to graceful degradation? (feature off) Time to stable/resolve? Time to all clear?
Qualifying Response High signal:noise in comm channels? Troubleshooting fatigue? Troubleshooting handoff? All tools on-hand? Metrics visibility? Collaborative and skillful communication? Improvised tooling or solutions?
All Together Now • Start/TTD/TTR/Stable/etc. • Severity • DATA (graphs, IRC, etc.) • Description (timeline, etc.) • Observations (motivations, latent conditions, etc.) • Actions (remediation tickets, followup)
Human Error “...knowledge and error flow from the same mental sources, only success can tell one from the other.” Ernest Mach, 1905
Human Error Nobody comes to work to do a bad job.
Human Error Useless as a label and ending point.
Human Error Human error isn’t a cause, it’s an effect.
Why did it make sense to the person at the time?
Error Categories • Slips • Lapses • Mismatches • Violations
Error Categories
First Stories “Human error” seen as root cause. Counterfactuals: saying what they “should” have done. Prevention: be “more careful!”
Second Stories “Human error” seen as systemic vulnerabilities, deeper inside the organization. Digging into why it made sense for them to do what they did, at the time they did it. Prevention...
Substitution Test Could peers have made the same error under the same circumstances?
WHERE to learn from ?
Two Propositions
100 deploys 6 deploy-related issues
100 > 6
Proposition #1 “Ways in which things go right are special cases of the ways in which things go wrong.”
Proposition #1 Successes = failures gone wrong Study the failures, generalize from that. data sources: 6 out of 100
Proposition #2 “Ways in which things go wrong are special cases of the ways in which things go right.”
Proposition #2 Failures = successes gone wrong Study the successes, generalize from that data sources: 94 out of 100
94/100 ? OR 6/100 ?
What and WHY Do Things Go RIGHT?
Not just: why did we fail? But also: why did we succeed?
Near Misses Hey everybody - Don’t be like me. I tried to X, but because it was no good. It almost exploded everyone. So, don’t do: (details about X) Love, Joe
Taking the New View Recognize that human error is an attribution.
Taking the New View Pursue Second Stories.
Taking the New View Escape Hindsight Bias.
Taking the New View Understand work as performed at the sharp end.
Taking the New View Examine how changes (at all layers) will produce new vulnerabilities.
Taking the New View Use technology to support and enhance human expertise.
Taking the New View Tame complexity through new forms of feedback.
Taking the New View Realize that your systems are not inherently safe.
Taking the New View Human error is an inevitable by-product of strained complex systems.
Taking the New View Human error isn’t at the root of your safety problems.
Taking the New View Human error isn’t random.
Just Culture
Just Culture Balancing accountability with learning.
Intentional Malice
Negligence Found Severity of the Outage
Name Blame Shame
Name Blame Shame
Name WHY? Blame #!@%$&# Shame
“Must set an example!”
“Has to be some fear that not doing one’s job correctly could lead to punishment.”
“Must set an example!” Punishing Deterrents is a not “Has to be some fear that Losing could doing one’s job correctly Proposition lead to punishment.”
Holding People Accountable != Blaming People
Accountability and Learning Punishment For Errors
No Bad Apples Only Bad Theories of Error
Name WHY? Blame #!@%$&# Shame
Signs Of Old View “Gross Misconduct” “Carelessness” “Negligence” “Egregious Behavior” “Willful Violations”
Discretionary Spaces
Acceptable Unacceptable
Acceptable (who draws this subjective line?) Unacceptable
Increase Accountability By Supporting Learning
Empower People Let them own their own stories. Don’t make people pay penalties. Allow them to educate the organization.
Reduce Uncertainty Make it clear who defines acceptable behavior.
Organizational Roots Accountability = Responsibility + Requisite Authority
(Thanks, Fellas) Dr. Erik Hollnagel Dr. David Woods Dr. Sidney Dekker Dr. Richard Cook
Homework!
We Want YOU etsy.com/careers
• Photo Credits http://www.flickr.com/photos/51035644987@N01/2678090600/ • http://www.flickr.com/photos/67196253@N00/2941655917/ • http://www.flickr.com/photos/stirwise/417629641 • http://www.flickr.com/photos/38383999@N06/3888057995/ • http://www.flickr.com/photos/94443490@N00/361543080/ • http://www.flickr.com/photos/7729940@N06/4333396494/ • http://www.flickr.com/photos/cpstorm/167418602 • http://www.flickr.com/photos/63474264@N00/4366221069/ • http://www.flickr.com/photos/proimos/4199675334 • http://www.flickr.com/photos/30475691@N07/2862060992/ • http://www.flickr.com/photos/14663487@N00/797755046/ • http://www.flickr.com/photos/25080113@N06/5361445631/
THE END

Check these out next

Advanced PostMortem Fu and Human Error 101 (Velocity 2011)

Recommended

More Related Content

Slideshows for you(11)

Viewers also liked(20)

More from John Allspaw(16)

Recently uploaded(20)

Advanced PostMortem Fu and Human Error 101 (Velocity 2011)