Graph
Cases4 cases
1 to 4 of 4
- 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
IL-0218GitLab.com's primary PostgreSQL data was wiped by mistake and, with no working backup, the site was down about 18 hoursGitLab2017- Symptoms
From around 19:00 UTC on 31 January 2017, load on GitLab.com's PostgreSQL database rose, which GitLab suspected was spam, and many users could not post comments on issues and merge requests. Around 23:00 UTC the replication of the PostgreSQL secondary fell behind and then failed, because WAL segments it still needed had already been removed from the primary.
- Trigger
While trying to restore replication to the secondary, an engineer ran the removal of the PostgreSQL data directory on the primary, db1.cluster.gitlab.com, believing it was the secondary.
- Root cause
- Component
- Contributing factor
- Detection
The engineer who ran the deletion on the primary noticed the mistake and stopped it a second or two later.
- Remediation
- Raised max_wal_senders from 3 to 32 and lowered max_connections from 8000 to 2000 so PostgreSQL would restart
- Stopped the deletion on the primary a second or two after noticing it
- Restored the database from the LVM snapshot taken about 6 hours before the outage by copying the PostgreSQL data directory from staging
- Restored the webhooks from a separate database built from the snapshot and imported them as a SQL dump
- Incremented all database sequences by 100,000 so IDs used before the outage could not be reused
- Re-enabled GitLab.com gradually
- Rebuilt projects created after 17:20 UTC in basic form from their Git repositories on the NFS cluster
- Action items
- Change the shell prompt (PS1) on all hosts to show more clearly which host and environment is in use
- Monitor backups with Prometheus
- Set PostgreSQL's max_connections to a sane value
- Investigate point-in-time recovery and continuous archiving for PostgreSQL
- Take LVM snapshots of the production databases every hour
- Take Azure disk snapshots of the production databases
- Move staging to the ARM environment
- Recover the production replicas
- Test recovery of PostgreSQL database backups automatically
- Improve the PostgreSQL replication documentation and runbooks
- Investigate pgbarman for PostgreSQL backups
- Investigate WAL-E for database backup and realtime replication
- Build a streaming database restore
- Assign an owner for data durability
- Set up multiple secondaries and balance load among them with pgpool-II
- Provide a tool for developers to run and revert Rails migrations on staging
- Build owned recovery procedures for the rest of the GitLab.com infrastructure, not only the database
- Publish a backup monitoring dashboard and add more backup data to it
- Improve the abuse reporting and response system so removal for spam does not hard delete
- Redact engineers' names in future public incident documents
- Lessons
GitLab split the incident into two problems: GitLab.com went down because the primary's data directory was removed by mistake during a manual, undocumented replication rebuild, and recovery took over 18 hours because the backups had failed silently, disk snapshots were not enabled and the only copy sat on slow staging disks. The backup procedure was never tested because no one owned it. GitLab chose to focus on fast, regularly practised recovery and on making it obvious which host an engineer is on, rather than on blocking commands, since a safer rm only protects against one of many ways to lose data.
IL-0538Sakura Cloud storage maintenance deleted 53 in-use customer disks, and the disks could not be restored from backupSakura Internet2012- Symptoms
During emergency maintenance on 5 January 2012, a bulk deletion of unneeded file systems on the Sakura Cloud storage device also deleted 53 disks that customers were using. The deleted disks could not be restored from backup.
- Trigger
In the emergency maintenance on 5 January 2012, Sakura Internet ran a batch command written only for that maintenance to delete unneeded file systems on the storage device in bulk.
- Root cause
- Component
- Contributing factor
- Action items
- Simplify the process for deleting unneeded file systems
- Do not run scripts that have not been reviewed and tested enough
- Symptoms
From 12:47 AM PDT on 21 April 2011, a subset of Amazon EBS volumes in one Availability Zone of the US East Region could no longer serve reads or writes, and EC2 instances that tried to use them got stuck as well. AWS called these "stuck" volumes. EBS API calls across the whole US East Region also returned high error rates and latencies during two periods on the first day.
- Trigger
During a routine network change to upgrade the capacity of the primary EBS network in one Availability Zone, traffic was to be shifted off one of the redundant routers. The shift was executed incorrectly and sent the traffic onto the lower-capacity replication network instead of the other primary router, which could not carry it.
- Root cause
- Component
- Contributing factor
- Remediation
- Rolled back the incorrect traffic shift, which restored network connectivity
- Disabled all new Create Volume requests in the affected Availability Zone at 2:40 AM PDT
- Disabled all communication between the degraded EBS cluster and the EBS control plane from 8:20 AM PDT
- Stopped EBS servers in the degraded cluster from futilely contacting other servers for free space
- Changed the EBS control plane so new EBS-backed instance launches stopped failing
- Moved spare server capacity physically from across the US East Region into the degraded cluster
- Adjusted the negotiation throttles so the new servers could join without flooding the old ones
- Built a separate EBS control plane partitioned to the affected zone and finer-grained throttles, then processed the backlog
- Restored the remaining volumes from S3 snapshots taken early in the event
- Restored volumes on failed machines that had no snapshot after forensic work
- Intervened by hand on the RDS multi-AZ instances that did not fail over automatically
- Action items
- Audit the change process and add automation to prevent the traffic shift mistake
- Change capacity planning and alarming to keep the extra safety capacity needed for large recovery events
- Change the retry logic in EBS nodes to back off harder and reconnect to previous replicas instead of searching for new nodes
- Test and deploy the fix for the race condition that crashed EBS nodes
- Fix the RDS bug that kept multi-AZ instances from failing over automatically
- Improve the EBS control plane timeout logic to prevent thread exhaustion when one zone's cluster is slow
- Make the EBS control plane aware of Availability Zones so it sheds load when over capacity
- Move more EBS control plane functions into per-cluster services that run in the same zone as the cluster
- Offer multiple Availability Zones to Amazon VPC customers
- Provide better tools for building multi-AZ applications that survive the loss of a zone
- Host free webinars and publish whitepapers on fault-tolerant architecture
- Build the fine-grained control and throttling used in recovery into the EBS nodes and automate the recovery models
- Look at changes that keep volumes working while a cluster is degraded, including the ability to take a snapshot of a stuck volume
- Send more frequent and detailed customer updates and staff developer support more widely during events
- Develop tools that show through the APIs whether instances are impaired
- Lessons
AWS writes that with more spare capacity the cluster would have absorbed the re-mirroring requests without a storm, and that it now understands how much capacity large recovery events need. The event also showed that the EBS control plane let a failure in one Availability Zone affect the others, so more work is needed to make zones behave as if completely independent. AWS adds that some customers had critical components in a single zone, and that multi-AZ deployments need to become easier to design and run.
These 4 cases involve Cloud block storage and Database. 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
Operator error4 cases
- Component
- Contributing factor
- Organisation
IL-0534Amazon S3 in US-EAST-1 could not serve GET, LIST, PUT or DELETE requests for hours while its index subsystem restartedIL-0218GitLab.com's primary PostgreSQL data was wiped by mistake and, with no working backup, the site was down about 18 hoursGitLab2017IL-0538Sakura Cloud storage maintenance deleted 53 in-use customer disks, and the disks could not be restored from backupSakura Internet2012IL-0337EBS volumes in one US East Availability Zone got stuck after a network change cut EBS nodes off from their replicas