사후 분석

사후 분석은 사고가 끝난 뒤에 무엇이 왜 일어났는지 적어 두고, 같은 사고가 다시 안 나게 조치를 정하는 절차입니다. 시스템이 정상으로 돌아오고 나서 여는, 사고 대응의 마지막 단계입니다.

쉽고 빠른 이해

사후 분석은 사고가 끝난 뒤 무엇이 왜 일어났는지 적고, 다시 안 일어나게 조치를 정하는 일입니다. 데이터베이스가 새벽에 두 시간 멎었던 사고를 글로 남기는 것이 그런 예입니다.

이게 없으면 사고가 지나가고 나면 원인을 아무도 다시 들여다보지 않습니다. 몇 달 뒤 같은 원인으로 사고가 또 납니다.

어떻게 도는가:

대가는 글을 쓰고 회의를 여는 시간입니다. 원인을 사람의 실수로 적으면 다음부터 사람들이 사실대로 알리지 않고 감추게 됩니다.

사고마다 매번 열지는 않습니다. 사용자에게 드러나지 않은 작은 사고까지 쓰면 시간만 들고 새로 배울 것도 적어, 심각도가 일정 기준을 넘거나 사용자에게 드러난 사고에만 엽니다.

상세

이 절은 사후 분석이 언제 시작되는지부터 봅니다. 그다음 문서에 담기는 내용과 쓰는 절차를 보고, 원인을 사람에게서 찾지 않는 이유와 언제 여는지로 마칩니다.

사고가 났을 때 원인을 찾아 시스템을 정상으로 되돌리는 활동을 사고 대응이라고 부릅니다. 사후 분석은 그 활동의 한 단계가 아니라 활동이 끝난 다음에 여는 마지막 구간입니다. 영어로는 postmortem(포스트모템)이라고 부릅니다.

시스템이 이미 정상으로 돌아온 뒤에 쓰는 글이라, 사후 분석 자체는 사고를 고치는 일을 하지 않습니다. 대신 그 사고에서 무엇을 배웠는지를 남겨, 같은 원인이 다시 사고를 내지 않게 합니다.

사후 분석 문서 하나에는 대개 네 가지가 들어갑니다.

항목	담는 내용
시간대별 경과	언제 무엇을 알아챘고 언제 무엇을 했는지, 일어난 순서대로
영향 범위	어떤 기능이 얼마 동안 어떤 사용자에게 어떻게 나빠졌는지
근본 원인	겉으로 보인 증상 말고 그 밑에 있던 원인
조치 항목	재발을 막거나 더 빨리 알아채게 할 일. 담당자와 기한을 같이 적습니다

이 넷 중 근본 원인이 제일 어렵습니다. 겉으로 드러난 것은 대개 증상이지 원인이 아니기 때문입니다. "디스크가 가득 찼다"는 증상이고, "오래된 로그를 지우는 배치가 두 달 전부터 멎어 있었다"가 원인에 더 가깝습니다.

글을 쓰고 검토하는 절차는 대개 다섯 단계로 갑니다.

flowchart TD
    A["사고 대응이 끝난다"] --> B["담당자가 초안을 쓴다"]
    B --> C["관련된 사람이 모여 검토한다"]
    C --> D["조치 항목에 담당자·기한을 붙인다"]
    D --> E["끝날 때까지 추적한다"]

담당자 한 명이 초안을 다 채우지는 않습니다. 검토 회의에서 다른 사람의 기억과 기록을 더해 빈 곳을 채웁니다. 조치 항목을 추적하는 마지막 단계가 없으면 사후 분석은 회의로 끝나는 절차가 됩니다.

사후 분석 중에는 사람을 탓하지 않고 쓰는 방식이 있습니다. 영어로는 blameless postmortem(비난 없는 사후 분석)이라고 부릅니다.

원인을 사람의 실수로 적으면, 같은 상황을 다음에 먼저 보는 사람이 그 사실을 알리는 대신 감춥니다. 자기도 같은 일을 겪을까 봐서입니다. 원인을 시스템과 절차에서 찾으면, 그 사람은 감출 이유가 없어 알아챈 것을 그대로 알립니다.

이 방식을 쓰려면 조직이 실수를 처벌로 잇지 않기로 미리 정해 둬야 합니다. 그 약속이 없으면 사후 분석의 이름만 비난 없는 사후 분석이고, 사람들은 여전히 감춥니다.

사고마다 매번 열지는 않습니다. 사용자에게 드러나지 않은 작은 사고까지 쓰면 시간만 들고 새로 배울 것도 적습니다. 그래서 대개 심각도가 일정 기준을 넘었거나 사용자에게 드러난 사고에만 엽니다.