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

사례6건

6건 중 5~6번째

  1. 증상

    2023년 5월 15일 02:36 UTC 부터 us-west-1 리전에 서비스를 둔 Atlassian 고객에게 미디어, 첨부 파일, 빌드 아티팩트 같은 데이터 자산의 저장과 조회가 실패했다. 자동 모니터링이 3분 안에 감지했다.

    촉발

    네트워크 세그먼트 사이의 분리를 강화해 보안을 높이는 작업의 하나로 내부 서비스를 새 네트워크 세그먼트로 옮겼다.

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

    자동 모니터링이 3분 안에 감지했다.

    조치
    • 네트워크 이전 변경을 롤백해 Atlassian 시스템을 정상이던 상태로 되돌렸다.
    후속 조치
    • 서비스 스택을 내리는 시스템을 검토하고, 스택을 내리기 전에 그 스택이 더는 고객 트래픽을 받지 않는지 확인하는 검사를 넣는다.
    • 서비스 네트워크 이전 절차에 함께 손봐야 할 DNS 레코드가 있는지 찾는 단계를 더한다.
    교훈

    Atlassian 은 기존 테스트와 예방 절차가 이 문제를 잡지 못했다고 밝혔다. 서비스를 네트워크 세그먼트 사이로 옮기는 일은 자주 하는 작업이 아니고, 테스트 환경에서 정확히 재현하기도 어렵기 때문이라고 설명했다. 이런 문제를 막으려고 블루/그린 배포 방식을 썼지만, 옛 스택을 내리기 전에 충분한 검증 단계를 돌리지 않았다고 적었다.

  2. 증상

    2023-01-25 09:15 UTC 에 crates.io 운영 인프라에 변경을 배포하는 동안 static.crates.io 의 DNS 레코드가 해석되지 않았다. 사용자는 crate 를 내려받지 못해 빌드가 실패했다.

    촉발

    Rust 인프라 팀이 Terraform 으로 운영 환경에 현재 CDN 의 새 TLS 인증서와 바뀐 DNS 레코드를 함께 배포했다. Terraform 은 기존 인증서와 DNS 레코드를 먼저 지운 뒤 새 인증서를 발급했다.

    원인
    구성 요소
    기여 요인
    조치
    • Terraform 이 배포를 마치고 static.crates.io 의 새 DNS 레코드를 만들자 장애가 저절로 풀렸다.
    후속 조치
    • 운영에 변경을 배포하는 절차, 특히 Git 커밋을 고르는 방법과 변경 내역을 검토하는 방법을 문서로 남긴다. 절차를 정해 두고 계속 고쳐 나가 같은 문제를 피한다.
    • 스테이징에서 따로 만들고 시험한 변경은 운영에도 하나씩 차례대로 배포하고, 이 규칙을 문서에 넣는다.
    • main 브랜치에 병합한 변경은 운영에도 반드시 배포해, Git 에 있는 구성과 실제로 배포된 것이 벌어지지 않게 한다.
    교훈

    TLS 인증서 변경과 DNS 레코드 변경을 따로 배포했다면 이번 장애를 피할 수 있었다. 운영 환경을 master 의 최신 커밋에 고정하면서 여러 변경이 한꺼번에 들어갔고, 병합한 변경을 그때그때 배포하지 않아 운영과 스테이징이 너무 벌어졌다. 팀이 얻은 교훈은 세 가지다. 배포 절차를 문서로 정해야 한다. 스테이징에서 따로 시험한 변경은 운영에도 하나씩 차례로 배포해야 한다. 병합한 변경은 운영에도 배포해야 한다.

내 클러스터에도 있는지 확인하기

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

원인별1