근본 원인 분석

불을 끄는 일과 다시 나지 않게 하는 일은 다른 작업입니다. 그런데 복구가 끝나면 사람들은 이미 지쳐 있고 밀린 일이 기다리고 있어서, 무엇을 고쳐야 하는지 정하지 않은 채 그 사고가 닫히는 일이 흔합니다.

페이지덱에서 저장이 안 되는 장애가 났을 때가 그랬습니다. 태오가 서버를 다시 띄워 20분 만에 복구하고 기록에는 메모리 부족이라고 적었습니다. 2주 뒤 같은 장애가 다시 났고, 이번에는 한 시간이 걸렸습니다. 첫 번째 기록에 적힌 것은 원인이 아니라 증상의 마지막 단계였습니다. 메모리가 왜 부족했는지, 그 상황이 왜 그날 처음 생겼는지는 아무도 묻지 않았습니다.

같은 사고가 두 번 나면 손해는 두 배가 아니라 그 이상입니다. 사용자는 두 번째에 신뢰를 잃고, 팀은 같은 장애에 두 번 사람을 씁니다. 복구와 별개의 작업으로 원인을 파고드는 자리를 따로 둔 이유가 여기 있습니다.

시간표를 먼저 만들고, 증상에서 출발해 우리가 바꿀 수 있는 조건에 닿을 때까지 왜를 반복합니다.

1. 사실만으로 시간표를 적습니다. 몇 시 몇 분에 무엇이 일어났는지를 줄로 늘어놓고, 그 옆에 같은 시각의 배포와 설정 변경과 트래픽 변화를 함께 놓습니다. 원인 후보는 대개 이 두 줄이 만나는 자리에서 나옵니다.
2. 증상에서 시작해 왜를 이어 붙입니다. 페이지덱의 경우는 이렇게 이어졌습니다. 저장이 실패했다, 서버 메모리가 모자랐다, 한 요청이 문서 전체를 메모리에 올렸다, 문서 크기에 상한이 없었다, 상한을 정하는 항목이 설계 검토 목록에 없었다.
3. 멈추는 자리를 정합니다. 우리가 바꿀 수 있는 조건에 닿으면 거기서 멈춥니다. 위의 예에서는 검토 목록에 항목을 더하는 것과 문서 크기에 상한을 두는 것이 그 자리입니다. 반대로 "개발자가 확인하지 않았다" 는 더 파고들 자리이지 멈출 자리가 아닙니다. 확인을 빠뜨려도 통과되는 구조가 원인입니다.
4. 원인을 하나로 좁히지 않습니다. 사고는 대개 여러 조건이 같은 날 겹쳐서 납니다. 문서 크기 상한이 없었고, 경고 기준이 실제 한계보다 높게 잡혀 있었고, 그날 마침 300쪽짜리 문서를 올린 고객이 있었다면 셋 다 적습니다. 하나만 고치면 다음에는 다른 모습으로 같은 사고가 옵니다.
5. 재발 방지 항목에 담당과 기한을 붙입니다. 항목이 문장으로만 남으면 반년 뒤에도 그대로 남아 있습니다. 문서 크기 상한을 태오가 이번 주까지, 경고 기준 조정을 다음 주까지 같은 형태로 적어 작업 목록에 넣습니다.
6. 막혔는지 확인합니다. 같은 조건을 시험 환경에서 만들어 보고 이번에는 막히는지 봅니다. 300쪽짜리 문서를 올려 상한에 걸리는지 보는 식입니다. 확인하지 않은 조치는 조치했다는 기록일 뿐입니다.

영향이 컸던 인시던트와 두 번 이상 반복된 사고에 씁니다. 반복이 신호인 이유는 첫 번째 분석이 증상에서 멈췄다는 뜻이기 때문입니다. 원인이 처음부터 분명한 사고, 예를 들어 설정 한 줄을 잘못 고쳐 3분 만에 되돌린 경우에는 이 작업을 따로 돌리지 않습니다.

한계는 넷입니다.

1. 불이 붙은 동안에는 할 수 없습니다. 복구가 먼저이고 이 작업은 그 뒤입니다. 두 일을 같은 자리에서 하려 하면 복구가 늦어집니다. 대신 복구하는 동안 기록을 남겨 두면 다음 날 시간표를 만드는 일이 훨씬 쉬워집니다.
2. 사람을 탓하는 자리가 되면 사실이 나오지 않습니다. 누가 무엇을 눌렀는지가 추궁으로 돌아오는 팀에서는 기록이 조심스럽게 적히고, 조심스럽게 적힌 기록으로는 구조를 찾을 수 없습니다. 이 태도를 따로 책임 추궁 없는 회고라고 부릅니다.
3. 원인이 하나라는 전제가 틀릴 때가 많습니다. 시스템이 여러 겹으로 되어 있을수록 사고는 방어선 여럿이 동시에 뚫린 결과이고, 그때 하나를 근본 원인으로 지목하면 나머지 구멍이 남습니다.
4. 분석이 결과를 만들지는 않습니다. 재발을 막는 것은 5번에서 나온 항목이 실제로 실행됐을 때뿐입니다. 항목의 완료율을 함께 보지 않으면 분석 문서만 쌓입니다.

"메모리 부족은 증상이고 원인이 아닙니다. 왜 모자랐는지가 남아 있어요."

파고들기를 한 단계 더 하자는 말입니다.

"같은 장애가 2주 만에 또 났으니 지난번 분석이 증상에서 멈춘 겁니다."

반복을 분석이 얕았다는 신호로 읽는 것입니다.

"재발 방지 항목에 담당자와 기한을 붙여 주세요."

실행되지 않을 항목을 미리 걸러 내자는 요청입니다. 당번인 온콜에게 항목을 몰아 주지 말자는 뜻도 함께 담깁니다.

두 번째 장애 뒤에 태오와 지현이 한 시간 반 동안 시간표를 만들고 왜를 다섯 번 이어 붙였습니다. 나온 항목은 셋이었습니다. 문서 크기에 상한을 두는 것, 메모리 경고 기준을 실제 한계의 70퍼센트로 내리는 것, 설계 검토 목록에 크기 상한 항목을 더하는 것입니다. 셋 다 담당과 기한이 붙어 작업 목록에 들어갔고 3주 안에 끝났습니다. 같은 장애는 그 뒤로 나지 않았고, 대신 상한에 걸린 고객 문의가 두 건 들어와 상한값을 한 번 조정했습니다.

원인을 하나 찾아내는 작업이라고 읽는 경우가 가장 많습니다. 이름에 근본 원인이라는 단수 표현이 들어 있으니 자연스러운 오해입니다. 하지만 사고 하나에 조건이 하나뿐인 경우는 드뭅니다. 상한이 없었던 것과 경고가 늦었던 것과 그날 대용량 문서가 올라온 것이 겹쳐야 장애가 됩니다. 하나를 근본 원인으로 못 박고 닫으면 나머지 두 구멍이 그대로 남아, 다음에는 다른 순서로 같은 사고가 납니다.

분석을 문서로 남기는 것이 목적이라고 보는 것도 흔합니다. 양식이 정해져 있고 회의가 열리고 문서가 저장되니 일이 끝난 것처럼 보입니다. 실제로 재발을 막는 것은 문서가 아니라 그 문서에서 나온 항목입니다. 항목이 담당 없이 적혀 있거나 기한이 없거나 작업 목록에 들어가지 않았다면, 그 분석은 두 시간을 써서 아무것도 바꾸지 않은 회의입니다. 분석의 성과는 문서 수가 아니라 같은 사고가 다시 났는지로 확인합니다.