사례4건

4건 중 1~4번째

1. IL-0568 DeNA의 한 사업장에서 L2 스위치 루프가 생겨 사업장 전체의 단말이 서버에 접속하지 못하거나 통신이 느려졌다

   DeNA2026

   증상

   평일 20시쯤 사업장 현장에서 고객 업무에 쓰는 특정 시스템의 단말이 통신하지 못해 영업에 문제가 생겼다는 연락이 왔다. 네트워크 그룹의 모니터링에서는 알림이 하나도 울리지 않았다.

   간헐적 연결 실패지연 시간 증가

   촉발

   Cisco Catalyst 2960L 15대의 설정을 맞추는 작업에서, SW2와 SW3 사이 LACP LAG를 이루는 물리 포트 두 개 중 SW3 쪽 한 포트에만 no switchport trunk allowed vlan 을 넣어 허용 VLAN 지정을 지웠다.

   원인

   운영 실수

   구성 요소

   네트워크 스위치

   기여 요인

   모니터링 사각지대단계적 배포 부재런북 부재피크 시간 변경

   감지

   모니터링 알림은 울리지 않았고, 20시쯤 사업장 현장에서 단말이 통신하지 못한다는 연락을 받고 알았다. 대상 포트의 인터페이스 모니터링은 처음부터 없었고, LACP 모니터링은 꺼져 있었으며, CPU 상승은 10% 정도라 리소스 알림에 걸리지 않았다.

   조치

   • 원인 지점을 모른 채 작업을 되돌리기 시작했고, 30분쯤 뒤 장비 한 대의 인터페이스 설정을 원래대로 되돌린 시점에 복구됐다.
   • 22시쯤 이어진 조사에서 원인 지점을 확인하고 다른 영향이 없음을 확인한 뒤 1차 대응을 마쳤다.

   후속 조치

   • 대상 포트에 빠져 있던 인터페이스 모니터링과 꺼져 있던 LACP 모니터링을 즉시 바로잡았다.
   • 모니터링 설정 변경은 가벼운 임계값 변경까지 모두 리뷰를 거치게 했다.
   • 알림 규칙을 정의한 리포지토리의 PR은 리뷰어 승인 없이는 머지할 수 없도록 설정을 바꿨다.
   • PR에 AI 자동 리뷰를 켜서 사람 말고도 누락을 찾을 수 있게 했다.
   • 네트워크 변경 작업은 가벼운 작업이라도 스스로 판단하지 않고 미리 공지하는 규칙으로 바꿨다.
   • 작업 일시는 사업장 책임자 등과 일정을 맞추고, 사업장의 운영 일정을 파악해 행사일을 피한다는 규칙을 다시 확인했다.
   • 영향이 큰 유지보수나 이번처럼 여러 대를 함께 바꾸는 작업처럼 되돌릴 때 시간이 걸리는 작업은 되돌리는 절차를 미리 만든다.

   교훈

   말단 장비 한 대라도 사업장 전체에 영향을 줄 수 있다. 작업 실수, 예상 못 한 상황, 버그 같은 이유로 작업 중에는 언제든 장애가 날 수 있으므로, 미리 일정을 맞춰 유지보수 시간을 확보해야 한다. 여러 대를 한꺼번에 바꾸면 원인 장비를 찾고 되돌리는 데 시간이 걸린다. 만일에 대비해 미리 준비하고, 사람이 아니라 구조로 막을 수 있는 부분은 막아야 한다. 지금이라면 로그를 AI에게 보여 주고 원인을 바로 찾을 수 있었을 것이다. 이번 같은 장애에는 AI의 사전 리뷰와 장애 상황 분석이 효과가 있었을 것이다.

   사례 보기
2. IL-0378 Cloudflare R2 객체 스토리지에서 1시간 7분 동안 쓰기가 모두 실패하고 읽기가 전 세계에서 약 35% 실패했다

   Cloudflare2025

   증상

   21:45 UTC 에 R2 전역 가용성 알림이 울렸다. 알림은 오류 예산 소진율 2% 를 가리켰고, R2 의 읽기와 쓰기 가용성 지표가 조금씩 계속 내려가고 있었다.

   자격 증명 획득 실패오류율 상승

   촉발

   R2 엔지니어링 팀이 R2 Gateway 서비스의 스토리지 인프라 자격 증명을 교체하면서 wrangler secret put 과 wrangler deploy 에 --env 인자를 빠뜨렸다. 새 자격 증명은 운영 Worker 가 아니라 기본 환경 Worker 에 들어갔고, 그 뒤 스토리지 인프라에서 옛 자격 증명을 지웠다.

   원인

   운영 실수

   구성 요소

   오브젝트 스토리지

   기여 요인

   미검증 가정모니터링 사각지대늦게 드러난 변경

   감지

   21:45 UTC 에 R2 전역 가용성 알림이 울렸다. 알림은 오류 예산 소진율 2% 를 가리켰고, R2 엔지니어링 팀은 운영 대시보드와 로그를 보기 시작했다.

   조치

   • 22:45 UTC 에 올바른 운영 R2 Gateway Worker 에 자격 증명을 배포했고, R2 가용성이 돌아왔다.

   후속 조치

   • R2 Gateway Worker 가 스토리지 인프라 인증에 쓰는 자격 증명 ID 의 끝자리를 로그 태그에 넣어, 어떤 자격 증명을 쓰는지 바로 확인할 수 있게 했다.
   • 옛 토큰을 지우기 전에 새 토큰 ID 의 끝자리가 스토리지 인프라 로그와 맞는지 반드시 확인하도록 내부 절차를 바꿨다.
   • 키 교체를 wrangler 명령을 손으로 치는 대신 핫픽스 배포 도구로만 하도록 했다. 이 도구는 환경 설정을 강제하고 다른 안전 검사도 한다.
   • 변경을 적어도 두 사람이 확인한다는 관행을 관련 표준 운영 절차에 명시했다.
   • 엔드포인트를 감시하는 기존 폐루프 상태 검사 시스템을 넓힌다. 이 시스템이 새 키를 시험하고, 그 상태를 알림 플랫폼으로 자동 보고하고, 게이트웨이 Worker 를 배포하기 전에 새 키가 전역으로 퍼졌는지 확인하게 한다.
   • 분산 스토리지 엔드포인트의 문제를 빨리 가려내도록, 관측 플랫폼에 캐시를 거치지 않은 업스트림 성공률 화면을 더한다.

   교훈

   이번 장애는 사람의 실수로 일어났고, R2 Gateway Worker 가 어떤 자격 증명으로 스토리지 인프라에 인증하는지 볼 수 없어서 더 길어졌다. Cloudflare 는 옛 자격 증명을 지운 뒤 가용성 지표에 기대지 말고, R2 Gateway 서비스가 실제로 어떤 토큰을 쓰는지 직접 확인했어야 했다고 적었다.

   사례 보기
