{"id":"IL-0424","org":"Nebius","date":"2024-11-26","docs":[],"title":{"en":"A Nebius Compute API release wrongly saw VMs as missing and restarted 282 VMs in eu-north1, leaving 164 stuck for hours","ko":"eu-north1 리전의 VM 282대가 한꺼번에 재시작했고 그중 164대가 2~3시간 동안 켜지지 않았다"},"domain":["ai-infra"],"impact":{"scope":"282 VMs in eu-north1 restarted, 196 got stuck, and 164 stayed offline for about 2 to 3 hours, interrupting customer workloads","users":"unknown","region":"eu-north1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"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.","ko":"단계별로 나눠 복구한 방식은 효과가 있었지만 사람이 직접 손대고 면밀히 지켜봐야 했다. Nebius 는 복구 절차를 더 자동화해야 비슷한 상황에서 대응 시간을 크게 줄일 수 있다고 정리했다."},"related":[],"sources":[{"url":"https://nebius.com/blog/posts/incident-post-mortem-analysis-partial-unavailability-on-november-26-2024","kind":"blog","archived":"https://web.archive.org/web/20260822200034/https://nebius.com/blog/posts/incident-post-mortem-analysis-partial-unavailability-on-november-26-2024"}],"summary":{"en":"The new release contained a flawed assumption about the order in which events are processed by the system that tracks resource updates. With it, the Nebius Compute API wrongly concluded that some VMs were not running, marked them as missing and started recovery operations that restarted 282 VMs. The systems were not yet optimised for that many recovery operations at once, so many VMs got stuck. After the alert at 14:03, the team declared an incident within 15 minutes, identified the root cause at 15:00, halted all automatic recovery operations, separated the VMs that had restarted from those that were stuck, and tested a procedure on individual VMs: stop the VM to interrupt all stuck processes, then start it again in controlled batches. 163 VMs were recovered in batches between 15:37 and 16:39, and at 17:40 every affected VM was verified as started. Nebius plans more testing of recovery scenarios and stricter validation of VM state changes before deployment, rate limiting for recovery processes, better monitoring and anomaly detection of VM activity, extra safety checks in deployments, and faster escalation and better customer notification for large VM events.","ko":"UTC+1 기준 13:48 에 새 릴리스를 eu-north1 에 배포하자 Compute API 서비스가 일부 VM 이 동작하지 않는다고 잘못 판단했다. 새 릴리스는 리소스 변경을 추적하는 시스템이 이벤트를 처리하는 순서를 잘못 가정하고 있었다. Compute API 는 일부 VM 이 사라졌다고 보고 필요 없는 복구 작업을 시작했고, VM 282대가 재시작했다. 당시 시스템은 이만큼 많은 복구 작업을 감당하도록 최적화되어 있지 않았다. 그 결과 196대가 재시작하지 못하고 멈췄다.\n\n14:03 에 내부 모니터링 알림이 울려 온콜 엔지니어에게 전화가 갔다. 팀은 15분 안에 인시던트를 선언하고 대응 팀을 꾸렸다. 팀은 자동 복구 작업을 모두 멈추고, 정상적으로 재시작한 VM 과 손으로 살려야 하는 VM 을 나눴다. 15:00 에 근본 원인을 찾은 뒤 개별 VM 에서 복구 절차를 시험했고, 15:37 부터 16:39 까지 VM 163대를 몇 대씩 묶어 차례로 복구했다. 17:40 에 영향받은 VM 이 모두 정상으로 켜진 것을 확인하고 인시던트를 끝냈다."},"trigger":{"en":"Deployment of a new release, with a faulty change in the VM recovery sequence, to eu-north1 at 13:48 (UTC+1).","ko":"UTC+1 기준 13:48 에 VM 복구 순서에 결함이 있는 새 릴리스를 eu-north1 에 배포했다."},"severity":"unknown","symptoms":["vms-restarted","service-unavailable"],"timeline":{"detected_after":"15m","resolved_after":"3h 52m"},"date_kind":"incident","detection":{"en":"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.","ko":"내부 모니터링이 멈춘 VM 을 감지해 14:03 에 알림을 울렸고, 곧바로 온콜 엔지니어에게 전화가 갔다. 같은 때 고객이 Slack 으로 첫 신고를 보냈다. 팀은 15분 안에 영향을 파악하고 인시던트를 공식으로 선언했다."},"components":["cloud-compute-control-plane"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Halted all automatic recovery operations to prevent further impact","ko":"근본 원인을 찾으면서 피해가 더 번지지 않도록 자동 복구 작업을 모두 멈췄다."}},{"text":{"en":"Split the affected VMs into those that had restarted and those stuck and needing manual work","ko":"영향받은 VM 을 재시작에 성공한 VM 과, 멈춰서 손으로 살려야 하는 VM 의 두 그룹으로 나눴다."}},{"text":{"en":"Tested a mitigation procedure on individual VMs before applying it","ko":"15:00 부터 15:37 까지 상황을 더 나쁘게 만들지 않는 복구 계획을 세우고, 그 방법을 개별 VM 에서 먼저 시험했다."}},{"text":{"en":"Stopped the stuck VMs to interrupt their stuck processes and restarted them in controlled batches","ko":"멈춘 VM 을 정지해 걸려 있던 프로세스를 모두 끊은 뒤 몇 대씩 묶어 차례로 다시 시작했다. 15:37 부터 16:39 까지 VM 163대를 이렇게 복구했다."}}],"action_items":[{"text":{"en":"Add testing for recovery scenarios before deployment","ko":"배포 전 검증에 복구 시나리오 테스트를 더한다."}},{"text":{"en":"Enforce stricter validation of VM state changes","ko":"VM 상태 변경을 더 엄격하게 검증한다."}},{"text":{"en":"Rate-limit recovery processes","ko":"복구 작업에 속도 제한을 둔다."}},{"text":{"en":"Improve monitoring and anomaly detection of VM activity","ko":"VM 활동의 모니터링과 이상 탐지를 강화한다."}},{"text":{"en":"Add safety checks to deployment procedures","ko":"배포 절차에 안전 점검을 더한다."}},{"text":{"en":"Escalate large-scale VM events faster","ko":"대규모 VM 이벤트가 나면 더 빨리 에스컬레이션한다."}},{"text":{"en":"Improve customer notifications and engagement, and refine internal communication protocols for incident response","ko":"고객 알림과 고객 소통을 개선하고, 사고 대응이 매끄럽도록 내부 소통 절차를 다듬는다."}}],"contributing":["assumption-unverified","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"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.\n\nAt 14:03 internal monitoring alerted on the large number of stuck VMs and phoned the on-call engineers, and the first customer report arrived over Slack at the same time. While the team worked out a safe way to recover, 32 VMs were restarted or deleted by their users; the remaining 164 stayed offline for about 2 to 3 hours until they were recovered by hand in batches.","ko":"UTC+1 기준 13:48 에 eu-north1 리전의 VM 282대가 한꺼번에 재시작했다. 14:03 에 멈춘 VM 이 많다는 알림이 울렸고, 같은 때 고객이 Slack 으로 첫 신고를 보냈다.\n\n재시작한 282대 가운데 86대는 13:50 에 자동으로 다시 올라왔지만 196대는 재시작에 실패하고 멈춘 상태로 남았다. 사용자가 그중 32대를 직접 재시작하거나 지웠고, 나머지 164대는 켜지지 않은 채 약 2~3시간 동안 오프라인이었다.\n\n팀은 14:21 에 원인을 분석하기 시작했고, 상황을 더 나쁘게 만들지 않으면서 피해를 줄일 방법도 함께 찾았다. 근본 원인은 15:00 에 찾았다."},"updated_at":"2026-11-14T12:34:07.439699Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0424","org_slug":"nebius"}