포스트모템

장애가 복구되면 안도가 먼저 옵니다. 새벽에 깨어 있던 사람들은 잠을 자야 하고, 낮에는 미뤄 둔 일이 기다립니다. 그래서 대응이 끝난 자리에 남는 것은 대개 "복구 완료" 한 줄입니다.

태오가 새벽 3시에 데이터베이스 연결 수가 넘쳐 터진 장애를 복구한 날도 그랬습니다. 원인을 찾는 데 한 시간이 걸렸고, 그 한 시간 동안 알게 된 것이 여럿 있었습니다. 어느 지표를 봐야 이 상황이 보이는지, 어떤 명령으로 연결을 끊어야 하는지, 왜 알림이 늦게 왔는지였습니다. 그런데 그 내용은 태오 머릿속에만 남았습니다.

석 달 뒤 같은 원인으로 다시 터졌을 때 태오는 휴가 중이었습니다. 당번을 맡은 사람은 지난번과 같은 한 시간을 처음부터 다시 썼습니다. 지난번에 이미 알아낸 것을 아무도 꺼낼 수 없었기 때문입니다. 장애가 두 번 난 것이 아니라, 배움을 한 번도 저장하지 않은 것이 문제였습니다.

이름은 의료에서 왔습니다. 사망 원인을 밝히려고 시신을 열어 보는 절차를 가리키는 말인데, 소프트웨어에서는 목적이 조금 다릅니다. 같은 일이 다음에 일어나지 않게 하려고 여는 것입니다.

문서 하나가 장애 하나를 맡습니다. 항목은 팀마다 다르지만 빠지면 문서가 제 몫을 못 하는 것이 일곱 개입니다.

1. 요약 — 무엇이 언제부터 언제까지 어떻게 됐는지를 다섯 줄 안에 적습니다. 바쁜 사람은 이 부분만 읽습니다.
2. 영향 범위 — 느낌이 아니라 숫자로 적습니다. "많은 고객이 불편을 겪었다" 가 아니라 "42분 동안 문서 저장 요청의 18퍼센트가 실패했고 유료 팀 230곳이 영향을 받았다" 입니다.
3. 타임라인 — 시각과 사실만 줄줄이 적습니다. 문제가 시작된 시각과 팀이 알아챈 시각을 따로 적습니다. 두 시각의 간격이 곧 감지가 늦은 정도입니다.
4. 촉발 원인 — 무엇이 이 일을 시작시켰는지입니다. 배포, 설정 변경, 트래픽 증가, 외부 서비스 장애 중 하나가 대개 여기 옵니다.
5. 근본 원인 — 촉발 원인이 왜 장애로 이어졌는지입니다. 배포 자체는 정상이었는데 연결 수 상한이 낮게 잡혀 있었다는 식으로, 한 단계 아래의 조건을 적습니다.
6. 대응 과정 평가 — 빠르게 도움이 된 것과 시간을 잡아먹은 것을 함께 적습니다. 대시보드가 있어서 3분 만에 범위를 알았다는 것도, 복구 명령을 아는 사람이 한 명뿐이라 20분을 기다렸다는 것도 남깁니다.
7. 재발 방지 항목 — 담당자와 기한이 붙은 실행 항목입니다. 담당자 없는 문장은 아무도 하지 않습니다.

7번이 문서의 값을 정합니다. 앞의 여섯이 잘 적혀 있어도 마지막이 "모니터링을 강화한다" 같은 문장이면 다음 장애는 그대로 옵니다. "연결 수가 80퍼센트를 넘으면 알림이 오게 한다, 태오, 이번 주" 처럼 적습니다. 알림은 정해진 조건을 넘으면 담당자에게 알려 주는 장치를 말합니다.

쓰는 사람은 대응에 참여한 사람 중 한 명입니다. 대개 그 자리를 이끈 사람이 맡지만 혼자 쓰지는 않습니다. 타임라인은 참여자 전원이 자기가 무엇을 언제 했는지 채워야 맞게 만들어집니다. 기억은 몇 시간만 지나도 순서가 섞입니다.

