첫 대응의 목표는 원인을 단정하는 것이 아니라 사용자 영향과 대응 책임자를 확인하고, 안전한 완화 조치를 선택하는 것입니다. 영향·담당·조치·다음 확인 시각을 한 기록에 모으세요.
먼저 확인할 네 가지
장애 알림을 받으면 ① 어떤 사용자 기능이 영향을 받는지 ② 언제부터 증상이 보였는지 ③ 현재 대응을 조율하는 사람이 누구인지 ④ 다음 상황 공유를 언제 할지부터 적습니다. 원인을 아직 모르더라도 확인된 사실은 공유할 수 있습니다. 여기서 15분은 조직의 대응 시간을 보장하는 기준이 아니라 초기 대응을 나누어 보는 예시입니다. 정보 유출이나 안전 문제처럼 별도 절차가 있는 사고는 해당 조직의 사고 대응 절차를 우선합니다.
0~5분: 알림과 사용자 영향을 구분하기
알림 이름을 그대로 장애의 범위로 간주하지 마세요. 로그인, 조회, 저장 등 실제 기능이 실패하는지 확인하고, 전체 사용자 문제인지 일부 구간의 문제인지 나눕니다. 대시보드 지표에는 조회한 시간 범위도 함께 남깁니다. 예를 들어 ‘응답 시간 상승’ 알림과 ‘모든 결제 실패’는 다른 상태입니다. 가상 사례의 첫 기록은 ‘14:02부터 주문 조회 지연 관측, 결제 영향은 미확인, 고객 문의 2건 확인’처럼 사실과 미확인을 분리할 수 있습니다. 예시 숫자는 실제 운영 실적이 아닙니다.
5~10분: 조율·실행·기록 역할 정하기
여러 사람이 동시에 설정을 바꾸면 어떤 조치가 효과가 있었는지 알기 어렵습니다. 한 사람은 진행을 조율하고, 다른 사람은 복구 작업을 수행하며, 기록과 공지를 맡을 사람도 정합니다. 작은 팀에서는 한 사람이 여러 역할을 맡되 현재 맡은 역할을 명시합니다. 변경 내용, 실행자, 실행 시각, 예상 결과, 중단 기준을 공용 기록에 남깁니다. 조직에서 승인한 대응 채널을 사용하고 비밀번호·토큰·개인정보는 붙여 넣지 않습니다.
10~15분: 되돌릴 수 있는 완화책 검토하기
최근 배포가 있었다면 연관성을 확인하되 그것이 원인이라고 단정하지 않습니다. 롤백, 트래픽 우회, 기능 일시 중지 등 가능한 조치마다 영향 범위와 되돌리는 방법을 확인합니다. 데이터 변경이 포함된 배포는 애플리케이션만 되돌려도 안전한지 별도로 살펴야 합니다. 조치 후에는 동일한 사용자 기능과 지표를 다시 확인합니다. 오류율이 내려갔는지, 지연이 해소됐는지, 밀린 작업이 남았는지까지 확인한 뒤 상황을 공유합니다. 증상 완화와 근본 원인 규명은 별도의 완료 조건입니다.
그대로 옮겨 적는 초기 상황 기록
발견 시각 / 관측 시작 시각: 영향받는 기능과 사용자 범위: 확인된 사실 / 아직 모르는 내용: 대응 조율자 / 실행자 / 공지 담당: 수행한 조치와 결과: 다음 확인 시각: 짧은 기록이라도 같은 형식으로 이어 쓰면 교대 시 설명 비용을 줄일 수 있습니다. 상황이 바뀔 때는 이전 내용을 지우기보다 시각을 붙여 새 사실을 추가하세요.
참고 자료와 적용 범위
역할 분담과 상황 기록의 기본 원칙은 Google SRE Workbook의 Incident Response를 참고했습니다. 시간 구간과 기록 양식은 작은 운영팀이 적용을 검토할 수 있도록 구성한 일반 예시이며 특정 회사의 장애 사례가 아닙니다. https://sre.google/workbook/incident-response/
장애 대응의 기술
당황하지 않는 운영자를 위한 실무 가이드