3. IL-0531 West US 의 Azure Database for MySQL Single Server 와 MariaDB 일부 서버로 가는 새 연결이 모두 거부됐다

   Microsoft Azure2024

   증상

   West US 리전에서 Azure Database for MySQL - Single Server 와 Azure Database for MariaDB 의 일부 고객은 데이터베이스로 가는 연결이 모두 실패했고, 재시도해도 성공하지 못했다. 데이터베이스 자체는 정상이었지만 연결이 하나도 맺어지지 않았다.

   서비스 중단간헐적 타임아웃

   촉발

   계획된 게이트웨이 하드웨어 교체 작업에서 2024-04-19 04:26 UTC 에 Azure Database for MySQL 과 MariaDB 서버 한 묶음의 DNS 를 바꿨다. 절차상의 실수로 새 연결이 설정이 덜 끝난 새 게이트웨이 링으로 보내졌다.

   원인

   운영 실수

   구성 요소

   데이터베이스DNS 서버와 레코드

   기여 요인

   모니터링 사각지대

   감지

   새 게이트웨이 링에 텔레메트리와 모니터링이 없어 서비스 텔레메트리는 실패를 잡지 못했다. MySQL 팀은 04:46 UTC 에 Azure Databricks 가 여러 데이터베이스에 닿을 수 없다고 알려 와서 장애를 알았다.

   조치

   • 07:30 UTC 에 변경을 완전히 롤백했고, 검증을 거쳐 모든 연결을 정상 동작하던 이전 게이트웨이 링으로 되돌렸다.

   후속 조치

   • MySQL 엔지니어링 팀은 운영 게이트웨이 링을 전환하기 전에 점검, 테스트, 승인 절차를 더한다. 2024년 5월에 마칠 예정이다.
   • Azure Databricks 엔지니어링 팀은 짧은 시간 안에 여러 데이터베이스를 쓸 수 없게 되는 상황을 잡는 알림을 만든다. 2024년 5월에 마칠 예정이다.

   사례 보기
4. IL-0491 CDN 원본 서버군의 정상 노드가 안전 수준 아래로 줄어 Squarespace 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다

   Squarespace2019

   증상

   2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. static.squarespace.com과 static1.squarespace.com 도메인이 영향을 받아 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다.

   오류율 상승

   촉발

   2019-02-11 오후 10시 30분 ET에 한 엔지니어가 Squarespace CDN 원본 서버군 전체에 유지보수 작업을 시작했다. 엔지니어는 작업을 멈췄다고 생각했지만 작업은 백그라운드에서 계속 돌았고, 2019-02-12 오전 12시 10분에 CDN 원본 서비스 장애를 일으켰다.

   원인

   운영 실수

   구성 요소

   CDN 과 엣지 네트워크

   기여 요인

   과도한 영향 범위모니터링 사각지대

   감지

   2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. 알림은 서버군이 핵심 가용성 기준 아래로 떨어진 뒤에야 왔고, 고객 영향이 크다는 것은 나중에야 분명해졌다.

   조치

   • 오전 2시 15분 ET까지 추가 복구 조치로 CDN 원본 서버군 일부를 되살렸고, 2시 20분에 서비스가 정상으로 돌아왔다.

   후속 조치

   • 장애 대응 플레이북을 고쳐 이 서버군에 영향을 주는 문제 대부분을 빨리 해결할 점검과 조치를 넣는다. 첫 점검에서 고객 영향을 판단하고 인시던트 커맨더를 바로 부르게 한다.
   • CDN 협력사와 원본 서비스의 문제가 고객에게 주는 영향을 더 빨리 판단할 수 있도록 외부 모니터링을 개선한다.
   • 엔지니어가 유지보수 명령을 내리는 방식의 운영 정책을 고치고 안전장치를 더한다. 그런 명령이 작업할 수 있는 서버군의 범위를 제한한다.
   • 사람이 직접 하는 유지보수 작업이 필요한 경우를 줄인다.
   • 독립된 장애 도메인을 만들고, 상태가 나쁜 부분을 피해 요청을 자동으로 보내도록 해 인프라의 복원력을 높인다.

   사례 보기

원인별1