사례16건

16건 중 1~5번째

1. IL-0400 웨일스 공공 부문 광역 네트워크 PSBA 에서 웨일스 전역의 기관 사이트가 연결과 인터넷 접속을 잃었고, 관리 링크도 계속 끊겼다 붙었다

   PSBA2026

   증상

   2026년 3월 25일 16:57 부터 웨일스 곳곳의 기관이 사이트 연결이 끊겼다고 서비스 데스크에 전화했다. 16:58 에 모니터링 시스템에 경보가 400개 넘게 떠 Major Incident 가 선언됐다. 경보는 17:05 에 약 1,500개, 17:08 에 웨일스 전역에서 약 5,000개로 늘었다.

   네트워크 도달 불가간헐적 연결 실패링크 플래핑

   촉발

   2026년 3월 25일 16:30 에 Capita 가 운영하던 레거시 UPS 장비를 BT/PSBA 관리로 옮기려고 PSBA 코어 Provider Edge 라우터의 route map 을 바꾸는 구성 변경을 적용했다. 이 변경은 정식 변경 관리를 거치지 않았다. 변경은 16:40 에 되돌렸지만 그 라우터가 default route 를 계속 잘못 광고했다.

   원인

   설정 변경

   구성 요소

   BGP 라우팅

   기여 요인

   롤백 무효리뷰 누락디버그 접근 제한장애 중첩

   감지

   16:57 에 Mid Wales Fire & Rescue Service 가 Presteigne 사이트의 연결이 끊겼다고 전화했다. 16:58 에 모니터링 시스템이 묶어 보낸 경보로 Service Now 에 CS0287201 건이 열렸다. 그때 경보는 400개가 넘어 Major Incident 가 선언됐다.

   조치

   • 16:40 에 네트워크 변경을 되돌렸다.
   • 22:00 에 Technical Design Architect 가 BGP 의 QoS 를 바꿔 관리 접속을 되살렸고, 경보가 줄기 시작했다.
   • 경로를 지우고 inbound BGP 광고를 리셋했지만, default route 는 계속 잘못 광고됐다.
   • 01:02 에 인터넷에서 학습한 경로에 영향을 주던 구성 문제를 찾아 고쳤다.
   • 영향을 받은 라우터를 통제된 방식으로 다시 올렸고, 고객 서비스와 PSBA 관리 연결이 정상으로 돌아왔다.

   후속 조치

   • 내부 브리핑으로 변경 관리 요구 사항을 다시 강조한다. 브리핑에서는 정식 변경 제출과 승인의 중요성, 계획에 없던 변경이 서비스 안정성과 고객에게 주는 위험, 계획 변경과 긴급 변경 때의 역할과 책임을 다룬다.
   • 진행 중인 모든 Major Incident 에 쓰는 P1 / Major Incident 전용 Microsoft Teams 채널을 만든다. 이 채널을 서비스 데스크, 2nd·3rd line 팀, Incident Manager, 관련 이해관계자가 실시간으로 소통하는 단일 창구로 쓴다.
   • 재해 복구와 업무 연속성 시험 훈련을 도입하는 것을 검토한다. 이 훈련으로 조직이 큰 장애와 P1 장애에 더 잘 대비하게 한다. 또 지금의 절차를 확인하고, 빈틈을 찾고, 장애 대응을 더 일관되게 한다.
   • 관리 접속을 잃은 동안에는 참여한 모든 기술 팀이 신고한 기관이 준 정보로 고객 영향을 판단한다. 서비스 데스크와 장애 관리 담당은 고객이 알린 영향받은 사이트, 증상, 시각을 기록하고 확인해 모든 해결 담당 그룹에 실시간으로 나눈다. 도구나 관리 접속을 쓸 수 없을 때는 고객이 알린 영향을 근거로 문제를 풀고 판단한다.
   • Capital Quarter 와 Newport 의 Vantage Data Centre 안 관리 랙 사이에 고정 링크를 까는 것을 검토한다. 전용 관리 단말과 이중 인증을 두어 secure management platform 인 SSP 밖에서도 네트워크에 접근해 상태를 확인할 수 있게 한다. 보안 설계와 승인이 갖춰지면 원격 작업자도 이 단말을 쓰게 할 수 있다.
   • 장애를 접수할 때 묻는 질문을 강화해 첫 분류를 개선한다. 장애 내내 영향을 계속 다시 판단하고 알리도록 강조해, 근본 원인 분석을 더 정확하고 빠르게 한다.
   • P1 / Major Incident 절차를 검토해 에스컬레이션 기준과 시간을 분명히 정한다. 서비스 데스크 교육으로 P1 / Major Incident 상황을 일찍 알아보고 정한 절차대로 바로 에스컬레이션하게 한다.
   • PSBA 네트워크 전체를 검토해 레거시 구성을 찾아 평가한다. 레거시 구성을 지우는 절차와 기한을 정하고, 앞으로 레거시 구성이 들어오거나 남아 있지 않도록 막는 통제를 둔다.
   • 메일과 문자 공지의 배포 목록과 절차를 검토해 정확하고 빠짐없게 한다. 서비스 데스크 교육을 강화해 P1 과 Major Incident 때 고객 공지가 일관되고 분명하며 제때 알맞은 대상에게 가게 한다.

   교훈

   보고서가 밝힌 교훈은 여덟 가지였다. PSBA 가 합의한 변경 관리 절차 밖에서 계획에 없던 변경을 했다. P1 / Major Incident 동안 내부 소통이 효과적이지 않아 업데이트가 늦고 흩어졌다. 네트워크 전체에 걸친 큰 장애에 대응할 준비가 부족했다. 관리 접속을 잃어 해결 담당 그룹이 문제를 끝까지 찾지 못했고 네트워크 상태와 고객 영향을 보기 어려웠다. 고객 영향을 자세히 몰라 해결 담당 그룹이 충분한 정보를 받지 못했고, 그래서 문제 해결의 효과가 떨어지고 근본 원인을 찾는 일이 늦어졌다. PSBA 경영진에게 에스컬레이션하는 속도가 문제였다. 네트워크 안에 레거시 구성이 남아 있었다. 메일과 문자 공지가 효과적이지 않아 일부 고객이 제때 알맞은 업데이트를 받지 못했다.

   사례 보기
