Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례2건

2건 중 1~2번째

  1. 증상

    2020-07-16 13:26 UTC 부터 Gandi LiveDNS 의 DNS 노드 두 대로 간 질의가 타임아웃으로 실패했다. 상태 페이지에는 13:26 에 FR 고객에게 영향이 있다는 글이 올라갔다.

    촉발

    LiveDNS 노드 두 대의 DNS 서버 소프트웨어에서 버그가 장애를 일으켜 서버가 멈췄다.

    원인
    구성 요소
    기여 요인
    감지

    DNS 서버에서 LiveDNS 모니터링 알림이 울렸다. 그러나 앞서 다루던 내부 네트워크 사고가 모니터링 시스템에 소음을 많이 만들고 있어 엔지니어들은 이 알림을 오탐으로 잘못 읽었고, 알림을 다시 판단하기까지 시간이 걸렸다.

    후속 조치
    • DNS 서버가 제대로 동작하지 않을 때 노드를 서비스에서 빼는 방식을 고친다.
    • 노드 설정을 고치고, 한 노드가 여러 클러스터의 주소를 알리지 않는지 확인하는 모니터링을 둔다.
    • 모니터링과 내부 교육, 조직 운영을 다시 짠다.
    • DNS 서버 소프트웨어의 버그를 찾아냈고, 고친 판을 배포하고 있다.
  2. 증상

    2016년 12월 15일 새벽 GOV.UK PaaS 의 VM 에 DNS 조회 오류가 기록되기 시작했고, PaaS 에 배포한 애플리케이션이 DNS 조회에 간헐적으로 실패했다. 그 때문에 서비스가 데이터베이스, 백엔드 서비스, API 에 연결하지 못했을 수 있다. 01:00 부터 03:17 사이에 이 애플리케이션을 쓴 사용자는 간헐적인 느려짐과 오류를 봤을 수 있다.

    원인
    구성 요소
    기여 요인
    감지

    장애가 난 시각에 팀은 PaaS 를 24시간 지원하지 않았다. 팀은 12월 15일 업무를 시작하면서 모니터링 알림이 나가 있던 것을 알아챘다. 08:00 에 팀원이 경고를 보고, 모니터링에서 영향이 끝났음을 확인했다.

    후속 조치
    • 디스크 모니터링 데이터가 들어오지 않을 때는 모니터링 시스템이 메일을 보내지 않게 한다. 메일이 너무 많으면 다른 알림을 알아보기 어렵기 때문이다.
    • 장애를 tenant 에게 더 쉽고 빠르게 알릴 수 있게 한다.
    • 업무 시간 밖 지원에 쓸 알림을 곧 도입하고, 어떤 알림을 둘지는 이 장애를 예로 삼아 정한다.
    • PaaS 를 쓰는 서비스의 필요에 맞춰 곧 24시간 지원을 시작한다.
내 클러스터에도 있는지 확인하기

이 2건에서 가장 많이 나오는 구성 요소: BGP 라우팅, DNS 서버와 레코드. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별2