사례2건
2건 중 1~2번째
- 증상
평일 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 데이터센터에서 난 다른 사고들까지 함께 보며 이 문제의 근본 원인을 계속 조사한다.
- 운영 중인 네트워크에 인프라 업그레이드를 적용하는 동안 인프라가 계속 안정적으로 동작하도록 절차를 마련한다.
이 2건에서 가장 많이 나오는 구성 요소: 네트워크 스위치. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.