proomt

Search

Search posts, papers, and topics

Hall of Fame

Hall of FameDan Luu201510 min readintermediate

Reading postmortems

Summary

Dan Luu surveys public postmortems and finds that most severe outages stem from a handful of recurring causes—poor error‑handling code, risky configuration changes, hardware faults, manual processes, and missing monitoring/alerting. He backs the claims with study numbers and argues engineers should focus on testing, automation, and observability to cut these failure modes.

  • Bad error‑handling code causes cascading failures; 92% of critical failures in a study were due to mishandled errors.
  • Configuration changes account for roughly half of public postmortems and often lack proper testing before rollout.
  • Hardware faults, including silent DRAM errors, occur far more frequently than advertised specifications.
  • Manual operational steps are a common source of outages; automating repeatable procedures can eliminate many human‑error cases.

Ops and reliability engineers should prioritize robust error handling, safe config deployment, hardware awareness, automation, and observability to reduce outage risk.

6/10

Related reading

  1. Best practices for handling cloud reliability incidents

    The article outlines a structured Verify→Investigate→Report→Resolve→Review workflow for GCP reliability incidents and stresses pre‑incident preparation across design, data, playbooks, and training. It lists concrete tools (Cloud Logging, Service Health, Gemini Assist) and reporting steps to help engineers reduce outage impact.

    Google Cloud Bloggoogle.com11 min
  2. The Flaky Test Confession: “We All Know We’re Ignoring Test Failures”

    Flaky tests silently erode CI reliability, waste compute and developer time, and let real bugs slip into production. The post quantifies the cost (≈2.5 % of developer time, $5.67 per manual investigation vs $0.02 for auto‑rerun) and critiques common band‑aid approaches (retries, quarantine, manual triage). It argues that visibility—detecting flaky tests, predictive test selection, and automated t…

    Codeshipcloudbees.com5 min
  3. How Complex Systems Fail

    Cook argues that complex system accidents arise from multiple interacting faults, making the notion of a single root cause meaningless, and that hindsight bias skews post‑incident analysis. Understanding failure as a social construct shifts focus to systemic improvement.

    Hall of Famecomplexsystems.fail2 min
  4. Can we stop with the uptime percentages?

    This article argues that uptime percentages are a poor public interface for communicating service reliability because their non-linear nature is not intuitive to non-infrastructure people. It proposes showing absolute downtime (e.g., hours affected) alongside percentages for better clarity for a general audience.

    Hacker News front pagejim-nielsen.com2 minHN144112
  5. How Uber Protects Against Retry Storms

    Uber developed a context-aware mechanism to prevent retry storms in deep microservice dependency chains. It introduces "error ownership" where services claim errors they originate and unclaim errors they propagate, allowing upstream callers to make informed retry decisions and avoid amplifying load on already struggling services.

    Hacker News front pageuber.com12 minHN11949