사례7건

7건 중 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-0487 Postgres 테이블 두 개의 콜레이션을 바꾼 뒤 데이터베이스 CPU가 치솟아 Autumn API 요청의 약 10%가 실패했다

   Autumn2026

   증상

   2026-03-15 15:00 GMT 무렵 운영 데이터베이스의 두 테이블에 콜레이션 변경을 적용하자 데이터베이스 CPU가 치솟고 질의가 실패하기 시작했다. 16:15 GMT까지 Autumn API 요청의 약 10%가 실패했다.

   데이터베이스 과부하오류율 상승잠금 경합과 교착

   촉발

   가장 자주 도는 질의를 최적화하던 중 관련 테이블 네 개의 콜레이션을 맞추기로 하고, 운영 데이터베이스에서 customer_entitlements와 customer_products의 콜레이션을 바꿨다.

   원인

   설정 변경

   구성 요소

   데이터베이스

   기여 요인

   롤백 무효

   조치

   • 15:48에 PlanetScale 지원팀의 도움을 받아 모든 애플리케이션 연결을 끊었다.
   • 콜레이션 변경을 되돌렸다.
   • ANALYZE로 플래너 통계를 다시 만든 뒤 재시작했다. 질의가 바로 정상으로 돌아왔고 CPU도 안정됐다.

   후속 조치

   • 앞으로 열과 스키마 마이그레이션은 모두 복제, 이중 쓰기, 전환 순서로 한다. 열을 제자리에서 바꾸지 않고 원하는 타입의 새 열을 만들어 두 열에 함께 쓰고, 기존 행을 작은 묶음으로 채우고, 인덱스를 동시 생성한 뒤 전환한다.
   • 문제가 생겼을 때 상황을 투명하게 알리려고 상태 페이지를 만든다.
   • 장애가 나도 유료 고객이 영향을 받지 않도록 check와 track SDK가 기본으로 fail-open 하게 바꾸는 방안을 검토한다.

   사례 보기
3. IL-0528 Cloud Pub/Sub 가 여러 리전에서 게시와 구독을 모두 못 했고 순서 지정 구독 일부는 그날 밤까지 메시지를 받지 못했다

   Google Cloud2025

   증상

   여러 리전에서 Cloud Pub/Sub 에 메시지를 게시할 수도, 구독할 수도 없었다. 백로그 지표는 오래된 값이거나 아예 비어 있을 수 있었다. 상태 페이지의 제목은 "Multiple regions completely blocked for subscribe for Pubsub" 였다.

   서비스 중단모니터링 중단

   촉발

   미국 태평양 시간 06:54 부터 07:30 사이에 잘못된 서비스 설정 변경이 여러 리전에 배포됐다. 이 변경은 리전 메타데이터 데이터베이스에 접근하는 권한을 의도치 않게 지나치게 좁혔다.

   원인

   설정 변경

   구성 요소

   메시지 브로커데이터베이스

   기여 요인

   스테이징 불일치단계적 배포 부재롤백 무효

   감지

   엔지니어들은 영향이 시작되고 9분 뒤인 미국 태평양 시간 07:03 에 내부 텔레메트리로 장애 알림을 받았다. 순서 지정 구독 일부가 백로그를 소비하지 못하는 문제는 09:07 에 역시 내부 텔레메트리 알림으로 알았다.

   조치

   • 문제를 일으킨 설정 변경을 찾아 미국 태평양 시간 08:07 에 롤백을 마쳤다.
   • 영향을 받은 순서 지정 구독을 모두 찾아 고쳤고, 이 작업을 미국 태평양 시간 23:09 에 마쳤다.

   후속 조치

   • 설정 변경의 영향을 운영 환경에 닿기 전에 잡을 수 있도록 사전 운영 환경과 운영 환경의 설정을 같게 맞추는 규칙을 더 강하게 적용한다. 목표일은 2025년 1월 31일이다.
   • 변경 관리 절차를 검토해 앞으로 설정 변경이 우선순위에 맞춰 단계적으로 배포되게 한다. 목표일은 2025년 1월 31일이다.
   • 순서 메타데이터의 불일치를 미리 잡아내는 모니터링을 더한다. 목표일은 2025년 3월 31일이다.
   • 순서 지정 메시지가 전달되지 않게 만든 Cloud Pub/Sub 의 순서 메타데이터 관리 버그를 고친다. 목표일은 2025년 6월 30일이다.

   사례 보기