2. IL-0350 TXL 클러스터 한 곳의 호스트 네트워크가 끊기고 프로비저닝 대기열이 밀려 여러 서비스가 오래 나빠졌다

   IONOS Cloud2026

   증상

   2026-03-03 11:36 UTC 에 상태 페이지가 TXL 의 모니터링 알림을 조사하고 있다고 알렸다. 정비 중이던 클러스터 한 곳의 호스트가 연결을 잃었고, 고객은 간헐적인 네트워크 서비스 저하나 중단을 겪었다.

   네트워크 도달 불가링크 플래핑서비스 중단

   촉발

   TXL 데이터 센터 클러스터의 고장 난 스위치를 바꾸는 정비로 두 토폴로지 가운데 Topology 2 를 계획대로 껐다. 그동안 남은 Topology 1 에서 스위치 하나의 링크 흔들림이 패브릭 resweep 을 일으켰다.

   원인

   용량 한계

   구성 요소

   InfiniBand 패브릭네트워크 컨트롤 플레인BGP 라우팅NIC·케이블·스위치 포트 링크모델 허브데이터베이스

   기여 요인

   자동화 증폭과도한 영향 범위

   감지

   IONOS Cloud 는 TXL 에서 울린 모니터링 알림으로 장애를 알아챘고, 11:36 UTC 에 상태 페이지에 이 알림을 조사하고 있다고 올렸다.

   조치

   • 문제가 난 컨트롤 플레인을 대기 장비로 전환했다.
   • 멈춘 게이트웨이를 재부팅했다.
   • 예정된 정비 상태에서 Topology 1 을 복구했다.
   • 작업이 밀린 클러스터의 프로비저닝을 잠시 멈췄다. 실행 중인 서비스는 영향이 없었지만 기존 자원의 변경은 다시 켤 때까지 처리되지 않았다.
   • 네트워크 연결이 나아지자 프로비저닝을 다시 켜고 작업 실행을 지켜봤다.
   • DCD 를 받치는 시스템들의 연결을 다시 세워 DCD 서비스를 되살렸다.

   후속 조치

   • 컨트롤 플레인 구성에서 failover 타이머를 덜 민감하게 바꾸고 무거운 sweep 작업을 줄여 전달 테이블의 부하를 낮췄다.
   • 멀티캐스트 그룹 가입 수를 줄여 전달 테이블의 부담을 더 덜었다.
   • 전달 테이블 사용률과 컨트롤 플레인 메모리를 계속 감시해 용량 한도에 닿기 전에 알림이 오게 했다.
   • 네트워크 관리와 데이터 플레인 트래픽이 자원을 다투지 않도록 컨트롤 플레인을 전용 고성능 서버로 옮긴다. 2025년 4분기에 시작했고 2026년 2분기 완료가 목표다.
   • IPv6 구성과 IPoIB 드라이버 설정을 깊이 감사한다. 2026년 2분기 완료가 목표다.
   • 스위치, 게이트웨이, 드라이버를 포함한 인터커넥트 패브릭을 현대화해 복원력과 성능을 높인다. 2026년 3분기 완료가 목표다.
   • 주요 Cloud API 를 잠시 쓸 수 없어도 핵심 신원 서비스가 동작하도록 IAM 정비 절차를 강화했다.
   • IAM 을 전용 플랫폼으로 옮기는 작업을 앞당겨 IAM 이 일반 Managed Kubernetes 클러스터에 기대지 않게 한다. 목표 시점은 2026년 3분기다.
   • DBaaS 와 Managed Kubernetes 에 전용 프로비저닝 공급자를 두어 자가 치유 같은 변경 중에 서비스가 끊기는 일을 줄인다. 목표 시점은 2026년 3분기다.
   • 자가 치유 서비스 때문에 과부하가 나거나 대기열이 끝없이 쌓이지 않도록 프로비저닝 엔진에 자동 서킷 브레이커를 넣는다. 목표 시점은 2026년 1분기다.
   • 프로비저닝 대기열에서 작업 실행과 우선순위를 더 잘 보고 다룰 수 있도록 QoS 를 개선한다.
   • 서비스 사이의 파급을 줄이도록 프로비저닝 대기열의 결합을 푸는 구조 변경을 한다.

   교훈

   IONOS Cloud 는 서비스들이 프로비저닝 대기열로 서로 얽혀 있던 점이 서비스 저하를 길게 만든 핵심 요인이었다고 봤다. 앞으로는 서비스마다 견고하게 만드는 것과 함께 프로비저닝 대기열의 결합을 풀어 이번과 같은 파급을 줄이겠다고 했다. 서비스 사이의 의존도 찾아 풀어서 앞으로의 장애가 미치는 범위를 줄이겠다고 했다.

   사례 보기
