포스트모템은 열기는 쉽고 쓸모 있게 만들기는 어렵습니다. 회의가 열리고, 문서가 작성되고, 액션 아이템 네 개가 기록되고, 그리고 여섯 달 뒤에 똑같은 장애가 다시 일어납니다. 그 무렵 누군가가 전혀 다른 것을 찾다가 그 오래된 문서를 우연히 발견하게 됩니다.

이 주제를 이야기할 때 관심은 대부분 무비난이라는 단어에 쏠립니다. 그 원칙은 실제로 중요하지만, 실패가 일어나는 지점은 거기가 아닙니다. 아주 철저하게 무비난 원칙을 지키면서도 아무것도 바꾸지 못하는 회고를 돌리는 조직이 대단히 많습니다. 회고 자체를 결과물로 취급했고, 결과물을 만들어 내는 수단으로 취급하지 않았기 때문입니다.

여러분의 회고가 작동하는지 판별하는 시험은 민망할 만큼 단순합니다. 지난 여섯 달 동안 나온 액션 아이템 가운데 실제로 완료된 비율은 얼마입니까? 대부분이라는 답이 나온다면, 겉모습이 어떻든 그 프로세스는 작동하고 있습니다. 절반에 못 미친다면 프로세스를 운영하는 것이 아니라 회의를 여는 것이며, 더 좋은 템플릿을 붙여도 고쳐지지 않습니다. 담당자와 기한이 붙은 적은 수의 항목이, 아무도 시간을 낼 수 없는 꼼꼼한 목록보다 낫습니다.

포스트모템은 실제로 무엇을 위한 것인가

무슨 일이 있었는지 설명하기 위한 자리가 아닙니다. 그 자리에 있던 사람들은 장애가 끝날 무렵이면 대개 이미 알고 있습니다.

포스트모템이 존재하는 이유는 작은 문제가 큰 문제로 번지도록 허용한 조건들을 찾아내고, 그중 몇 가지를 바꾸기 위해서입니다. 이것은 무엇이 고장 났는가와는 다른 질문이며, 그 차이는 문서를 쓰기 시작하는 순간 곧바로 드러납니다. “데이터베이스 커넥션이 고갈되었다"는 무엇이 고장 났는지를 말합니다. “커넥션 풀 포화에 대해 아무 알림도 울리지 않았고, 그것을 보여 줬을 대시보드는 온콜 런북에 들어 있지 않다"는 조건을 말하며, 조건은 손댈 수 있습니다.

두 번째로 만들어지는 산출물은 늘 과소평가되는데, 사건에 대한 공유된 서술입니다. 그것이 없으면 각자가 자기 버전을 간직하고, 그 버전들은 각자가 시스템에 대해 원래부터 믿고 있던 방향으로 흘러갑니다. 그리고 일 년 뒤에는 함께 겪은 하나의 장애를 두고 두 팀이 서로 다른 이야기를 하며 다투게 됩니다.

무비난은 아주 구체적인 뜻이다

아무도 실수하지 않았다는 뜻이 아닙니다. 주어진 정보를 바탕으로 합리적으로 행동한 사람이 결과적으로 잘못된 조치를 취했다고 전제하고, 그 조치가 그 시점에 왜 옳아 보였는지를 묻는다는 뜻입니다. 이 관행과 그에 따르는 실패 양상은 Google의 SRE 책에 자세히 정리되어 있습니다.

이것이 단순한 배려에 그치지 않는 이유는 비난이 정보를 파괴하기 때문입니다. 장애가 개인에게 달라붙는 조직에서 사람들은 사건을 조심스럽게 기술하고, 불리해 보이는 세부 사항을 빼고, 안전하게 설명할 수 있을 만큼 이해하게 될 때까지 보고를 미룹니다. 그러면 회고는 자기 보호를 위해 편집된 서술을 재료로 삼게 되는데, 이것은 가능한 입력 중 최악입니다.

