Cases5 cases

1 to 5 of 5

1. IL-0342 DigitalOcean's AMS3, LON1 and SFO2 data centers lost Internet connectivity in repeated waves as edge routers failed

   DigitalOcean2023

   Symptoms

   From 09:55 UTC on 9 August 2023, DigitalOcean's AMS3, LON1 and SFO2 datacenters lost Internet access in waves of 10 to 15 minutes, about an hour apart. Users saw connectivity issues, latency and timeout errors on Droplets and on Droplet-based services such as Load Balancers, Kubernetes and Database clusters.

   Network unreachableIntermittent timeoutsHigh latency

   Trigger

   The edge routers received an RPKI-related routing update, and the operating system software on them crashed its routing process on that update.

   Root cause

   Software defect

   Component

   BGP routing

   Contributing factor

   Excessive blast radiusHarmful manual action

   Remediation

   • Rolled out a software update to the edge routers running the affected version, site by site
   • Rebalanced traffic on the congested routes between AMS3 and FRA1
   • Rolled out the fix to the redundant networking equipment so a failover would not hit the bug

   Action items

   • Upgrade all global edge routers to remove the bug
   • Bring the network upgrades already done in Asia to Europe and North America

   View case
2. IL-0217 Honeycomb's main MySQL database locked up under cache-miss reads and ran out of connections, a 68-minute total outage

   Honeycomb2023

   Symptoms

   Hours after a routine switch between two clusters of Retriever, Honeycomb's storage and query engine, late on 24 July 2023, the internal SLO for Shepherd, the ingest service, began to burn slowly. The performance was only marginally slow and inconsistent, with no good explanation, so engineers treated it as minor and left it for the morning.

   High latencyDatabase overloadLock contention or deadlockService outage

   Trigger

   Late on 24 July Honeycomb switched between two Retriever clusters to avoid a subtle bug, and the new cluster stopped writing the last-written timestamps the schema cache depends on. On the morning of 25 July a feature flag flip meant to move those writes back stopped the remaining writes entirely.

   Root cause

   Software defect

   Component

   DatabaseIn-memory cache

   Contributing factor

   Dependence on a warm cacheIgnored early signalHarmful manual actionUnverified assumption

   Detection

   Hours after the cluster switch, the internal SLO for the ingest service Shepherd started burning slowly. Engineers left it for the morning, when a chart showed that Retriever's database calls updating the last-written records had stopped.

   Remediation

   • Flipped only the writes back to the other Retriever cluster with a feature flag, which did not fix the problem
   • Set up circuit breakers that denied all Shepherd traffic with a 5xx error to protect the database
   • Failed the hard-locked database over to a replica
   • Restarted all Retriever hosts so they could provide data for the cache
   • Set the last-written timestamp of every schema with traffic in the last day to now, so the schema store reloaded the cache
   • Removed the circuit breaker and restarted the query hosts that failed internal checks

   Action items

   • Finish the Retriever cluster migration and remove all code that could disable writes behind the cache
   • Explore ways to strengthen the cache further
   • Lower the contention put on the database during update storms from new schemas
   • Stabilise the performance costs of some operations in the system
   • Study instrumentation and experimentation that detect and handle such edge cases better

   Lessons

   Locally good decisions combined into the outage: the query engine wrote the timestamps because it already saw all the data, the shared cache helped scale ingest and untangle the main database, the cluster switch was done to avoid a bug, frequent deploys hid the feature flag bug, pausing deploys during the investigation kept hosts from restarting, and past near-misses made the team expect a slow failover. Feature flags, frequent deploys, pausing deploys during incidents and learning from near-misses all contributed, although they are among the practices Honeycomb trusts most. For a rare lockup of this kind a database failover is the fastest recovery. Several recent Honeycomb incidents started from trying to avoid a subtle bug.

   View case
