Incident Library
적용된 필터 원인소프트웨어 결함조직Mozilla모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례1건

1건 중 1~1번째

  1. 증상

    2022년 1월 13일 07:28 UTC 직후 크래시 리포터로 들어오는 크래시가 갑자기 늘었고, Mozilla 안팎에서 브라우저가 멈춘다는 신고가 여럿 들어왔다. 전 세계 사용자의 Firefox 가 2시간 가까이 웹 콘텐츠를 불러오지 못하고 쓸 수 없는 상태가 됐다.

    촉발

    2022년 1월 13일 07:28 UTC 에 GCP 가 예고 없이 로드 밸런서의 HTTP/3 를 기본으로 켰다. Mozilla 의 로드 밸런서는 "Automatic (default)" 설정이어서 Firefox 가 Telemetry 서비스로 여는 연결 일부가 HTTP/2 대신 HTTP/3 를 쓰게 됐다.

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

    크래시 리포터로 들어오는 크래시가 갑자기 늘었고, Mozilla 안팎에서 브라우저가 멈춘다는 신고가 여럿 들어왔다.

    조치
    • 09:12 UTC 에 GCP 에서 HTTP/3 를 명시적으로 껐다.
    후속 조치
    • GCP 와 함께 예고 없는 기본값 변경 문제를 개선한다.
    • 비슷한 실수를 막으려고 모든 서비스의 설정을 다시 검토한다.
    • HTTP 버전을 바꿔 가며 시스템 테스트를 더 돌린다.
    • 이런 문제에 브라우저가 더 잘 견디고 사고 대응이 더 빨라지도록 할 조치를 찾는다.
    교훈

    문제는 처음 보기보다 훨씬 복잡했고 여러 요인이 함께 작용했다. GCP 가 HTTP/3 기본값 변경을 예고했다면 사고를 완전히 막지는 못했어도 스테이징 환경 같은 곳에서 더 통제된 실험과 배포를 할 수 있었을 것이다. 로드 밸런서를 명시적인 값 대신 "Automatic (default)" 로 둔 탓에 변경이 저절로 적용됐다. Firefox Desktop 에서 HTTP/3 와 viaduct 를 함께 쓰는 조합은 CI 가 시험하지 않았다. 모든 조합을 시험할 수는 없어도 HTTP 버전 선택이나 viaduct 같은 추가 네트워크 계층은 시험했어야 했다. HTTP 버전을 바꿔 가며 시스템 테스트를 더 돌렸다면 이 문제를 찾았을 것이다.

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

이 사례에서 가장 많이 나오는 구성 요소: 클라우드 로드 밸런서, HTTP·RPC 클라이언트 라이브러리. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1