4. IL-0285 Clever Cloud 의 Apache Pulsar 메시징 클러스터가 멈추면서 EU-FR-1 리전의 배포 API 가 먹통이 되고 하이퍼바이저들이 커널 패닉으로 재부팅됐다

   Clever Cloud2024

   증상

   10:08 CEST 에 모니터링에 메시징 플랫폼 연결 문제가 보였고, 10:09 에 엔지니어가 이벤트 버스에 데이터를 넣지 못하는 것을 확인했다. 하이퍼바이저의 에이전트, 로드 밸런서의 로그 전달기, 배포가 영향을 받기 시작했다.

   배포 실패노드 CPU 고부하메모리 압박노드 커널 패닉OOMKilled오토스케일러 오동작모니터링 중단

   촉발

   10:06 CEST 에 데이터 팀이 Apache Pulsar 를 3.3.1 로 올리는 작은 롤링 업그레이드를 시작하면서, 번들 배치를 최적화하는 새 로드 밸런서 TransferShedder 와 extensible unload 전략도 함께 켰다. 첫 브로커가 업그레이드될 때 새 로드 매니저 확장 기능이 제대로 초기화되지 않았고, 브로커들은 부하 메타데이터를 맞추는 시스템 토픽을 만들지 못했다.

   원인

   설정 변경

   구성 요소

   메시지 브로커텔레메트리 에이전트리눅스 커널자동 용량 관리 시스템

   기여 요인

   설정 테스트 부재모니터링 사각지대롤백 무효기본 설정 방치자동화 증폭재시도 폭주순환 의존

   감지

   10:08 CEST 에 모니터링이 메시징 플랫폼 연결 문제를 보여 줬고, 10:09 에 엔지니어가 이벤트 버스에 데이터를 넣지 못하는 것을 확인했다. 시스템 토픽이 만들어지지 않은 첫 브로커는 죽지 않아 모니터링에 정상으로 보였고, 엔지니어들은 플랫폼 대역폭이 떨어지는 것을 보고 어떤 토픽도 로드되지 않았다는 것을 알았다.

   조치

   • 엔지니어들이 플랫폼 대역폭이 떨어지고 어떤 토픽도 로드되지 않았다는 것을 알고 unload 방식 변경을 되돌렸다. Pulsar 3.3.1 릴리스는 그대로 유지했다.
   • 11:36 CEST 에 메타데이터 충돌로 브로커가 다시 시작하지 못하자 엔지니어링 팀이 클라이언트 프록시를 내려 브로커에 걸린 부담을 덜었다.
   • 11:50 CEST 에 배포 담당 팀이 메시징 문제를 피하려고 알림 이벤트를 RabbitMQ 로 보내도록 바꿨다.
   • 모든 브로커를 멈추고 하나만 띄워 브로커 사이의 메타데이터 충돌을 막았다. 그 브로커가 배정되지 않은 시스템 토픽을 로드하자 토픽을 지웠고, 모든 브로커가 다시 시작해 10분이 안 되어 평소 상태로 돌아왔다.
   • 12:54 CEST 에 메시징 프록시를 재시작했다. 연결이 돌아오고 메시지 생산과 소비가 정상이 됐다.
   • 12:39 CEST 에 watchdog 이 실패한 구성 요소를 한꺼번에 다시 띄우지 못하게 멈추고, 상황을 파악하며 구성 요소를 하나씩 시작했다.
   • 12:50 CEST 에 저장소 클러스터를 지키려고 Metrics API 수집을 껐다. 버퍼링 덕분에 수집은 계속 받을 수 있었다.
   • 자원을 확보하려고 관측 지표의 장기 저장소인 Warp10/FoundationDB 클러스터를 비롯한 덜 중요한 서비스를 멈췄다. 핵심 서비스는 메모리 안의 Warp10 단독 인스턴스로 관측을 이어 갔다.
   • 13:35 CEST 에 모든 리전의 모니터링 인스턴스를 전역 유지보수 상태로 돌려 업스케일, 다운스케일, 도달 불가, 디스크 같은 모니터링 작업을 오케스트레이터로 보내지 않게 했다.
   • 과부하를 일으키는 VM 을 모아 정렬해 보니 메모리가 작은 VM 이었고, SRE 팀이 이 VM 을 하나씩 죽여 하이퍼바이저를 다시 통제했다.
   • 13:50 CEST 에 하이퍼바이저 12대에 작업 일부를 빼내라는 표시를 했고, 아직 자원이 필요한 다른 인스턴스를 위해 일부 로드 밸런서를 내려 CPU 와 메모리를 확보했다.
   • 14:08 CEST 에 복구를 앞당기려고 좀비 VM 일부를 정리했다.
   • 15:45 CEST 에 모니터링 인스턴스의 알림 큐를 비워 아직 쌓여 있던 모니터링 이벤트가 오케스트레이터 명령 사이로 쏟아져 들어가지 않게 했다.
   • 16:05 CEST 에 업그레이드를 위해 비워 두고 세워 둔 EU-FR-1 리전의 새 하이퍼바이저를 투입해 과부하된 하이퍼바이저를 도울 용량을 더했다.
   • 16:15 CEST 에 과부하된 하이퍼바이저 위에서 함께 과부하되어 오케스트레이션을 방해하던 RabbitMQ 노드를 클러스터에서 뺐다. 그 뒤 오케스트레이터가 제대로 돌았다.
   • 17:06 CEST 까지 모든 리전 L7LB 를, 17:30 까지 모든 L4LB 와 전용 L7LB 를 차례로 재시작했다.
   • 18:40 CEST 에 하이퍼바이저 에이전트와 컨트롤 플레인 사이의 통신 오류를 의심해 인프라의 모든 HV 에이전트를 재시작했다. 컨트롤 플레인 이벤트 버스와 통신하지 못하는 것으로 보이는 애드온 공급자 API 도 재시작했다.
   • 18:53 CEST 에 stopping 상태로 남은 VM 을 모두 없앴고 애플리케이션 배포가 이어졌다.
   • 20:51 CEST 에 Metrics API 수집을 부하를 단계적으로 올리는 QoS 정책과 함께 다시 켰다. 22:53 에 이 정책을 끄고 클러스터가 완전히 정상으로 돌아왔다.

   후속 조치

   • Pulsar 브로커와 클러스터 상태, 하이퍼바이저 부하와 I/O, 커널 패닉으로 인한 하이퍼바이저 재부팅, 좀비 VM, RabbitMQ 브로커와 클러스터 상태, 배포 큐 소비를 지표로 잡는다. 각 지표를 사건 시각, 감지 시각, 결정 시각, 해결 시각으로 따져 운영이 잘 돌아간 곳과 가시성이나 대응이 모자란 곳을 가려낸다.
   • 너무 많은 모니터링 알림을 다루는 방법을 정한다.
   • 리전 bastion 하나가 취약하므로 백업 bastion 을 검토한다.
   • 컨트롤 플레인 복구 절차를 다시 세운다.
   • 모니터링과 오케스트레이션의 연관 관계를 다시 따진다.
   • 장애 도메인 분리와 멀티 테넌시의 관계를 다시 검토한다.
   • 런타임 이미지와 하이퍼바이저의 역할을 다시 생각한다.
   • Pulsar 처럼 여러 차례에 나눠 내보내는 릴리스 업그레이드를 격리한다.
   • 런타임 이미지를 다시 설계하고 하이퍼바이저와 더 잘 통합한다.
   • 관측 서비스를 리전별로 나눠 이중화한다.
   • 작은 VM 의 Vector 설정에서 buffer.max_events 와 buffer.max_size 를 정한다. type=disk 이면 buffer.max_size 는 적어도 256Mo 여야 한다.
   • Vector 의 buffer.type 을 기본값 memory 에서 disk 로 바꾼다.
   • Vector 의 buffer.when_full 을 기본값 block 에서 drop_newest 로 바꾼다.
   • Journald 의 로그 상세 수준과 SystemMaxUse 를 조정한다.
   • Cgroups 제한을 걸어 프로세스를 더 잘 통제한다.
   • VM 관리자에 I/O 제한을 건다.
   • 좀비 VM 을 더 잘 찾아낸다.

   교훈

   작은 릴리스나 작아 보이는 설정 변경은 큰 릴리스에 쓰는 시뮬레이션 절차를 거치지 않았고, 이번 장애는 그 변경에서 시작됐다. 브로커가 살아 있으면 정상으로 보는 모니터링은 확장 기능의 초기화 실패를 잡지 못했다. Clever Cloud 가 자기 플랫폼 위에서 도는 구조는 평소 이점이 많지만, 이번에는 복구에 필요한 스케줄러와 컨트롤 플레인이 같은 장애에 묶였다. 모니터링이 도달 불가와 CPU 증가에 반응해 배포를 크게 늘렸고, 이 배포가 과부하된 컨트롤 플레인과 인프라를 더 눌렀다. Clever Cloud 는 Pulsar 와 RabbitMQ 의 브로커 상태와 클러스터 상태, 하이퍼바이저 부하와 I/O, 커널 패닉 재부팅, 좀비 VM, 배포 큐 소비를 지표로 삼아 사건 시각, 감지 시각, 결정 시각, 해결 시각으로 따졌다. Clever Cloud 는 이 방식으로 기존 규칙을 다시 따져 볼 수 있었고, 인프라 일부를 고치거나 다시 설계할 수 있다는 것을 알게 됐다고 밝혔다. 여름 휴가철이었지만 Clever Cloud 는 13:00 CEST 에 이미 휴가 중인 사람들까지 불러 대응 인력을 빠르게 늘렸다.

   사례 보기
