Cases2 cases

1 to 2 of 2

1. IL-0424 A Nebius Compute API release wrongly saw VMs as missing and restarted 282 VMs in eu-north1, leaving 164 stuck for hours

   Nebius2024

   Symptoms

   On 26 November 2024 at 13:48 (UTC+1), right after a new release was deployed to Nebius's eu-north1 region, 282 virtual machines restarted at once and customer workloads on them were interrupted. 86 of them came back on their own within two minutes, but 196 got stuck and could not restart.

   Unexpected VM restartsService outage

   Trigger

   Deployment of a new release, with a faulty change in the VM recovery sequence, to eu-north1 at 13:48 (UTC+1).

   Root cause

   Faulty deployment

   Component

   Cloud compute control plane

   Contributing factor

   Unverified assumptionAutomation amplification

   Detection

   Internal monitoring alerted on the large number of stuck VMs at 14:03 and phoned the on-call engineers; the first customer report came over Slack at the same time.

   Remediation

   • Halted all automatic recovery operations to prevent further impact
   • Split the affected VMs into those that had restarted and those stuck and needing manual work
   • Tested a mitigation procedure on individual VMs before applying it
   • Stopped the stuck VMs to interrupt their stuck processes and restarted them in controlled batches

   Action items

   • Add testing for recovery scenarios before deployment
   • Enforce stricter validation of VM state changes
   • Rate-limit recovery processes
   • Improve monitoring and anomaly detection of VM activity
   • Add safety checks to deployment procedures
   • Escalate large-scale VM events faster
   • Improve customer notifications and engagement, and refine internal communication protocols for incident response

   Lessons

   The staged manual recovery worked but needed close monitoring and hands-on work, which showed that better automation of recovery procedures would shorten the response to similar incidents.

   View case
2. IL-0229 bunny.net's DNS servers crashed in a loop on a corrupted routing database file and could not fetch a fix from its CDN

   bunny.net2021

   Symptoms

   On 22 June 2021, within minutes of an update released at 8:25 AM UTC, bunny.net's global fleet of close to 100 DNS servers kept crashing and restarting, more than 60% of traffic was lost, hundreds of Gbits of throughput disappeared, and over 750,000 websites were affected. After 10 minutes the team realised that the DNS servers were restarting and dying and that nothing could bring them back up in that state.

   Container crash loopDNS resolution failuresService outageMisrouted requestsLoad imbalance

   Trigger

   At 8:25 AM UTC bunny.net released an update meant to reduce the download size of the SmartEdge optimization database, and it uploaded a corrupted file to Edge Storage.

   Root cause

   Faulty deployment

   Component

   Authoritative DNS servers and recordsCDN and edge networkObject storage

   Contributing factor

   Circular dependencySingle point of failureAutomation amplificationIneffective rollbackHarmful manual action

   Detection

   About 10 minutes after the release, the team realised that the DNS servers were restarting and dying.

   Remediation

   • Deployed by hand an update that disabled the SmartEdge system on the DNS nodes
   • Routed all requests through Frankfurt instead of Madrid on a couple of DNS servers
   • Migrated the deployment systems and files to a third-party cloud storage service
   • Rewired the deployment system and DNS software to the new storage and deployed
   • Synced the databases and deployed the newest file sets through the third-party service

   Action items

   • Phase out the BinaryPack library as a hot-fix
   • Test third-party libraries more extensively
   • Migrate the internal APIs to an independent third-party service
   • Find how to stop non-critical software from becoming a single point of failure across clusters
   • Make the DNS system keep a local copy of all backup data with automatic failure detection

   Lessons

   bunny.net had built its systems to rely on each other, including the critical parts of its internal infrastructure, so one corrupted file brought down several layers of redundancy with no way back. A part of the infrastructure treated as non-critical turned out to be a single point of failure for several clusters at once, which canary deployments did not catch. Building infrastructure inside its own ecosystem lets one failure cascade through all of it. In the rush to fix the outage the team made typos and mistakes, and the final deployment came after it calmed down and double-checked everything.

   View case

By root cause1