서비스가 느려졌다는 고객 문의가 들어왔습니다. 개발자는 서버 로그를 보고, 운영자는 고객에게 답할 문구를 찾고, 책임자는 ‘언제 정상화되느냐’고 묻습니다. 모두 바쁘지만 같은 상황을 보고 있지는 않습니다. 장애 대응에서 가장 먼저 필요한 것은 대단한 자동화가 아니라 공통의 현재 상태와 다음 행동입니다.
모든 알림이 장애는 아니고, 모든 장애가 서버 다운도 아니다
서버가 켜져 있어도 결제가 실패하거나 문의 폼이 저장되지 않으면 고객에게는 장애입니다. 반대로 경보 하나가 울렸다고 곧바로 전사 장애라고 판단하면 대응 에너지가 소진됩니다. 서비스별 핵심 사용자 여정과 영향 기준을 먼저 정합니다. 예를 들어 로그인 불가, 데이터 손실 가능성, 특정 고객사만 영향, 우회 방법 유무를 구분할 수 있습니다.
초기 기록에는 발견 시각, 관측된 증상, 영향받는 기능과 고객 범위, 마지막 정상 시각, 최근 변경, 임시 대응 담당자를 남깁니다. 원인은 아직 모를 수 있으므로 ‘확인된 사실’과 ‘가설’을 구분합니다. 추측을 사실처럼 공유하면 복구가 늦어지고 고객 신뢰도 흔들립니다.
플레이북은 조사 순서를, 런북은 실행 절차를 담는다
플레이북은 ‘이 증상이 보이면 무엇을 확인할까’를 안내합니다. 런북은 ‘이 상황에서 캐시를 비우거나 작업을 중지하는 방법’을 구체적으로 적습니다. AWS의 운영 플레이북 지침은 조사 단계, 필요한 도구와 권한, 이해관계자 소통 계획을 명확히 하도록 설명합니다.
작은 팀이라면 문서 한 장으로 시작해도 됩니다. 확인할 대시보드, 최근 배포와 외부 연동 상태, 담당자 연락처, 고객 공지 위치, 되돌리기 조건을 적습니다. 중요한 것은 평소에 열어보고 실제로 실행 가능한지 확인하는 일입니다. 존재만 하는 문서는 사고 순간 도움이 되지 않습니다.
복구 중에는 역할과 의사결정권을 분리한다
대응 책임자는 우선순위와 복구 방향을 정하고, 조사 담당자는 증거를 모으며, 소통 담당자는 고객과 내부 상태를 갱신합니다. 한 사람이 모두 맡아야 하는 작은 팀이라도 이 역할을 머릿속에서 구분하면 누락이 줄어듭니다. 변경을 멈출지, 배포를 되돌릴지, 일부 기능을 제한할지 결정할 사람도 분명해야 합니다.
가장 빠른 완벽한 원인 규명보다 피해 확산을 막는 조치가 먼저일 때가 많습니다. 다만 임시 조치가 증거를 지우거나 데이터 복구를 어렵게 만들 수 있으니, 실행 전 현재 상태를 기록합니다. 고객 공지는 원인을 단정하기보다 영향 범위, 현재 조치, 다음 업데이트 시점을 분명히 말하는 편이 낫습니다.
복구 선언은 고객 관점에서 확인한다
서버 메트릭이 정상으로 돌아와도 적체된 작업이 남거나 고객 화면이 여전히 실패할 수 있습니다. 핵심 사용자 여정의 실제 성공, 큐 적체, 실패한 요청의 재처리, 데이터 정합성을 확인한 뒤 복구를 선언합니다. 이후에도 일정 시간 재발 여부를 관찰합니다. ‘서비스 정상’과 ‘모든 후속 처리가 끝남’은 다를 수 있습니다.
사후 분석은 사람 평가가 아니라 시스템 개선이다
타임라인을 만들고, 탐지가 늦어진 이유, 영향이 커진 경로, 복구를 어렵게 한 제약을 찾습니다. AWS의 사후 분석 가이드도 개인 탓보다 기여 요인과 검증 가능한 개선 조치를 강조합니다. ‘주의하자’보다 ‘이 경우를 테스트에 추가하고 담당자와 기한을 지정한다’가 실행 가능한 결론입니다.
개선 항목은 즉시 차단책과 구조적 해결책으로 나눕니다. 예를 들어 재시도 폭주가 장애를 키웠다면 당장 제한값을 조정하고, 장기적으로는 부하 실험과 자동 차단 조건을 보완합니다. 조치 완료 여부를 다음 회고에서 확인해야 같은 장애가 다른 이름으로 반복되지 않습니다.
플레이북은 연습하면서 짧아진다
문서를 만들었다면 실제 장애 전에 작은 모의훈련을 해봅니다. 담당자가 대시보드에 접근할 수 있는지, 고객 공지 권한이 있는지, 되돌리기 명령이 최신 배포 방식과 맞는지 확인합니다. 훈련에서 막힌 단계는 개인의 숙련도 문제로만 남기지 않고 문서와 권한을 고칩니다. 실전에서 처음 여는 문서보다 연습 중 한 번이라도 사용한 문서가 훨씬 유용합니다.
장애 대응 기록은 길수록 좋은 것이 아닙니다. 시각, 사실, 가설, 실행한 조치, 결과, 다음 담당자만 일관되게 남겨도 교대가 가능합니다. 원인을 찾느라 고객 공지를 놓치지 않도록 상태 업데이트의 담당자와 간격도 미리 정합니다. 장애가 끝난 뒤에는 기록에서 실제로 도움이 된 단계와 불필요한 단계를 골라 플레이북을 고칩니다.
팀 체크리스트
- 고객 여정 기준으로 장애 선언 조건이 있는가?
- 사실·가설·조치·다음 업데이트 시각을 한곳에 기록하는가?
- 조사, 복구 결정, 고객 소통 담당이 정해지는가?
- 복구 후 실제 사용자 동작과 적체 작업을 확인하는가?
- 사후 분석의 각 조치에 담당자와 확인 기준이 있는가?
#장애대응 #인시던트관리 #플레이북 #런북 #포스트모템 #사후분석 #서비스복구 #고객공지 #운영체계 #재발방지
