사례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 경영진에게 에스컬레이션하는 속도가 문제였다. 네트워크 안에 레거시 구성이 남아 있었다. 메일과 문자 공지가 효과적이지 않아 일부 고객이 제때 알맞은 업데이트를 받지 못했다.
- 증상
2024년 1월 10일 06:00 UTC 무렵 모니터링 시스템이 SourceHut 의 PHL 인프라에 이상이 있다고 경보를 울렸다. 09:00 UTC 무렵에는 PHL 망에 아예 닿을 수 없게 됐다.
- 촉발
2024년 1월 10일 06:00 UTC 무렵 SourceHut 의 PHL 인프라를 노린 layer 3 DDoS 가 시작됐다. 상위 망인 Cogent 가 이에 대응해 SourceHut 의 하위 AS 에 null route 를 걸었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
06:00 UTC 무렵 모니터링 시스템이 이상을 알아채 경보를 울렸고, 운영팀은 곧 조사를 시작했다.
- 조치
- 코로케이션 사업자가 Cogent 를 설득해 null route 를 /24 전체에서 DDoS 가 노리던 IP 주소 하나인 /32 로 좁혔다.
- 외부 DNS 로 옮겼다.
- 새 주 데이터베이스를 띄웠다.
- FRE 의 백업을 AMS 로 복원했다.
- 운영 데이터와 마지막 백업 사이의 차이를 손으로 반영했다.
- 새 메일 시스템을 갖추고 메일 서비스를 그 시스템에 맞게 설정했다.
- OVH 서버를 두고 트래픽을 OVH 의 DDoS 방어 망을 거쳐 AMS 의 비공개 운영 서브넷으로 NAT 했다. 이 방식으로 종단 간 암호화를 지키면서 임의의 TCP 프로토콜도 서비스했다.
- 1월 12일 PHL 망 사업자가 임시 서브넷을 내줘 PHL 서버에 대역 외로 접근했고, 이것으로 대체 인프라를 더 빨리 갖췄다.
- PHL 에서 AMS 로 객체 저장소를 옮기는 동안 pages.sr.ht 를 PHL 로 가는 대역 외 링크로 서비스했다. 성능에는 제약이 있었다.
- pages.sr.ht 가 새 서브넷과 IP 주소로 옮겨 가면서, apex 레코드가 PHL 서브넷을 직접 가리키던 사용자에게 손으로 고치는 방법을 메일로 보냈다.
- AMS 의 연산 용량이 모자라 builds.sr.ht 의 빌드 워커를 OVH 의 전용 베어메탈 서버에서 돌렸다.
- 후속 조치
- 새 대기 데이터베이스를 갖춘다. 사고 뒤 작업 가운데 이미 끝난 일이다.
- AMS 에서 FRE 로 백업을 받도록 설정한다. 이미 끝난 일이다.
- 새 모니터링 시스템을 설치한다. 진행 중인 일이다.
- PHL 데이터센터의 설비를 완전히 정리하고, PHL 의 서버를 포장해 AMS 로 보내 용량을 보탠다.
- 몇 주 안에 빌드용 연산 서버를 PHL 에서 AMS 로 옮긴 뒤 빌드 서비스를 SourceHut 이 운영하는 인프라로 되돌린다.
- SourceHut 을 온프레미스 쿠버네티스 클러스터에서 돌리는 방법을 연구해 구현한다. 내부 유지 보수 때 사용자가 겪는 중단을 줄이고 이런 사고에 더 잘 견디려는 것이다.
- 그 작업이 끝나면 두 번째 운영 데이터센터를 계획한다. 두 데이터센터가 함께 부하를 나누고, 한 데이터센터에 장애가 나면 다른 쪽이 전체 서비스를 넘겨받게 한다.
- 교훈
SourceHut 은 데이터센터 전체 장애까지 대비해 둔 운영 계획이 이번 대응에 중요했다고 적었다. 이번 사고는 SourceHut 이 이중화와 복원력 목표를 다 이루기 전에, 알고 고치던 약점을 드러냈다. pages.sr.ht 의 S3 호환 객체 저장소가 오프사이트 백업에 들어 있지 않다는 것도 이번에 알았다. SourceHut 은 이번 일로 비상 절차를 실제로 시험해 볼 수 있었고, 안정성을 더 높일 방법을 많이 배웠다고 적었다. 긴급 이전으로 EU 로 옮기려던 장기 목표 상당수를 빨리 이뤘다.
- 증상
Facebook 데이터 센터 사이의 서버 연결과 데이터 센터와 인터넷 사이의 서버 연결이 한꺼번에 완전히 끊겼다. DNS 서버는 동작하고 있었지만 인터넷에서 닿지 않아 누구도 Facebook 서버를 찾을 수 없었다. 백본이 통째로 빠지자 DNS 서버가 있는 작은 시설들이 스스로 비정상이라고 판단해 BGP 광고를 거둬들였기 때문이다.
- 촉발
일상적인 유지보수 작업 중에 전 세계 백본 용량의 가용성을 평가하려고 내린 명령이 의도치 않게 백본 네트워크의 모든 연결을 끊었다. 이런 명령을 검사해 실수를 막는 감사 도구가 버그 때문에 이 명령을 멈추지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 주 네트워크 접근과 out-of-band 접근이 모두 끊겨, 팀은 엔지니어를 데이터 센터 현장에 보내 문제를 디버깅하고 시스템을 다시 시작하게 했다.
- 보안 접근 절차를 거쳐 현장 인력이 서버를 다룰 수 있게 된 뒤 문제를 확인하고 백본을 다시 온라인으로 올렸다.
- storm 훈련에서 얻은 경험을 살려 서비스를 다시 켜면서 늘어나는 부하를 조심스럽게 관리했다.
- 후속 조치
- 전 세계 백본이 끊기는 상황을 storm 훈련으로 시뮬레이션할 방법을 찾는다.
- 테스트와 훈련, 전반적인 복원력을 강화해 이런 사고가 최대한 드물게 일어나게 한다.
- 교훈
무단 접근을 막으려고 강화한 보안이, 공격이 아니라 스스로 낸 실수에서 비롯된 장애의 복구를 늦췄다. Meta 는 드문 사고에서 복구가 느려지더라도 평소의 보안을 크게 높이는 편이 낫다고 봤다. 서비스, 데이터 센터, 리전 전체를 내리는 storm 훈련이 부하를 다시 올리는 데 도움이 됐지만, 전 세계 백본이 끊기는 상황은 훈련해 본 적이 없었다.
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 모드로 더 오래 버티게 해, 사용자 영향 없이 복구할 시간을 충분히 둔다.
- 고객 소통 도구를 포함한 비상 대응 도구와 절차를 검토하고 고치고 시험해, 이번과 같은 네트워크 장애에도 견디게 한다.
- 상시 재해 복구 시험의 범위를 넓혀 이번 장애와 이와 비슷한 수준의 큰 장애를 넣는다.
- 증상
멜버른 시간 2016년 2월 7일 일요일 오전 4시 50분, UTC 로는 2월 6일 오후 6시 무렵 Level 3 와 NYI 사이의 GRE 터널이 끊겼다. FastMail 로 오는 트래픽이 FastMail 네트워크에 전혀 들어오지 못해 고객은 서비스를 쓸 수 없었다.
- 촉발
멜버른 시간 2016년 2월 7일 오전 4시 50분에 DDoS 방어를 맡은 Level 3 와 주 데이터센터 NYI 사이의 GRE 터널이 끊겼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
데이터센터 업체 NYI 가 장애를 금방 알아챘다.
- 조치
- NYI 가 Level 3 지원 창구에 계속 상급자 대응을 요청해, FastMail 의 공인 IP 대역이 다시 NYI 를 가리키게 했다.
- 후속 조치
- DDoS 방어를 예전 방식으로 되돌려, NYI 가 직접 통제하는 가운데 Black Lotus 가 방어를 맡는다.
- Los Angeles 데이터센터에 보조 네트워크로 NYI 의 애플리케이션·메일 서버와 통신하는 nginx 프런트엔드를 새로 만든다. NYI 의 주 네트워크가 끊기면 DNS 로 www.fastmail.com, mail.messagingengine.com 같은 이름을 LA 프런트엔드로 돌린다.
- Amsterdam 에 하드웨어를 늘리고, 배달 시스템이 NYI 와 덜 통신하도록 내부를 바꾼다.
- NYI 가 네트워크 장애를 감지하고 대응하는 내부 절차를 NYI 와 함께 더 자세히 파악한다.
- 교훈
이렇게 복구가 늦어지는 것은 받아들일 수 없다. FastMail 과 NYI 가 쌓아 온 신뢰성의 큰 부분은 NYI 가 인프라를 직접 통제하는 데서 나왔다. 상시 DDoS 방어로 옮기면서 그 통제를 잃었다.
이 5건에서 가장 많이 나오는 구성 요소: BGP 라우팅, 백본망. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.