3. IL-0563 Linode 의 모든 리전에서 서버에 연결할 수 없게 됐고 Amsterdam 데이터센터는 거의 전부 멈췄다

   Linode2025

   증상

   2025년 3월 17일 16:38 UTC 쯤 여러 데이터센터에서 서버들에 오랫동안 연결할 수 없다는 내부 알림이 한꺼번에 울렸다. 같은 때 고객들도 여러 제품에서 문제를 신고하기 시작했다.

   네트워크 도달 불가서비스 중단

   촉발

   Akamai Compute 의 내부 백엔드 API 구성 요소를 릴리스하는 중이었다. 롤아웃이 이어지는 동안 이 API 의 응답이 서로 일치하지 않았다.

   원인

   배포 결함

   구성 요소

   BGP 라우팅네트워크 컨트롤 플레인

   기여 요인

   부분 배포

   감지

   16:38 UTC 쯤 여러 데이터센터에서 서버들에 오랫동안 연결할 수 없다는 내부 알림이 대거 울렸다. 같은 때 고객들도 여러 제품의 문제를 신고하기 시작했다.

   조치

   • 18:30 UTC 쯤부터 모든 데이터센터의 라우트 서버를 영향이 가장 큰 리전부터 단계적으로 재시작했고, 21:34 UTC 쯤 마쳤다.

   후속 조치

   • 라우트 서버가 받는 경로 데이터가 끊김 없이 이어지게 할 더 나은 방법을 마련할 때까지 백엔드 API 릴리스를 멈춘다.

   사례 보기
