사례3건
3건 중 1~3번째
- 증상
평일 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의 사전 리뷰와 장애 상황 분석이 효과가 있었을 것이다.
- 증상
2022년 12월 13일 0:05 UTC 쯤 모니터링 시스템이 Dallas 데이터센터에 접속할 수 없는 문제를 잡아 알림을 냈다. 이 데이터센터 Linode 의 약 80-90% 에서 지연이 간헐적으로 늘고 연결이 끊겼다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
0:05 UTC 쯤 모니터링 시스템이 Dallas 데이터센터에 접속할 수 없는 문제를 잡아 알림을 냈다. 0:10 에 사고로 등록했다.
- 조치
- 4:20 UTC 쯤 브로드캐스트를 막는 필터를 전체 호스트에 배포했다.
- 임시 조치였던 필터를 더 시험한 뒤 12월 13일 18:35 UTC 에 영구 적용했다.
- 후속 조치
- 최근 Dallas 데이터센터에서 난 다른 사고들까지 함께 보며 이 문제의 근본 원인을 계속 조사한다.
- 운영 중인 네트워크에 인프라 업그레이드를 적용하는 동안 인프라가 계속 안정적으로 동작하도록 절차를 마련한다.
- 증상
2012년 11월 30일 금요일, GitHub 는 18분 동안 완전히 접속이 안 됐고, 하루 종일 응답이 이따금 느려지고 오류가 간헐적으로 났다. 파일 서버 한 쌍이 하루 대부분 내려가 있어 일부 저장소가 영향을 받았다.
- 촉발
새 애그리게이션 스위치를 들이려고 액세스 스위치를 떼어 설정을 바꾸고 다시 연결하는 작업을 했다. 11월 30일 아침 A 스위치를 옮기던 중 마지막 스위치에서 브리지 루프가 생겼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
마지막 A 스위치를 연결할 때 같은 캐비닛의 B 스위치와 연결이 끊겼다. 문제를 고친 뒤에도 성능이 기대만큼 나오지 않아 들여다보다가 액세스 스위치와 애그리게이션 스위치 사이 링크가 모두 포화된 것을 봤다.
- 조치
- 마지막 A 스위치에서 난 첫 문제를 빨리 해결하고, 영향받은 B 스위치를 다시 서비스에 넣어 이전을 마쳤다.
- 액세스 스위치에서 잘못된 설정을 지웠다. 그 뒤로는 링크를 시험해도 페일오버가 기대대로 작동했고, 애그리게이션 계층이나 액세스 계층의 스위치 하나를 빼도 서버에 영향이 없었다.
- 몇 시간을 더 찾아도 설정 문제가 나오지 않자 네트워크 공급사에 다시 에스컬레이션했고, 공급사는 이 문제를 가장 높은 심각도 등급으로 올려 바로 함께 조사했다.
- 태평양 시간 토요일 오전 6시에 네트워크 점검 시간을 잡고 애그리게이션 스위치의 핵심 프로세스 일부를 재시작해 MAC 주소를 다시 학습하게 했다. 이 우회책이 통해서 트래픽과 성능이 정상으로 돌아왔다.
- 후속 조치
- 공급사가 MAC 학습 문제의 근본 원인을 찾았고, 1주일쯤 안에 최종 수정이 나오면 스위치에 소프트웨어 업데이트를 배포한다.
- 그때까지 애그리게이션 계층과 액세스 계층 사이 용량을 면밀히 지켜보고, 문제가 다시 나면 쓸 우회 절차를 둔다.
- 라우터부터 액세스 계층 스위치까지 네트워크 스택을 똑같이 한 벌 더 갖춰 스테이징 환경으로 쓰고, 이런 변경을 미리 더 충분히 시험한다.
- 비슷한 문제가 생기면 더 빨리 알림을 받도록 네트워크에 자동 모니터링을 더한다.
- 앞으로 몇 달 동안 정기적인 장애 대응 훈련을 늘리고, 한 가지 가설에 매달리지 않도록 하는 시나리오를 만든다.
- 앞으로는 네트워크에 문제 조짐이 처음 보일 때 바로 공급사 지원팀에 연락한다.
- 교훈
GitHub 는 고객에게 영향이 없도록 설계한 점검 작업이 결국 고객에게 영향을 줬다고 인정했다. 장애 대응 중에 브리지 루프라는 생각에 오래 매달려 다른 원인을 보지 못했고, 그래서 한 가지 가설에 갇히는 것을 더 경계해야 한다고 했다. GitHub 는 공급사 지원팀과 일한 경험이 좋았다며, 앞으로는 문제 조짐이 처음 보일 때 바로 지원팀에 연락하겠다고 했다.
이 3건에서 가장 많이 나오는 구성 요소: 네트워크 스위치, NIC·케이블·스위치 포트 링크. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.