5. IL-0266 eqiad 코어 라우터 두 대 사이에 라우팅 루프가 생겨 eqiad 가 다른 데이터센터의 공인 IP 주소에 닿지 못했다

   Wikimedia Foundation2021

   증상

   09시 39분에 알림이 울렸다. 첫 알림은 eqiad 의 Icinga 가 싱가포르 eqsin 의 공인 text-lb 주소에 닿지 못해서 울렸다.

   네트워크 도달 불가

   촉발

   09시 37분쯤 cr1-eqiad 와 cr2-eqiad 에서 BGP 경로 선택에 영향을 주려고 BGP 설정 하나를 뺐다. 이 설정은 BGP "MED" 속성 값을 BGP 경로의 다음 홉까지 가는 OSPF 비용으로 정했다. 설정을 뺀 것은 T295672 작업의 일부였다.

   원인

   설정 변경

   구성 요소

   BGP 라우팅

   기여 요인

   롤백 무효

   감지

   09시 39분에 알림이 울렸다. eqiad 의 Icinga 가 eqsin 같은 엣지 캐시 클러스터를 상태 검사하다가 eqsin 의 공인 text-lb 주소에 닿지 못했다.

   조치

   • 09시 42분 cr1-eqiad 와 cr2-eqiad 두 장비에서 설정 변경을 되돌렸다. 정책이 바뀔 때 경로가 갱신되는 방식 때문에 이것만으로는 바로 풀리지 않았다.
   • 09시 51분 eqiad 라우터 사이의 BGP 세션을 강제로 재설정했고, 문제가 풀렸다.

   후속 조치

   • T295672 티켓에 사고 내용을 더 자세히 적고, "second IXP port" 문제를 다루면서 같은 일이 다시 나지 않도록 BGP 세션을 조정하자는 제안을 올렸다.

   사례 보기

원인별1