3. IL-0213 Roblox was down for 73 hours because key-value writes on its single Consul cluster slowed from under 300 ms to 2 seconds

   Roblox2021

   Symptoms

   On the afternoon of 28 October 2021 (13:37 PST), Vault performance at Roblox degraded and a single Consul server showed high CPU load. Consul cluster metrics showed that writes to its key-value (KV) store had a 50th percentile latency of 2 seconds instead of the usual under 300 ms. Players were not yet affected.

   High latencySustained high node CPUService outageMonitoring outage

   Trigger

   On 27 October at 14:00, one day before the outage, Roblox enabled the Consul streaming feature on the backend service responsible for traffic routing and, to prepare for end-of-year traffic, added 50% more nodes to traffic routing.

   Root cause

   Software defect

   Component

   Coordination and key-value storeService discoveryIn-memory cache

   Contributing factor

   Single point of failureOverlapping failuresMonitoring blind spotHarmful manual actionChange with a delayed effect

   Detection

   Roblox engineers began investigating when Vault performance degraded and a single Consul server had high CPU load, before players were affected. Consul cluster metrics then showed elevated KV write latency.

   Remediation

   • Replaced one Consul cluster node on the suspicion of degraded hardware
   • Replaced all Consul nodes with 128-core machines with faster NVMe SSDs
   • Shut down the Consul cluster and reset its state from a snapshot taken at the start of the outage, with access blocked by iptables
   • Blocked external traffic, disabled all non-essential Consul use, scaled services down and lowered health check frequency from 60 seconds to 10 minutes
   • Moved the Consul cluster back to 64-core servers
   • Disabled the streaming feature for all Consul systems, which brought KV write latency back to 300ms
   • Kept the slow Consul servers from staying elected as leader
   • Redeployed the caching system and fixed its wrong scheduling data and failed deployments
   • Restarted the stopped services at the right capacity levels
   • Let players back in with DNS steering in roughly 10% steps while checking database load, cache performance and stability

   Action items

   • HashiCorp builds laboratory benchmarks and scale tests that reproduce the streaming contention
   • HashiCorp improves the design of streaming so it does not contend under extreme load
   • Compact the BoltDB database with existing BoltDB tooling
   • Remove the circular dependency between the telemetry systems and Consul
   • Extend telemetry with targeted alerts on Consul and BoltDB performance and with visibility into traffic between services and Consul
   • Run the backend in an additional, geographically distinct data center and in multiple availability zones
   • Split critical services into their own dedicated Consul clusters
   • Move data that core services keep directly in the Consul KV store to a more suitable storage system
   • Delete obsolete KV data from Consul
   • Upgrade to a Consul version that replaces BoltDB with bbolt, in Q1
   • Redesign cache deployment so the cache system can be brought up quickly from a standing start
   • Deploy Nomad enhancements that make it easier to turn up large jobs after a long period of unavailability
   • Use mechanisms for faster machine configuration changes
   • Reintroduce streaming only after a new implementation has been tested at Roblox's scale and workload

   Lessons

   Two mostly unrelated problems deep inside Consul, contention in streaming under very high read and write load and BoltDB freelist growth, were hard to diagnose, and that difficulty was the main reason the outage lasted so long. A single Consul cluster serving every workload made the impact larger, and monitoring that depended on Consul hid the cause when it was needed most. Faster hardware did not help and may have hurt, because the contention was worse on NUMA machines. HashiCorp had benchmarked streaming at a similar scale, but the problem needed both a large number of streams and a high churn rate. Restarting a platform from a fully stopped state, including warming caches, took a long time and needed tools built for bootstrapping rather than incremental change.

   View case
