Graph
Cases2 cases
1 to 2 of 2
IL-0491Squarespace's CDN origin fleet fell below its healthy node threshold, and images, scripts and stylesheets failed to loadSquarespace2019- Symptoms
At 12:10 AM ET on Tuesday, February 12, 2019, Squarespace's monitoring alerted the on-call engineer for the CDN origin fleet that the fleet had fallen below a safe number of healthy nodes. Requests to static.squarespace.com and static1.squarespace.com failed, so images, scripts and style sheets did not load for some sites, and the status page later reported elevated error rates serving media and stylesheets.
- Trigger
At 10:30 PM ET on February 11, an engineer started a maintenance operation across the CDN origin fleet. The operation kept running in the background after the engineer believed it had been terminated.
- Root cause
- Component
- Contributing factor
- Detection
The monitoring system alerted the CDN origin fleet's on-call engineer at 12:10 AM ET when the fleet fell below a safe number of healthy nodes.
- Remediation
- Restored the CDN origin fleet, partially by 2:15 AM ET and to normal behaviour at 2:20 AM ET
- Action items
- Revise the incident-response playbooks with checks and actions for this fleet, starting with an assessment of customer impact and the immediate involvement of an Incident Commander
- Improve external monitoring to assess customer impact of issues with the CDN partners and origin services more quickly
- Revise operational policies and add safeguards for issuing maintenance commands, including limiting the share of the fleet a command can operate on
- Reduce the need for direct manual maintenance operations
- Create independent failure domains and route requests automatically around unhealthy parts of the system
- 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 2 cases involve Cloud block storage and CDN and edge network. 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 error2 cases
- Contributing factor
- Organisation