운영자가 듣고 싶지 않은 질문 3개

그 질문이 나오는 순간

장애 직후 슬랙이 조용해진다. 그 침묵이 제일 무섭다.

누군가 조심스럽게 타이핑을 시작한다. 운영자는 그 말풍선 점이 올라오는 걸 보면서 이미 안다. “이번에 담당자가 누구예요?”

세 질문 다 비슷한 타이밍에 온다. 사건 직후, 온도가 가장 높을 때.

막상 이 말을 들으면 등이 서늘하다. 백업 스크립트는 분명 있다. 문제는 그게 실제로 복원되는지 아무도 테스트하지 않았다는 것.

올해 초 DB 마이그레이션 실수로 테이블 하나가 날아갔다. 팀 전체가 S3 버킷을 뒤졌고, 30분 만에 스냅숏을 찾았는데, 막상 restore 해보니 덤프 형식이 달라서 psql 이 그냥 에러를 뱉었다. 결국 수동으로 INSERT 를 돌려야 했고 2시간짜리 공백이 생겼다. 백업은 있었고, 복원은 안 됐다.
그 이후로 매달 15일에 restore drill 을 스테이징에서 돌리기로 했다. 실제로 2번은 했다. 3번째 달에 다른 이슈가 겹쳐서 건너뛰었고, 지금 그 드릴이 몇 달째 밀려 있다. 이게 “변하지 못한 것” 목록에서 계속 자리를 지키는 이유다.
README 에 “백업 담당: @mings, 복원 검증: @팀원B” 라고 적어뒀더니 적어도 서로 떠넘기는 시간은 줄었다. 담당자 이름이 명시되면 질문의 방향이 달라진다. “있어요?” 에서 “됐어요?” 로.

백업이 있다는 것과, 쓸 수 있다는 것은 다른 이야기다.

이 질문은 두 번 째 화살이다. 첫 번째 화살은 장애 자체고.

모니터링은 붙어 있었다. CPU 알림, 5xx 알림, latency 알림. 근데 이번에 터진 건 외부 서비스 timeout 이었다. 우리 서버는 200을 잘 뱉었고, 유저는 빈 화면을 봤다.

외부 API 응답 시간을 우리가 측정하지 않았다. 서비스가 “살아있음” 과 “제대로 응답함” 은 다른 상태인데, 전자만 감시하고 있었다. synthetic monitoring 을 붙인 건 그 사건 이후였다. 3분 간격으로 실제 사용자 흐름을 재현하는 스크립트를 Playwright 로 짜서 Grafana 에 물렸다.
알림 채널 분산도 문제였다. PagerDuty 로 오는 것, 슬랙 #ops 로 오는 것, 이메일로 오는 것이 각자 달랐고, 야간 당직 때 PagerDuty 만 폰에 들어오는 설정이었는데, 정작 그날 장애는 슬랙 봇이 떨어진 탓에 #ops 알림이 소리 없이 쌓이고 있었다. 알림 시스템 자체가 장애나면 알림이 안 온다. 당연한 말인데 직접 겪기 전까지는 체감이 안 된다.
지금은 알림 헬스 체크를 별도로 뒀다. 5분마다 테스트 페이로드를 PagerDuty 에 날리고, 그게 안 오면 SMS 로 fallback. 이걸 처음 설정했을 때 바로 다음날 PagerDuty 설정이 꼬여 있다는 걸 발견했다. 아무도 몰랐다.

제일 듣기 싫은 질문이다. 왜냐하면 보통 답이 “저요” 이거나 “아무도요” 이기 때문이다.

둘 다 나쁘다. 전자는 책임 소재가 명확하고, 후자는 조직 구조가 명확하지 않다는 뜻이다.

배포 롤백 판단을 주니어 혼자 내린 사건이 있었다. 본인이 최선이라 판단해서 한 거고, 결과적으로 맞기도 했다. 근데 왜 그게 문제냐면, 그 판단이 맞았을 때 아무도 기록을 남기지 않았고, 틀렸을 때를 대비한 에스컬레이션 경로도 없었기 때문이다. 우연히 잘 끝났을 뿐이고, 다음번에 그게 보장되지 않는다.
런북에 “이 상황에서는 @시니어 에게 먼저 ping” 이라고 한 줄 박은 것만으로 에스컬레이션 빈도가 눈에 띄게 달라졌다. 명시적인 허락이 있으면 사람들은 실제로 묻는다.
의사결정 로그를 별도로 쓰기 시작했다. 장애 대응 중에 Notion 페이지 하나 열어두고, 누가 언제 무슨 판단을 내렸는지 타임라인으로 남긴다. 24시간 안에 사후 보고서 쓰기는 아직도 못 하지만, 이 로그라도 있으면 재구성이 훨씬 빠르다. 없을 때는 슬랙 스크롤을 두 시간씩 올려다봤다.

세 질문에는 공통점이 있다. 전부 “미리 물었으면 방어할 수 있었던” 것들이다.

복원 테스트, 알림 헬스 체크, 에스컬레이션 경로. 전부 사건이 나기 전에 점검 가능하다. 근데 평소에는 아무도 이 질문을 안 한다. 불편하고, 찾아보면 허점이 나올 것 같아서.

막상 해보면 허점은 항상 있다. 찾기 전에 터지느냐, 찾고 나서 막느냐의 차이다.

운영 리뷰 때 이 세 가지를 정기 질문 목록에 넣었다. 매달 한 번, 누가 발표하는 것도 아니고 그냥 세 가지를 소리 내서 물어보는 것만으로 분위기가 바뀌었다.

다음 달 리뷰 때, restore drill 을 실제로 돌리고 그 결과를 한 줄이라도 적을 것. 말만 한 게 몇 달째다.

🛒 이 글과 어울리는 추천 상품

위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.