시점은 빠를수록 좋습니다. 복구 뒤 이틀 안에 초안을 만들고 한 주 안에 확정하는 팀이 많습니다. 미루면 채팅 기록을 다시 훑어야 하고, 재발 방지 항목이 다음 분기 계획에 들어갈 기회를 놓칩니다.

읽는 사람은 넷입니다.

1. 그 팀 — 재발 방지 항목을 실제로 하는 사람들입니다.
2. 다른 팀 — 같은 구조를 쓰고 있으면 같은 장애를 기다리고 있는 셈입니다.
3. 나중의 온콜 당번 — 온콜은 정해진 시간에 장애 연락을 받기로 한 당번입니다. 비슷한 증상을 만났을 때 지난 문서가 있으면 한 시간을 줄입니다.
4. 고객과 경영진 — 원인과 조치를 요약한 공개판을 따로 내기도 합니다. 기업 고객은 계약에 따라 이걸 요구합니다.

이 문서가 읽히려면 사람을 탓하지 않는다는 약속이 먼저 있어야 합니다. 책임 추궁 없는 회고가 그 약속이고, 없으면 타임라인이 방어 문장으로 채워집니다. 잘못 누른 사람을 찾는 문서가 되면 다음 장애에서 아무도 자기가 무엇을 했는지 적지 않습니다.

"포스트모템은 제가 쓰고 타임라인은 참여한 분들이 채워 주세요."

기억이 흩어지기 전에 각자 자기 몫을 적어 달라는 요청입니다.

"액션 아이템에 담당자가 없어요. 이러면 다음 달에도 그대로입니다."

실행 항목이 문장으로만 남아 있다는 지적입니다.

"이건 인시던트가 아니라 버그예요. 포스트모템까지 쓸 건 아닙니다."

서비스에 영향이 없었으니 문서를 남길 사안이 아니라는 뜻입니다.

페이지덱은 심각도가 높은 장애에만 이 문서를 씁니다. 태오가 첫 문서를 쓸 때 가장 오래 걸린 항목은 타임라인이었습니다. 채팅 기록에는 대응이 남아 있었지만 각자 무엇을 보고 그렇게 판단했는지는 없었습니다. 그래서 그다음부터는 대응 중에 한 사람이 시각과 판단을 그 자리에서 적기로 정했습니다.

규원이 문서를 읽고 물은 것은 원인이 아니라 감지 시간이었습니다. 문제가 시작된 시각과 알아챈 시각 사이가 38분이었고, 그 38분 동안 고객 문의가 먼저 들어왔습니다. 고객이 알려 주기 전에 알았어야 한다는 것이 그 회차의 가장 큰 항목이 됐습니다.

책임자를 찾는 문서로 읽는 경우가 가장 많습니다. 원인을 적는 칸이 있으니 그 칸에 사람 이름이 들어갈 것처럼 보입니다. 하지만 사람 이름을 적으면 문서가 멈춥니다. 잘못 누를 수 있는 화면을 그대로 두고 누른 사람을 적어 둔 문서는 다음에 다른 사람이 같은 것을 누르는 것을 막지 못합니다. 적어야 하는 것은 확인 절차 없이 운영 데이터를 지울 수 있었다는 조건입니다.

큰 장애에만 쓰는 문서라고 보는 것도 흔합니다. 실제로 심각도 기준을 두고 그 위만 쓰는 팀이 많으니 절반은 맞습니다. 다만 기준을 너무 높게 잡으면 문제가 됩니다. 5분 만에 복구된 장애가 석 달 동안 여섯 번 반복되고 있는데 한 번도 기록되지 않는 상황이 생깁니다. 같은 증상이 세 번 이상 반복되면 크기와 무관하게 한 번 쓰기로 정해 두는 팀이 있습니다.