다섯 사건으로 타임라인 세우기

목표

여러 로그에 흩어진 다섯 개의 시각을 모아 타임라인을 세우고, 사용자 관점의 영향 지속 시간을 계산할 수 있게 됩니다.

왜 중요한가

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

다섯 시각 사이의 네 구간이 각각 이름을 가집니다. 변경 → 영향은 잠복 구간, 영향 → 인지는 탐지 지연, 인지 → 조치는 대응 지연, 조치 → 복구 확인은 검증 구간입니다. 이 중 탐지 지연이 크면 고칠 것은 시스템이 아니라 관측입니다. 그리고 검증 구간이 없는 보고서는 "고쳤다고 생각한다" 까지만 말한 것입니다.

영향 지속 시간은 영향 시작부터 복구 확인까지로 셉니다. 사용자는 배포가 언제였는지 모르고, 롤백 명령이 들어간 순간이 아니라 실제로 정상이 된 순간에 영향에서 벗어나기 때문입니다.

로그 세 개: /opt/data/deploy.log, /opt/data/app.jsonl, /opt/data/alert.log

단계

1. /root/timeline 디렉터리를 만드세요.
2. payment 2.7.0 이 배포된 시각을 HH:MM 으로 /root/timeline/t_deploy.txt 에 적으세요.
3. 첫 에러가 발생한 시각을 /root/timeline/t_error.txt 에 적으세요.
4. critical 알람이 firing 된 시각을 /root/timeline/t_alert.txt 에 적으세요.
5. 롤백이 수행된 시각을 /root/timeline/t_rollback.txt 에 적으세요.
6. 알람이 resolved 로 바뀐 시각을 /root/timeline/t_resolved.txt 에 적으세요.
7. /root/timeline/timeline.md 를 쓰세요. 다섯 시각이 모두 들어가고, 파일 안에서 시간순으로 배치돼야 합니다.
8. 영향 시작부터 복구 확인까지의 분 수를 /root/timeline/mttr.txt 에 숫자만 적으세요.

참고

• cat /opt/data/deploy.log, cat /opt/data/alert.log — 둘 다 짧으니 그냥 읽으세요.
• 시각 표기는 HH:MM 입니다. 2026-08-19T03:19:04Z 에서 03:19 만 씁니다.
• 흔한 실수 1: 8번을 배포 시각부터 세는 것. 사용자는 배포 시각을 모릅니다.
• 흔한 실수 2: 7번에서 사람 이름이나 계정명을 쓰는 것. 로그에 있는 actor 값은 타임라인에 옮기지 않습니다.

단계 8개

1. 작업 디렉터리 만들기
2. 변경 시각 찾기
3. 영향 시작 시각 찾기
4. 인지 시각 찾기
5. 조치 시각 찾기
6. 복구 확인 시각 찾기
7. 타임라인 문서 쓰기
8. 영향 지속 시간 계산하기