인시던트 핸들링의 핵심: 장애 대응에서 가장 중요한 것

SRE 입문 4부작의 마지막은 Error Budget을 실제로 태우는 순간, 장애 대응입니다. 장애 대응 역량의 차이는 대개 기술이 아니라 절차에서 갈립니다. 유능한 개인이 새벽에 혼자 고치는 조직과, 누가 온콜이어도 같은 품질로 대응하는 조직의 차이입니다. 이 글은 그 절차의 뼈대를 정리합니다. 장애를 사용자 관점에서 설명하는 교양 편은 IT 상식 #4에서 다뤘고, 이 글은 대응하는 쪽의 시각입니다.

원칙 하나: 복구가 원인 규명보다 먼저입니다 #

장애 중에 가장 흔한 함정은 “왜 그런지"를 파는 것입니다. 인시던트 중의 질문은 “원인이 무엇인가"가 아니라 “사용자 영향을 지금 어떻게 끝내는가“입니다. 원인은 몰라도 복구는 되는 경우가 많습니다. 직전 배포 롤백, 문제 인스턴스 격리, 캐시된 응답으로 폴백, 트래픽 우회가 그렇습니다. 실제로 많은 조직의 1번 런북이 “최근에 뭐가 바뀌었나 → 되돌려라"인 이유입니다.

원인 규명은 복구 뒤, 포스트모템의 일입니다. 이를 위해 복구 과정에서 증거(로그, 지표 스냅숏, 타임라인)를 대응 중에 그때그때 남겨 두는 습관이 필요합니다. 진단 자체가 막힐 때를 위해서는 서버가 느린 이유 시리즈 같은 체계를 미리 런북으로 만들어 두는 것이 답이고, 인시던트 중에 처음부터 생각해 내는 것이 아닙니다.

역할 분리: 고치는 사람이 지휘하지 않습니다 #

일정 규모 이상의 인시던트에서 가장 중요한 구조는 역할 분리입니다.

• 인시던트 커맨더(IC): 대응 전체를 지휘합니다. 상황 파악, 작업 할당, 우선순위 결정을 하고, 직접 키보드를 잡지 않습니다. 디버깅에 빠진 사람은 전체 그림을 놓치기 때문입니다.
• 작업 담당(ops): 실제 조사와 복구 작업을 합니다. 발견과 변경 사항을 IC에게 보고합니다.
• 소통 담당: 상황을 요약해 이해관계자(경영진, CS, 필요하면 고객 공지까지)에게 주기적으로 알립니다. 이 역할이 없으면 작업자가 5분마다 “지금 어때요?“에 답하느라 복구가 늦어집니다.

작은 팀이라 세 명이 없어도 원칙은 유지할 수 있습니다. 두 명이면 한 명이 IC + 소통, 한 명이 작업을 맡고, 혼자라면 최소한 “10분마다 상황 한 줄 기록"으로 소통 채널을 대신합니다. 핵심은 지휘·소통이라는 일이 존재한다는 것을 아는 것입니다.

심각도 등급과 선포: 판단을 미리 만들어 둡니다 #

“이거 인시던트인가?“를 새벽 3시에 고민하게 만들면 안 됩니다. 심각도 등급과 선포 기준을 평시에 정의해 둡니다.

번 레이트 알림과 연결하면 선포 기준이 자연스러워집니다. 빠른 소진 알림은 SEV1〜2 후보, 느린 소진은 SEV3 티켓입니다. 그리고 애매하면 높은 등급으로 선포하고 나중에 낮추는 쪽이, 낮게 잡았다가 키우는 쪽보다 항상 쌉니다. 과소 선포는 대응 지연으로, 과대 선포는 기껏해야 약간의 머쓱함으로 끝납니다.

포스트모템: 비난 없이, 그러나 두루뭉술하지 않게 #

복구가 끝나면 포스트모템을 씁니다. 형식은 조직마다 달라도 네 가지는 반드시 들어갑니다. 타임라인(감지부터 복구까지, 시각과 함께), 영향(사용자 몇 %가 몇 분, 예산 얼마 소진), 원인 분석(직접 원인과 그것을 가능하게 한 구조), 액션 아이템(담당자와 기한이 붙은 재발 방지책)입니다.

“비난 없는(blameless)“의 의미는 자주 오해됩니다. 책임을 묻지 않는다는 뜻이 아니라, “누가 실수했나"를 “무엇이 그 실수를 가능하게 했나"로 바꾼다는 뜻입니다. “A가 프로덕션에 잘못된 설정을 넣었다"에서 멈추면 얻는 것이 없습니다. “설정 변경에 검증 단계가 없었고, 스테이징과 프로덕션의 설정 파일이 같은 화면에서 편집된다"까지 가야 시스템이 고쳐집니다. 사람을 겨냥하면 다음부터 사실이 숨겨지고, 숨겨진 사실 위에서는 어떤 재발 방지도 세울 수 없습니다. 그리고 액션 아이템은 기한과 담당자가 없으면 안 쓴 것과 같습니다. 분기마다 미이행 액션 아이템을 리뷰하는 루틴까지가 포스트모템입니다.

온콜: 지속 가능해야 굴러갑니다 #

이 모든 절차의 전제는 대응할 사람, 온콜입니다. 온콜이 무너지는 조직의 공통점은 기술이 아니라 부하입니다.

• 알림의 질: 대응이 필요 없는 알림(정보성, 자동 복구되는 것)이 호출로 오면 온콜은 빠르게 마모됩니다. 호출은 “지금 사람의 행동이 필요한 것"으로 제한하고, 나머지는 티켓이나 대시보드로 내립니다. 번 레이트 방식이 이 구분을 자연스럽게 만들어 줍니다.
• 부하의 상한: 교대 주기당 호출 횟수를 관측하고, 일정선을 넘으면 알림 정리와 근본 원인 제거가 기능 개발보다 우선한다는 규칙을 둡니다. 1편에서 본 토일 상한과 같은 원리입니다.
• 런북: 반복 알림에는 “이 알림이 오면 무엇을 본다 → 무엇을 한다"가 적힌 런북을 붙입니다. 런북 없는 알림은 매번 그 시스템을 아는 사람을 찾게 만들고, 그 사람이 곧 단일 장애점이 됩니다.

정리 #

• 인시던트 중의 목표는 원인 규명이 아니라 사용자 영향 종료입니다. 롤백, 격리, 폴백 같은 복구 수단을 먼저 씁니다.
• 지휘(IC), 소통, 작업의 역할을 분리합니다. 고치는 사람이 지휘까지 하면 둘 다 느려집니다.
• 심각도 등급과 선포 기준은 평시에 정의합니다. 애매하면 높게 선포하고 낮추는 쪽이 쌉니다.
• 포스트모템은 타임라인, 영향, 구조적 원인, 기한 있는 액션 아이템으로 쓰고, “누가"가 아니라 “무엇이 가능하게 했나"를 묻습니다.
• 온콜은 알림의 질과 부하 상한, 런북으로 지속 가능하게 만듭니다. 지속 불가능한 온콜 위에는 어떤 절차도 서지 않습니다.

이것으로 SRE 입문 4부작이 끝났습니다. SLI·SLO로 목표를 숫자로 만들고, Error Budget으로 속도와 안정성의 규칙을 세우고, 인시던트 절차로 예산을 지킵니다. 이 세 가지의 순환이 SRE의 뼈대입니다.