비난 없는 포스트모템
한 줄 요약
포스트모템의 목적은 같은 사고가 다시 나지 않게 하는 것이고, 그 약속은 조치 항목이 지킵니다. 그래서 좋은 포스트모템은 사람이 아니라 시스템을 원인으로 적고, 모든 주장을 실제 기록의 줄로 뒷받침하고, 모든 조치에 「지금은 실패하고 고치면 통과하는」 검증 명령을 붙입니다.
왜 이게 필요했나
Google SRE 책 15장(Postmortem Culture)은 비난 없는 포스트모템을 강조합니다. 이유는 단순합니다. 사람을 원인으로 적으면 다음 사고 때 아무도 사실을 말하지 않고, 사실이 없으면 원인을 못 찾습니다. 「배포한 사람이 실수했다」 는 문장은 아무것도 고치지 않습니다 — 그 실수를 가능하게 만든 시스템(설정 검토가 없는 배포, 꺼져 있는 건강 검사, 늦게 울리는 경보)은 그대로 남습니다.
더 조용한 실패도 있습니다. 조치 항목이 「완료」 로 닫혔는데 같은 사고가 다시 나는 것입니다. 열어 보면 검증이 「키가 있는지」
만 봤거나, 실패를 || true 로 덮었거나, 서비스가 읽지 않는 옛 사본을 검사하고 있습니다. 검증이 결함을 잡지 못하면 그 조치는
완료된 적이 없습니다.
어떻게 동작하나
원인을 나눕니다. 촉발(trigger)은 사고를 시작시킨 변경 — 대개 배포 하나입니다. 근본 원인(root cause)은 그 변경이 만든, 없었다면 사고가 없었을 결함입니다. 예를 들어 배포 v3.2.0 이 촉발이고, 그 배포가 커넥션 풀을 64 에서 5 로 줄인 것이 근본 원인입니다. 배포를 되돌리면 사고는 멈추지만, 「풀 크기가 검토 없이 바뀔 수 있다」 는 근본 원인은 남습니다. 조치는 근본 원인과 기여 요인에 겁니다. 기여 요인(contributing factor)은 원래부터 있던 결함으로, 사고를 늦게 알아채게 하거나(높은 경보 기준), 막지 못하게 하거나(꺼진 건강 검사), 키운(대기 없는 재시도) 것들입니다. 셋을 섞으면 조치가 엉뚱한 곳에 갑니다.
증거는 줄로 붙입니다. 「첫 오류는 06:24 쯤」 이 아니라 로그의 그 줄을 그대로 붙입니다. 누구든 같은 줄을 다시 찾아 확인할 수 있어야 하고, 그럴듯하게 지어 쓴 줄은 검증에서 걸립니다.
조치는 세 가지를 가집니다. 주인(사람이 아니라 팀), 무엇을 바꾸는지, 그리고 검증 명령. 검증은 세 성질을 가져야 합니다.
| 성질 | 의미 | 흔한 가짜 |
|---|---|---|
| 지금 실패한다 | 결함이 남아 있음을 잡는다 | 키 존재만 보기, ` |
| 고치면 통과한다 | 올바른 다른 고침도 받는다 | 값 하나를 못박은 grep -x |
| 자기 요인에 민감하다 | 남의 결함이 아니라 자기 것을 본다 | 비슷한 다른 키·옛 사본 검사 |
검증은 대상 트리를 인자($ROOT)로 받게 쓰면 운영 설정에도, 사고 당시 사본에도, 고친 사본에도 똑같이 돌려 볼 수 있습니다.
조치 항목 하나는 이렇게 생깁니다(예시의 키와 기준은 형식만 보여 줍니다).
action: 세션 저장소 연결 수를 팀 기준 이상으로
owner: platform-team
factor: example-too-small
verify: awk -F= '$1=="max_sessions" {v=$2} END {exit !(v != "" && v+0 >= 100)}' "$ROOT/etc/session.conf"
awk -F= 는 key=value 을 둘로 나누고, 같은 키가 여러 번 나오면 마지막 값이 남게 v 를 덮어씁니다 — 서비스가 설정을 읽는
방식과 같습니다. END 에서 기준과 비교해 종료 코드로 답하므로, 파이프 뒤에 붙이거나 || echo 로 감싸지만 않으면 그
결과가 그대로 검증 결과가 됩니다. 이 한 줄을 ROOT=<incident-copy>, ROOT=<fixed-copy> 으로 각각 돌려 보면 검증이
정직한지 몇 초 만에 알 수 있습니다.
현장에서 만나는 모습
분기 검토 회의에서 조치 목록이 전부 초록인데 같은 사고가 또 납니다. 열어 보면 조치 셋의 검증이 각각 다른 방식으로 거짓말을 하고 있습니다. 고치는 순서는 늘 같습니다 — 먼저 검증을 고쳐 지금 실패하게 만들어 결함이 남아 있다는 사실을 드러내고, 그 다음 시스템을 실제로 고쳐 검증이 정직하게 통과하게 합니다. 검증부터 고치지 않으면 시스템을 고쳤는지조차 알 수 없습니다.
비난 없는 글쓰기도 연습이 필요합니다. 「A 가 설정을 잘못 넣었다」 를 「설정 변경이 검토와 건강 검사 없이 운영에 들어갈 수 있었다」 로 바꾸면, 문장이 가리키는 고칠 곳이 사람에서 파이프라인으로 옮겨 갑니다. 타임라인에는 사람의 행동이 남아도 됩니다 — 다만 그것은 「그 사람이 그 순간 가진 정보로 왜 그렇게 판단했는가」 를 이해하려는 기록이지 원인이 아닙니다.
다음 실습에서 할 것
결제 장애의 로그·배포 기록·경보로 촉발 배포와 타임라인의 세 기둥을 실제 줄로 찾고, 근본 원인과 기여 요인을 가르고, 조치마다 검증 명령을 씁니다. 채점기가 그 명령을 사고 당시 사본·고친 사본 두 벌·요인 하나만 남긴 사본에 실제로 돌려 봅니다. 사람 이름 없는 포스트모템을 쓰고, 운영 설정을 실제로 고친 뒤, 「검증 통과」 인데 같은 장애가 난 지난 분기 조치를 바로잡습니다.