Incident Library
적용된 필터 증상데이터 유실기여 요인파괴적 변경 보호 장치 부재조직CareNet모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례1건

1건 중 1~1번째

  1. 증상

    2025년 8월 어느 날 10:41 에 시스템 개발 본부가 Slack 에 BigQuery 에서 장애가 났다는 첫 보고를 올렸다. 운영 데이터 웨어하우스의 데이터셋이 모두 지워져 있었다.

    촉발

    수정 중이던 테스트 코드가 테스트 환경의 데이터를 초기화하려고 데이터셋을 지우고 같은 이름으로 다시 만드는 처리를 했는데, 설정이 잘못되어 이 처리가 운영 환경의 모든 데이터셋에 실행됐다.

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

    10:41 에 시스템 개발 본부가 Slack 에 BigQuery 에서 장애가 났다는 첫 보고를 올렸다. 11:47 에 시스템 개발 본부가 조사해 AI 기술 개발실의 서비스 계정이 운영 데이터셋을 지운 것을 찾았다.

    조치
    • Cloud Shell 에서 bq cp 명령에 장애 전 시점을 지정해 타임 트래블로 테이블을 하나씩 복원했고, 데이터 대부분을 잃지 않고 되살렸다.
    • bq cp 로 되살릴 수 없는 뷰와 테이블 함수는 BigQuery 의 저장된 쿼리에 남아 있던 생성 쿼리로 다시 만들었다.
    후속 조치
    • 테스트 코드가 운영 환경에 접근하지 못하게 확실히 막는다.
    • 서비스 계정에 주어져 있던 과한 권한을 정리한다.
    • bq cp 로 복원하려면 테이블 이름을 알아야 하므로, 데이터셋과 테이블 정보를 메타데이터로 관리한다.
    • bq cp 로는 뷰와 테이블 함수를 복원할 수 없으므로, 그 생성 쿼리를 GitHub 같은 곳에서 관리한다.
    • BigQuery 의 백업 방식을 검토한다.
    교훈

    bq cp 로 복원하려면 테이블 이름을 알고 있어야 하고, 이 방법으로는 뷰와 테이블 함수를 되살릴 수 없다. 글쓴이의 팀은 BigQuery 의 타임 트래블 기능과 bq cp 명령 덕분에 데이터 대부분을 되살릴 수 있었다고 정리했다.

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

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

원인별1