4. IL-0263 GitHub was slow and erroring all day and down for 18 minutes as links between access and aggregation switches saturated

   GitHub2012

   Symptoms

   On Friday, 30 November 2012, GitHub had sporadic bursts of slow responses and intermittent errors for the whole day and was completely unavailable for 18 minutes. One fileserver pair was offline for a large part of the day, which affected a small percentage of repositories; this was a side effect of the network problems on the high-availability clustering between the fileserver nodes.

   High latencyHigh error rateService outage

   Trigger

   On the morning of 30 November GitHub moved the A switches in its server cabinets onto the new aggregation switches, the second half of a migration whose B-switch half had been done the day before.

   Root cause

   Software defect

   Component

   Network switchNIC, cable and switch port link

   Contributing factor

   Overlapping failuresUnverified assumptionHarmful manual action

   Detection

   Engineers saw the problems during the maintenance itself: connectivity to the B switch was lost as the last A switch was connected, and afterwards performance stayed low and the links between access and aggregation switches showed as completely saturated.

   Remediation

   • Fixed the bridge-loop problem and returned the affected B switch to service
   • Removed the partial link failure detection setting from the access switches
   • Escalated to the network vendor, which raised the case to its highest severity level
   • Restarted core processes on the aggregation switches in a Saturday 0600 Pacific maintenance window so they learned MAC addresses again

   Action items

   • Deploy the vendor's software update that fixes the MAC learning issue to the switches
   • Closely monitor aggregation-to-access capacity and keep a workaround process ready if the problem returns
   • Build a duplicate of the network stack, from the routers through the access switches, as a staging environment for testing such changes
   • Add automated network monitoring that alerts sooner on similar issues
   • Run scheduled incident response exercises with scenarios that counter tunnel vision
   • Contact the network vendor's support at the first sign of trouble in the network

   Lessons

   GitHub had designed the maintenance to have no impact on customers and clearly failed, so it plans to invest in a staging copy of its network to test such changes and catch bugs like this one. During the response the team fixated for a long time on a bridge loop, which kept it from considering other causes. GitHub had a very positive experience with the vendor's support staff, so it will contact that support team at the first sign of network trouble.

   View case
5. IL-0303 GitHub's MySQL master failed over to a node with a cold buffer pool during a schema migration and GitHub.com went down

   GitHub2012

   Symptoms

   On Monday, September 10th, 2012, during a schema migration, the health checks on GitHub's MySQL master failed and Percona Replication Manager moved the 'active' role to another node of the new three-node cluster. That node's InnoDB buffer pool was cold and it performed poorly, its health checks failed in turn, and the role failed back to the original server. GitHub.com went down.

   Failover failureDatabase overloadHigh latencyReplication lagSplit brainService outage

   Trigger

   A schema migration on Monday, September 10th put more load on the master database than earlier migrations had, and Percona Replication Manager's health checks on the master failed.

   Root cause

   Software defect

   Component

   DatabaseDatabase failover managerDatabase replication

   Contributing factor

   Automation amplificationDependence on a warm cacheHarmful manual actionOverlapping failures

   Detection

   On the morning of September 11th, a developer told the operations team that the 'standby' node was returning incorrect query results.

   Remediation

   • Enabled Pacemaker's maintenance-mode so no health checks or automatic failovers ran, and let the buffer pool warm
   • Powered off the out-of-date node 'c' to end the partition
   • Stopped Pacemaker and Heartbeat on nodes 'a' and 'b' and started them on node 'a' only
   • Started MySQL on node 'a' in the active role
   • Removed the events leaked to wrong dashboards and audited the wrongly routed repositories
   • Contacted the owners of the exposed private repositories

   Action items

   • Change the Pacemaker configuration so the active database role fails over only when an operations engineer starts it
   • Find a way to warm the InnoDB buffer pool of slave databases so failovers do not hurt performance
   • Audit the Pacemaker and Heartbeat stack, focusing on the code path behind the segfault
   • Run hardware tests on the server where the segfault happened

   Lessons

   GitHub concluded that automated failover is not the right strategy for its primary production database: for every failover in this incident, any member of the operations team would have said it should not happen. Failovers that must happen, in an emergency or during maintenance, should not hurt performance.

   View case

By root cause1