4. IL-0233 eu-west1 에서 Managed Kubernetes 의 거의 모든 파드가 네트워크 연결을 잃었고 롤백으로도 돌아오지 않았다

   Nebius2025

   증상

   2025-03-13 eu-west1 리전에서 Managed Services for Kubernetes 고객의 파드가 거의 모두 13:36 에서 18:11 UTC 사이에 적어도 한동안 네트워크 연결을 잃었다. Nebius 팀은 15:13 UTC 에 문제를 알아챘다. eu-north1 리전은 영향을 받지 않았다.

   네트워크 도달 불가

   촉발

   eu-west1 에 배포한 VPC 컨트롤 플레인 구성 요소의 릴리스가 새 기능에 필요한 route distinguisher 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인BGP 라우팅

   기여 요인

   롤백 무효자동 테스트 공백모니터링 사각지대

   조치

   • 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다.
   • 17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.

   후속 조치

   • 버그 자체를 바로잡는다.
   • 경로 수가 어긋나면 울리는 알림을 더한다.
   • 데이터 플레인의 패킷 drop 수를 보는 알림을 더한다.
   • 호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다.
   • VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다.
   • Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다.
   • e2e 테스트를 더 자주 돌린다.
   • 중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다.

   교훈

   문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다.

   사례 보기
5. IL-0347 FR-PAR-1 가용 영역에서 하이퍼바이저 약 25% 의 VPC 연결이 11분 동안 끊겼다

   Scaleway2024

   증상

   FR-PAR-1 가용 영역의 하이퍼바이저 약 25% 가 리전의 나머지와 VPC 로 통신하지 못했다. 7:50 부터 8:01 UTC 까지 Managed Database, Redis, Serverless, Kubernetes Kapsule 처럼 VPC 에 기대는 제품이 함께 영향을 받았다.

   네트워크 도달 불가패킷 손실노드 NotReady

   촉발

   6:20 UTC 에 랙 하나의 ToR 스위치 소프트웨어가 충돌했다. 이 불안정이 같은 랙의 하이퍼바이저에서 돌던 VPC 용 BGP 경로 반사기를 비정상 상태에 빠뜨렸다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인BGP 라우팅네트워크 스위치데이터베이스관리형 쿠버네티스 컨트롤 플레인과 제공자 API

   기여 요인

   과도한 영향 범위자동화 증폭

   감지

   Scaleway 의 Customer Excellence 팀과 SRE 팀이 영향을 알아채고 사고를 열었다. RR 의 헬스 체크 모니터링도 이상을 잡았지만 자동 재시작은 실패했다.

   조치

   • 멈춘 VPC 경로 반사기 두 대를 손으로 고쳤다.

   후속 조치

   • 멈춘 상태의 경로 반사기를 고치지 못한 자동 복구 장치를 고쳤다. 수정 내용은 https://github.com/FRRouting/frr/pull/17163 이다.
   • 버그 하나가 여러 경로 반사기를 한꺼번에 멈추지 않도록 경로 반사기의 소프트웨어 버전을 서로 다르게 둔다.
   • 경로 반사기를 멈춘 상태에 빠뜨린 소프트웨어 문제를 깊이 조사한다.

   사례 보기

원인별6