Incident Library
Applied filters Root causeOperator errorFactorCircular dependencyClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases2 cases

1 to 2 of 2

  1. Symptoms

    On 4 October 2021 Facebook's platforms went down worldwide: every connection in Facebook's global backbone network was lost, and the data centers were cut off from each other and from the internet. The rest of the internet could no longer find Facebook's servers, because Facebook's authoritative DNS servers had become unreachable.

    Trigger

    During routine maintenance of the backbone, a command was issued to assess the availability of global backbone capacity, and it unintentionally took down all connections in the backbone network.

    Root cause
    Component
    Contributing factor
    Remediation
    • Sent engineers onsite to the data centers to debug the issue and restart systems
    • Brought the backbone network back online across the data center regions
    • Brought services back gradually, managing the rising load to avoid crashes from a traffic surge
    Action items
    • Find ways to simulate the global backbone being taken offline in storm drills
    • Strengthen testing, drills and overall resilience
    Lessons

    The hardening that protects Facebook's data centers against unauthorized access slowed recovery from an outage caused by Facebook's own error, and the author judges that tradeoff worth keeping. Storm drills prepared the teams to bring load back safely, although no drill had yet simulated the global backbone going offline.

  2. Symptoms

    From 9:37AM PST on February 28th, 2017, Amazon S3 in the Northern Virginia (US-EAST-1) Region could not serve requests. AWS services in the region that store data in S3 failed with it, including the S3 console, new Amazon EC2 instance launches, Amazon EBS volumes that needed data from an S3 snapshot, and AWS Lambda.

    Trigger

    While debugging an S3 billing system that was progressing more slowly than expected, an authorized S3 team member followed an established playbook to remove a small number of servers from one S3 subsystem used by the billing process, and entered one input of the command incorrectly.

    Root cause
    Component
    Contributing factor
    Remediation
    • Restarted the index subsystem, which served GET, LIST and DELETE again from 12:26PM PST
    • Restarted the placement subsystem after the index subsystem worked, restoring PUT by 1:54PM PST
    Action items
    • Change the capacity removal tool to remove capacity more slowly
    • Add safeguards that stop capacity removal when it would take a subsystem below its minimum required capacity
    • Audit other operational tools for similar safety checks
    • Improve the recovery time of key S3 subsystems and start the planned further partitioning of the index subsystem into cells now
    • Run the SHD administration console across multiple AWS regions
Check your cluster for this

These 2 cases involve Backbone network (WAN) and BGP routing. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1