실무에서 무비난은 언어의 속성입니다. “왜 서비스를 재시작했나요?“라는 질문은 방어를 부릅니다. “재시작을 결정할 때 대시보드에 무엇이 보였나요?“라는 질문은 정보를 부릅니다. 두 번째 질문이 더 유용하기도 한데, 그 답이 동료에 대한 사실이 아니라 여러분의 모니터링에 대한 사실이기 때문입니다.

개인의 성과에 실제로 문제가 있다면 그것은 따로, 그리고 직접 다루십시오. 장애 회고 안에서 처리하면 회고가 망가지고, 어차피 그런 대화를 나누기에 좋은 자리도 아닙니다.

배움을 주는 타임라인 만들기

타임라인은 문서에서 가장 값진 부분이면서 가장 자주 잘못 쓰이는 부분이기도 합니다. 사람이 빠진 기술적 사건의 나열로 적히기 때문입니다.

사람들이 무엇을 알고 있었고 언제 알았는지를 함께 적으십시오. “14:32에 서비스를 재시작했다"만이 아니라, 그 사람이 14:32에 무엇을 볼 수 있었고 무슨 일이 벌어지고 있다고 믿었는지까지 적어야 합니다. 손댈 수 있는 재료가 바로 거기에 있습니다. 모호한 대시보드 때문에 생긴 십오 분의 지연은 고칠 수 있는 문제이지만, 그냥 공백으로만 기록된 십오 분의 지연은 고칠 수 없기 때문입니다.

의미가 있었던 순간들을 표시하십시오. 언제 시작되었는지, 누군가 처음 알아차린 때가 언제인지, 적임자가 언제 투입되었는지, 원인이 언제 파악되었는지, 언제 완화되었는지, 언제 해소되었는지를 적습니다. 개선의 여지는 그 사이의 간격에 살아 있으며, 탐지까지 걸린 시간이 그중 가장 큰 간격인 경우가 대단히 많습니다.

기억이 생생할 때, 이상적으로는 하루나 이틀 안에 쓰십시오. 특정 순간에 누가 무엇을 믿고 있었는지에 대한 기억은 무슨 일이 있었는지에 대한 기억보다 훨씬 빨리 흐려집니다.

단일 근본 원인은 거의 없다

이 표현은 그럴듯한 첫 설명에서 멈추도록 부추깁니다. 그러나 규모를 가리지 않고 장애는 여러 조건이 동시에 성립해야만 일어나는 사슬입니다.

쓸모 있는 회고는 대신 기여 요인을 나열합니다. 장애를 촉발한 변경, 그것을 잡아냈을 테지만 존재하지 않았던 테스트, 아무도 보지 않는 채널로 발송된 알림, 이전 아키텍처에 대해서는 정확했던 런북 같은 것들입니다. 각각이 별개의 기회이며, 사슬에서 우연히 맨 앞에 놓였던 것 대신 가장 값싼 두 가지를 고르는 선택이 가능해집니다.

이것은 흔한 왜곡도 줄여 줍니다. 회고가 단일 근본 원인을 지목할 때 그 원인은 아주 자주 “인적 오류"가 되는데, 이것은 설명이 아니라 서술이며, 조사가 시작되었어야 할 바로 그 지점에서 조사를 닫아 버립니다.

후속 조치를 실제로 굴러가게 하기

포스트모템의 생사가 갈리는 지점이며, 처방은 조금도 화려하지 않습니다.

항목을 줄이십시오. 완료되는 두 개가 완료되지 않는 여덟 개보다 낫습니다. 탐지 시간, 영향 범위, 재발 확률 가운데 무엇을 줄이는지로 순위를 매기고 나머지는 잘라 내십시오.

이름이 붙은 담당자와 기한을, 문서가 아니라 평소 쓰는 업무 트래커에 넣으십시오. 포스트모템 안에만 사는 항목은 계획 수립 시점에 보이지 않고, 일이 실제로 일정에 잡히는 때가 바로 그때입니다.

