타임라인이 곧 보고서의 절반이다

한 줄 요약

타임라인은 사건의 나열이 아니라 각 구간이 무엇을 뜻하는지를 드러내는 도구이고, 그 구간들이 곧 다음번에 줄여야 할 시간이다.

왜 이게 필요했나

장애 보고서에서 고객이 가장 먼저 읽는 것은 원인 분석이 아니라 타임라인입니다. 이유가 있습니다. 타임라인은 "우리가 얼마나 오래 몰랐는가" 와 "알고 나서 얼마나 빨리 움직였는가" 를 동시에 보여 주기 때문입니다.

그리고 이 두 숫자가 다음 분기의 개선 과제를 결정합니다.

어떻게 동작하나

쓸 만한 타임라인에는 다섯 개의 시각이 있습니다.

변경 시각 — 무언가 바뀐 때. 배포, 설정 변경, 트래픽 급증.
영향 시작 시각 — 사용자가 실제로 실패를 겪기 시작한 때.
인지 시각 — 우리가 알게 된 때. 알람이 울렸거나 고객이 신고한 때.
조치 시각 — 완화 조치가 들어간 때.
복구 확인 시각 — 같은 잣대로 다시 재서 정상을 확인한 때.

그리고 이 다섯 개 사이의 네 구간이 각각 이름을 가집니다.

변경 → 영향: 잠복 구간. 짧으면 즉시 드러난 것이고, 길면 특정 조건이 쌓여야 터지는 유형입니다. 후자가 훨씬 무섭습니다.

영향 → 인지: 탐지 지연. 이 값이 크면 문제는 시스템이 아니라 관측입니다. 고객이 먼저 알려 주는 상황이 반복되면, 원인을 아무리 잘 고쳐도 신뢰는 회복되지 않습니다.

인지 → 조치: 대응 지연. 런북이 있으면 짧고 없으면 깁니다.

조치 → 복구 확인: 검증 구간. 이 구간이 없는 보고서는 "고쳤다고 생각한다" 까지만 말한 것입니다.

현장에서 만나는 모습

여기서 자주 나오는 판단 하나를 짚어 둡니다. 영향 지속 시간을 어디부터 어디까지로 세느냐입니다.

변경 시각부터 세면 실제보다 길어지고, 조치 시각까지만 세면 실제보다 짧아집니다. 사용자 관점에서 정직한 계산은 영향 시작부터 복구 확인까지 입니다. 사용자는 배포가 언제였는지 모르고, 롤백 명령이 들어간 순간이 아니라 실제로 정상이 된 순간에 영향에서 벗어납니다.

그리고 타임라인을 쓸 때 지켜야 할 규칙이 하나 더 있습니다. 사람 이름을 쓰지 않습니다. "김 아무개가 03:19 에 배포" 가 아니라 "03:19 payment 2.7.0 배포" 입니다.

이것은 도덕이 아니라 계산입니다. 고객사 보고서에 특정 담당자가 지목되면 다음 장애에서 그 사람은 정보를 숨깁니다. 그러면 다음번 탐지 지연이 늘어납니다. 비난 없는 보고서는 다음 진단의 속도를 사는 투자입니다.

다음 실습에서 할 것

배포 이력, 애플리케이션 로그, 알람 이력에서 다섯 개의 시각을 각각 뽑아내고, 시간순으로 세운 타임라인 문서를 만들고, 사용자 관점의 영향 지속 시간을 계산합니다.