사례5건
5건 중 1~5번째
- 증상
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 를 계속 잘못 광고했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
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 경영진에게 에스컬레이션하는 속도가 문제였다. 네트워크 안에 레거시 구성이 남아 있었다. 메일과 문자 공지가 효과적이지 않아 일부 고객이 제때 알맞은 업데이트를 받지 못했다.
- 증상
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 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다.
- 17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.
- 후속 조치
- 버그 자체를 바로잡는다.
- 경로 수가 어긋나면 울리는 알림을 더한다.
- 데이터 플레인의 패킷 drop 수를 보는 알림을 더한다.
- 호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다.
- VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다.
- Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다.
- e2e 테스트를 더 자주 돌린다.
- 중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다.
- 교훈
문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다.
- 증상
09시 39분에 알림이 울렸다. 첫 알림은 eqiad 의 Icinga 가 싱가포르 eqsin 의 공인 text-lb 주소에 닿지 못해서 울렸다.
- 촉발
09시 37분쯤 cr1-eqiad 와 cr2-eqiad 에서 BGP 경로 선택에 영향을 주려고 BGP 설정 하나를 뺐다. 이 설정은 BGP "MED" 속성 값을 BGP 경로의 다음 홉까지 가는 OSPF 비용으로 정했다. 설정을 뺀 것은 T295672 작업의 일부였다.
- 원인
- 구성 요소
- 기여 요인
- 감지
09시 39분에 알림이 울렸다. eqiad 의 Icinga 가 eqsin 같은 엣지 캐시 클러스터를 상태 검사하다가 eqsin 의 공인 text-lb 주소에 닿지 못했다.
- 조치
- 09시 42분 cr1-eqiad 와 cr2-eqiad 두 장비에서 설정 변경을 되돌렸다. 정책이 바뀔 때 경로가 갱신되는 방식 때문에 이것만으로는 바로 풀리지 않았다.
- 09시 51분 eqiad 라우터 사이의 BGP 세션을 강제로 재설정했고, 문제가 풀렸다.
- 후속 조치
- T295672 티켓에 사고 내용을 더 자세히 적고, "second IXP port" 문제를 다루면서 같은 일이 다시 나지 않도록 BGP 세션을 조정하자는 제안을 올렸다.
- 증상
2021-10-13 09:20 CET 에 네트워크 설정을 바꾸던 중 문제가 생겼고, 09:21 CET 에 팀이 라우터 성능 문제를 감지해 곧바로 에스컬레이션했다. IPv6 트래픽은 계속 정상으로 오갔다.
- 촉발
늘어나는 DDoS 공격에 맞서 방어 설정을 강화하려고 미국 Vint Hill 데이터 센터의 라우터에 계획된 변경을 하던 중이었다. 이때 라우터가 BGP 경로를 OSPF 로 재분배하는 설정을 조절하려던 명령을 제대로 해석하지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
변경 작업 중이던 09:21 CET 에 팀이 라우터 성능 문제를 감지하고 곧바로 에스컬레이션 절차를 시작했다.
- 조치
- 연결을 격리해 서비스를 최대한 빨리 되살리려고, 10:02 CET 에 데이터 센터 기술자에게 광 장비 연결을 먼저 끊어 달라고 요청했다.
- 10:10 CET 에 고장 라우터의 전원을 끄기로 했고, 10:18 CET 에 장비를 껐다. 네트워크가 수렴하는 데 2분이 걸렸고 10:20 CET 에 첫 서비스가 돌아왔다.
- 10:30 CET 부터 남은 서비스를 모두 되살리려고 연결 안정화 작업을 시작했다. 10:57 CET 에 기술적으로 위기가 끝났다.
- 후속 조치
- 명령줄을 그대로 적용하는 이 종류의 장비에서 변경 절차를 다시 평가한다.
- 평가 결과에 맞춰 관련 변경 절차를 강화한다.
IL-0222유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.Google Cloud2019- 증상
2019-06-02 US/Pacific 11:47~11:49 부터 미국 여러 리전의 Google Cloud 프로젝트에서 패킷 손실이 늘고, 지연이 커지고, 간헐적 오류와 인스턴스 연결 끊김이 나타났다. us-west1 과 유럽, 아시아 리전에는 리전 네트워크 혼잡이 없었다. Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았다.
- 촉발
US/Pacific 11:45 에 비교적 드문 유형의 데이터 센터 유지보수 이벤트가 물리 위치 한 곳에서 시작됐다. 자동화 소프트웨어가 내릴 작업 목록에 네트워크 제어 작업을 돌리는 논리 클러스터를 넣었다. 이 클러스터에는 다른 물리 위치의 네트워크 제어 작업도 들어 있어, 여러 위치의 네트워크 제어 평면과 지원 인프라가 한꺼번에 내려갔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았고, 가장 심각한 운영 사고에 쓰는 사고 관리 절차를 곧바로 시작했다. 고객용 상태 페이지에는 US/Pacific 12:53 에 첫 공지가 올라왔다.
- 조치
- 혼잡을 줄이려고 덜 중요한 네트워크 트래픽 등급의 우선순위를 낮췄다.
- US/Pacific 13:01 에 근본 원인을 찾고, 유지보수 이벤트를 일으킨 자동화 소프트웨어를 멈췄다.
- 네트워크 제어 평면과 지원 인프라를 위치마다 다시 스케줄해 켰다.
- 제어 평면 인스턴스가 모두 내려가면서 사라진 설정 데이터를 여러 위치에 다시 만들어 배포했다. 새 설정은 14:03 부터 나가기 시작했다.
- Google 안의 여러 팀이 서비스별 완화 조치로 트래픽을 피해 리전 밖으로 돌려 다른 곳에서 계속 서비스했다.
- us-west2, northamerica-northeast1, southamerica-east1 에서 장애 때문에 fail-safe 상태에 들어간 VPN 제어 평면을 손으로 빼냈다. 이 리전의 VPN 게이트웨이는 16:30 에 회복됐다.
- 후속 조치
- 유지보수 때 작업을 내리는 데이터 센터 자동화 소프트웨어를 즉시 멈췄고, 여러 물리 위치에서 동시에 작업을 내리지 않게 하는 안전장치를 갖춘 뒤에만 다시 켠다.
- 클러스터 관리 소프트웨어가 요청의 출처와 상관없이 여러 물리 위치의 작업을 한꺼번에 내리는 요청을 거부하도록 강화한다.
- 네트워크 제어 평면 소프트웨어와 지원 인프라가 이번 사고에 얽힌 유형의 유지보수 요청을 거부하도록 다시 설정한다.
- 위치마다 네트워크 제어 평면이 설정을 영구 저장하게 바꿔, 모든 작업이 내려가도 설정을 다시 만들고 배포할 필요가 없게 한다. 이렇게 하면 복구 시간이 열 배쯤 줄어든다.
- 제어 평면을 잃었을 때 네트워크가 fail static 모드로 더 오래 버티게 해, 사용자 영향 없이 복구할 시간을 충분히 둔다.
- 고객 소통 도구를 포함한 비상 대응 도구와 절차를 검토하고 고치고 시험해, 이번과 같은 네트워크 장애에도 견디게 한다.
- 상시 재해 복구 시험의 범위를 넓혀 이번 장애와 이와 비슷한 수준의 큰 장애를 넣는다.
이 5건에서 가장 많이 나오는 구성 요소: BGP 라우팅, 백본망. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.