다음 포스트모템에서 미완료 항목을 점검하십시오. 이 습관 하나가 어떤 템플릿보다 큰 역할을 합니다. 끝내지 못한 일을 눈에 보이게 만들고, 연결되지 않은 회의의 나열을 하나의 프로세스로 바꿔 놓습니다.

일부 항목은 정직하게 받아들이십시오. 약속한 것의 절반을 꾸준히 해내는 팀이라면 약속을 절반으로 줄여야 합니다. 아무도 예산을 대지 않을 의도를 기록하는 것은 행동하지 않기로 한 결정을 기록하는 것보다 나쁩니다. 후자는 최소한 사실이기 때문입니다.

여기에서 나오는 개선은 대체로 저희 재해 복구 가이드와 소프트웨어 테스트 전략이 다루는 것과 같은 계열입니다. 더 빠른 탐지, 더 좁은 영향 범위, 그리고 최초 작성자가 아닌 사람도 운영할 수 있는 시스템입니다.

Mecanik은 서버 보안 분석 업무의 일부로, 저희가 유지 보수하는 시스템에서 장애 회고를 진행합니다. 대부분의 사례에서 반복되는 양상은 같습니다. 기술적 원인은 빠르게 파악되었고, 비싼 대가를 치른 쪽은 탐지가 늦어진 구간이었습니다.

자주 묻는 질문

포스트모템은 무엇을 위한 것입니까? 작은 문제가 큰 문제로 번지도록 허용한 조건을 찾아내고 그중 몇 가지를 바꾸기 위한 것이며, 이는 무엇이 고장 났는가와는 다른 질문입니다. 또한 사건에 대한 공유된 서술을 만들어 냅니다. 그것이 없으면 각자가 자기 버전을 간직하고, 그 버전은 원래 시스템에 대해 믿고 있던 방향으로 흘러갑니다.

무비난은 실제로 무슨 뜻입니까? 주어진 정보로 합리적으로 행동한 사람이 결과적으로 잘못된 조치를 취했다고 전제하고, 그 조치가 그때 왜 옳아 보였는지를 묻는다는 뜻입니다. 비난이 정보를 파괴하기 때문에 중요합니다. 사람들은 자기 보호를 위해 서술을 편집하고, 회고는 그렇게 오염된 입력을 재료로 삼게 됩니다.

포스트모템은 단일 근본 원인을 지목해야 합니까? 아닙니다. 규모를 가리지 않고 장애는 여러 조건이 동시에 성립해야 하는 사슬이므로, 기여 요인을 나열하는 편이 더 쓸모 있습니다. 사슬의 맨 앞이 아니라 가장 값싼 두 가지를 고칠 수 있게 해 주고, 설명이 아니라 서술일 뿐인 “인적 오류"로 끝나는 것도 막아 줍니다.

장애 타임라인에는 무엇을 담아야 합니까? 시스템이 무엇을 했는지만이 아니라 사람들이 무엇을 언제 알았는지를 담아야 합니다. 언제 시작되었는지, 누가 처음 알아차렸는지, 적임자가 언제 투입되었는지, 원인이 언제 파악되었는지, 언제 완화되고 언제 해소되었는지를 기록하십시오. 개선의 여지는 그 간격에 있고 탐지 시간이 대개 가장 큽니다.

포스트모템 액션 아이템은 왜 끝나지 않습니까? 업무 트래커가 아니라 문서 안에 살기 때문에 일정이 잡히는 시점에 보이지 않습니다. 항목 수를 줄이고, 평소 쓰는 트래커에 이름이 붙은 담당자와 기한을 넣고, 다음 포스트모템 시작 때 미완료 항목을 점검해 끝내지 못한 일을 눈에 보이게 만들면 해결됩니다.