인시던트
Incident · 운영 장애
인시던트는 서비스나 업무가 예기치 않게 중단되거나 성능·보안·데이터 상태가 허용 범위를 벗어나 대응 조직의 조정이 필요한 사건입니다. 원인 분석이 끝나기 전에도 영향과 대응 필요성을 기준으로 선언할 수 있습니다.
AI 보조 조사·작성 후 원문과 대조한 설명입니다. 사례·계산은 별도 출처 표기가 없는 한 이해를 위한 가상 예시이며 실제 고객 성과가 아닙니다.
언제 인시던트로 선언하나요?
고객에게 보이는 중단, 여러 팀이 필요한 장애, 정해진 시간 안에 원인을 찾지 못한 문제처럼 조직이 합의한 문턱을 사용합니다. Google SRE는 고객 가시성, 두 번째 팀의 참여 필요, 집중 분석 뒤에도 미해결인 상태를 선언 기준의 예로 듭니다. Google SRE 인시던트 관리
심각도를 확정할 정보가 부족해도 낮은 단계로 먼저 선언하고 범위를 조정할 수 있습니다. 반대로 알림 하나가 울렸다는 이유만으로 모두 인시던트가 되는 것은 아닙니다. 실제 영향, 확산 가능성, 대응 복잡도를 봅니다.
장애 공지에는 무엇을 적나요?
첫 공지에는 관찰된 현상, 영향받는 기능·사용자 범위, 시작 시각, 현재 대응과 다음 업데이트 시각을 씁니다. 확인하지 못한 원인을 단정하거나 복구 예상 시각을 약속하지 않습니다. 원인 가설은 내부 문서에 가설이라고 표시합니다.
Atlassian은 인시던트를 일상 요청과 달리 서비스가 중단·저하된 계획되지 않은 사건으로 설명하고 준비, 식별, 억제, 제거, 복구, 사후 검토 단계를 제시합니다. Atlassian 인시던트 대응 단계는 운영·보안 사건을 함께 다루므로 조직 상황에 맞게 범위를 정합니다.
시간대별 기록은 어떻게 남기나요?
가상 예시는 다음과 같습니다. 14:05 결제 완료율 하락 알림, 14:12 특정 결제수단에서 오류 재현, 14:20 신규 배포 중지, 14:35 우회 경로 적용, 14:50 완료율 정상 범위 회복입니다. 각 줄에는 누가 무엇을 관찰하거나 변경했는지와 증거 링크를 붙입니다.
복구 공지에는 정상화 시각과 남은 영향, 추후 분석 계획을 적습니다. 결제 실패 주문의 재처리나 중복 청구 점검이 남았다면 서비스 복구와 후속 업무 완료를 같은 상태로 쓰지 않습니다.
인시던트와 문제·서비스 요청은 어떻게 다른가요?
인시던트는 현재 영향의 완화와 복구가 우선입니다. 문제 관리는 반복 원인과 구조적 개선을 다루고, 서비스 요청은 권한 추가나 설정 변경처럼 표준 절차로 처리하는 요구입니다. 하나의 인시던트에서 여러 문제 과제가 나올 수 있지만 사고 중에는 원인 규명보다 영향 축소가 앞설 수 있습니다.
상태 문서의 최소 항목
- 선언 시각과 현재 심각도
- 영향받는 기능·지역·사용자 범위
- 확인된 사실과 아직 검증 중인 가설
- 실행한 변경, 결과와 다음 담당자
- 다음 업데이트 시각과 외부 공지 링크
원인 분석 보고서는 사건 중 공지보다 늦게 나와도 됩니다. 다만 당시 결정에 사용한 증거와 실패한 조치를 지우지 않아야 사후 검토에서 대응 과정을 재구성할 수 있습니다.
자주 묻는 질문
- 원인을 모르면 인시던트를 선언할 수 없나요?
- 선언할 수 있습니다. 영향과 대응 필요성이 확인되면 원인 분석 전에도 선언하고 상태를 갱신합니다.
- 장애 공지에 ETA를 꼭 적어야 하나요?
- 확인된 근거가 없다면 복구 시각을 확약하지 말고 다음 업데이트 시각을 제시하는 편이 낫습니다.
- 복구되면 사후 검토는 생략해도 되나요?
- 반복 가능성, 대응 지연과 후속 조치를 확인하려면 사건 기록을 바탕으로 검토하는 편이 좋습니다.
출처와 확인 범위
- Managing Incidents · Google SRE · 확인 2026-10-27
역할 분리, 상태 문서, 공지와 선언 기준 사례를 설명합니다.
확인 범위: Google SRE 운영 사례이며 모든 조직의 심각도 기준은 아닙니다.
- What is incident response? · Atlassian · 확인 2026-10-27
인시던트와 일상 요청의 차이, 대응 생명주기를 설명합니다.
확인 범위: Atlassian의 일반 가이드이며 법정 사고 신고 절차를 대신하지 않습니다.