방금 프로덕션 웹사이트가 다운됐습니다. 어떻게 대응하시겠습니까?

Question

Accepted Answer

최우선 순위는 **서비스를 복구한 다음 원인을 찾는 것**입니다 — 진단보다 완화가 먼저입니다. 저라면 incident를 선언하고, 역할을 명확히 배정하며, 가장 빠르고 안전한 복구를 향해 몰아가면서 그 과정 내내 소통합니다.

## 먼저 안정화하기

- **incident를 선언하고** 단일 채널(워룸 / Slack 스레드)을 열어 조율이 흩어지지 않게 합니다.
- **역할 배정**: 의사결정을 내릴 **Incident Commander**, stakeholder에게 업데이트할 **comms 담당자**, 조사를 진행할 **responder**. Tech Lead로서 저는 엔지니어가 문제에 집중할 수 있도록 종종 IC를 맡습니다.
- **가장 빠르게 되돌릴 수 있는 수정을 시도합니다.** 배포가 장애와 연관되어 있다면, 먼저 **rollback**하고 질문은 나중에 합니다 — 옳은 것보다 사용자를 복구하는 게 우선입니다.

## 병렬로 진단하기

- **명백한 시그널**을 확인합니다: 대시보드, 에러율, 최근 배포, 인프라 변경, 트래픽 급증, 만료된 인증서.
- 가설을 세우고, 가장 비용이 적은 것부터 검증하며, **한 번에 다섯 가지를 바꾸지 않습니다** — 무엇이 효과가 있었는지 알 수 없게 됩니다.

## 지속적으로 소통하기

침묵은 패닉을 낳습니다. 새로운 소식이 없을 때조차 일정한 주기로 업데이트를 보냅니다:

```
[14:05] 조사 중 — 체크아웃 다운, 사용자 약 40% 영향. 다음 업데이트 14:20.
[14:20] 원인 파악: 잘못된 배포. 지금 rollback 중. 예상 10분.
[14:35] 서비스 복구됨. 모니터링 중. postmortem 예정.
```

## 복구 이후

- "나아 보인다"가 아니라 완전한 복구를 확인합니다.
- 며칠 내로 **blameless postmortem**을 진행합니다: 타임라인, 근본 원인, 무엇이 탐지/수정을 느리게 만들었는지, 그리고 **담당자가 명시된 구체적 액션 아이템**.
- 결과물은 비난할 사람이 아니라 시스템적 개선(더 나은 알림, 가드레일, rollback 자동화)입니다.

## 함정

- 사용자가 고통받는 동안 **완화 전에 디버깅하기**.
- **단일 의사결정자가 없어** 다섯 명이 동시에 추측하기.
- stakeholder에게 **침묵하기**.
- **개인을 비난하기** — 이는 미래 incident가 의존하는 정직함을 죽입니다.

## 왜 중요한가

장애는 불가피합니다; 그것을 어떻게 운영하느냐가 팀의 신뢰와 고객의 확신을 정의합니다. 침착하고 역할 기반의 조율과 blameless 후속 조치는 나쁜 하루를 더 강한 시스템으로 바꿔줍니다 — 그리고 실패가 마녀사냥이 아니라 프로세스로 다뤄지기에 빠르게 움직여도 안전하다는 신호를 엔지니어에게 줍니다.