본문 바로가기
Case Studies (실무)

운영 장애 처리 방법: “진상규명”은 나중에, “복구”가 먼저입니다

운영 중 장애는 개발자의 피할 수 없는 숙명에 가깝습니다.
중요한 건 “장애를 안 만나는 법”이 아니라, 장애가 났을 때 얼마나 빠르고 안정적으로 복구하느냐입니다.

특히 장애 대응에는 명확한 시간 제한(time constraint) 이 있습니다.
서비스는 지금도 사용자에게 사용되고 있고, 장애가 길어질수록 피해는 기하급수적으로 커집니다.
따라서 장애 상황에서는 “완벽한 원인 규명”을 욕심내기보다, 빠르게 복구할 수 있는 단서를 찾고 조치하는 것이 우선입니다.


장애 대응의 핵심 원칙

1) 장애 대응에는 시간이 제한되어 있음을 “명확히” 받아들입니다

장애 상황에서 가장 흔한 함정은 이겁니다.

  • “원인을 정확히 알아야 고칠 수 있다”
  • “근본 원인을 찾고 완벽히 이해한 뒤 조치하자”

이 사고방식이 실제로는 주객전도를 만들기 쉽습니다.
원인 파고들다가 복구가 늦어지고, 그 사이 고객 영향은 계속 누적됩니다.

장애 시점에서 우리가 필요한 건 Root Cause(근본 원인) 가 아니라, 대개 Recoverable Cause(복구 가능한 단서) 입니다.


2) 목표를 “진상규명”이 아니라 “서비스 안정화/복구”로 둡니다

장애 대응의 1차 목표는 단 하나입니다.

서비스를 정상 상태로 되돌리고(또는 피해를 최소화하고), 재발을 막을 학습을 남기는 것

장애 대응 중에는 보통 다음을 먼저 달성해야 합니다.

  • 영향 범위 축소 (blast radius 줄이기)
  • 사용자 피해 최소화
  • 시스템 안정화 (재발/확산 방지)
  • 정상화 확인(재발 모니터링)

원인 규명은 중요하지만, “장애 중”에 끝내야 할 일은 아닙니다.


3) 장애 중에는 “충분히 그럴듯한 가설”로 빠르게 움직입니다

장애 상황에서는 완벽한 확신보다, 빠른 가설-검증 루프가 훨씬 중요합니다.

  • 최근 배포/설정 변경이 있었는가?
  • 특정 기능/엔드포인트/테넌트에 국한되는가?
  • 에러율/지연/자원(CPU, Memory, DB connection) 중 무엇이 튀는가?
  • 롤백/우회/차단/스케일업으로 즉시 완화 가능한가?

“정답을 찾는 분석”보다, 복구 가능성을 높이는 단서 탐색이 먼저입니다.


추천하는 장애 대응 흐름 (3단계)

1단계: Stabilize (더 나빠지지 않게 막기)

  • 장애 확산을 막기 위한 조치(트래픽 차단, 기능 플래그 OFF, rate limit 강화 등)
  • 과부하/병목 완화(스케일 아웃, 큐 적체 해소, 캐시 전략 조정 등)

2단계: Restore (정상 상태로 복구)

  • 가장 비용 대비 효과가 큰 복구 수단부터 적용
    예) 롤백 → 우회(기능 비활성) → 핫픽스
  • “완전한 해결”이 아니라도, 사용자 영향이 크게 줄면 일단 성공입니다.

3단계: Learn (포스트모템으로 진상규명 + 재발 방지)

  • 장애 타임라인 정리
  • 근본 원인 및 기여 요인(contributing factors) 분석
  • 재발 방지 액션 아이템 도출(오너/기한 포함)

왜 포스트모템이 반드시 필요한가

장애 중에 무리하게 진상규명을 하면 복구가 늦어집니다.
그렇다고 “복구만 하고 끝”이면 같은 장애가 반복됩니다.

그래서 올바른 방향은 이겁니다.

  1. 장애 시점에는 빠르게 단서를 찾아 조치하고
  2. 장애 이후 포스트모템에서 근본 원인과 재발 방지를 끝까지 해내는 것

포스트모템이 잘 되면 다음이 달라집니다.

  • 탐지(Detect) 시간 단축
  • 진단(Triage) 시간 단축
  • 복구(Recover) 수단이 런북/자동화로 축적
  • 결국 MTTR(평균 복구 시간)이 내려감

장애 대응에서 자주 하는 실수 (피해야 할 것들)

  • 장애 중에 로그/지표를 끝까지 파고들며 “확실한 원인”을 찾느라 조치가 늦어짐
  • 커뮤니케이션이 늦어져, 고객/내부 이해관계자의 불확실성이 커짐
  • 임시 조치 후 정상화 확인(모니터링/재발 관찰)을 생략함
  • 포스트모템을 “회고 문서”로만 끝내고, 재발 방지 액션이 실행되지 않음

정리: 장애는 ‘복구 → 학습’ 순서로 이기는 게임입니다

운영 장애는 피할 수 없습니다.
하지만 대응 방식은 선택할 수 있습니다.

  • 장애 중에는 시간 제한을 인정하고,
  • 복구 가능한 단서를 빠르게 찾아 처리하며,
  • 진짜 진상규명과 재발 방지는 포스트모템에서 끝까지 가져가는 것.

이 순서를 지키면 장애 대응은 점점 더 빨라지고, 시스템은 더 단단해집니다.