최우선 순위는 서비스를 복구한 다음 원인을 찾는 것입니다 — 진단보다 완화가 먼저입니다. 저라면 incident를 선언하고, 역할을 명확히 배정하며, 가장 빠르고 안전한 복구를 향해 몰아가면서 그 과정 내내 소통합니다.
침묵은 패닉을 낳습니다. 새로운 소식이 없을 때조차 일정한 주기로 업데이트를 보냅니다:
[14:05] 조사 중 — 체크아웃 다운, 사용자 약 40% 영향. 다음 업데이트 14:20.
[14:20] 원인 파악: 잘못된 배포. 지금 rollback 중. 예상 10분.
[14:35] 서비스 복구됨. 모니터링 중. postmortem 예정.
장애는 불가피합니다; 그것을 어떻게 운영하느냐가 팀의 신뢰와 고객의 확신을 정의합니다. 침착하고 역할 기반의 조율과 blameless 후속 조치는 나쁜 하루를 더 강한 시스템으로 바꿔줍니다 — 그리고 실패가 마녀사냥이 아니라 프로세스로 다뤄지기에 빠르게 움직여도 안전하다는 신호를 엔지니어에게 줍니다.