장애 리뷰 발표

템플릿 소개

이 자료가 놓이는 자리

큰 장애가 끝난 뒤 경영진에게 하는 사후 보고에 쓰는 자료입니다. 기술 조직 안에서 원인을 파고드는 회고 문서와는 층이 다릅니다. 듣는 사람이 알고 싶은 것은 로그가 아니라 고객이 무엇을 겪었는지, 왜 막지 못했는지, 다시 나지 않게 하려면 무엇을 승인해야 하는지입니다. 그래서 첫 본문이 고객 영향이고 마지막이 필요한 결정입니다.

슬라이드 흐름

표지, 목차, 섹션 간지와 본문 한 쌍씩, 좌우 비교, 핵심 지표 카드, 추이 막대, 마무리로 이어집니다. 목차는 섹션 제목을 옮긴 것이므로 제목을 고치면 함께 고칩니다.

채우는 순서

1. 고객이 겪은 일 — 본문에 “3시간 12분 동안 결제 실패”, “영향 고객 4,800명 · 주문 1,240건”, “환불과 쿠폰 지급은 완료”가 들어 있습니다. 서버 이름이나 오류 코드가 아니라 고객이 본 화면과 그 규모로 적으십시오. 보상 처리 결과를 같은 장에 두는 이유는 첫 질문이 늘 그것이기 때문입니다.
2. 왜 막지 못했나 — 같은 설정을 두 곳에서 관리했는지, 경보가 늦게 울렸는지처럼 구조에서 원인을 찾습니다. 사람 이름은 적지 않습니다.
3. 대응 경과 — 첫 오류, 인지, 원인 확인, 우회, 정상화를 시각으로 적습니다. 인지까지 걸린 시간이 뒤의 요청을 뒷받침합니다.
4. 바꾸는 것 — 할 일마다 기한을 붙입니다. 기한 없는 재발 방지는 다음 장애 때 그대로 다시 적히게 됩니다.
5. 필요한 결정 — 예산과 인력처럼 승인이 있어야 진행되는 항목만 따로 모읍니다.

지표 카드와 추이 막대

카드 네 칸은 “장애 지속(분)” 192, “영향 고객(명)” 4,800, “인지 지연(분)” 15, “요청 예산(만원)” 8,000 입니다. 피해와 요청을 한 화면에 세워 둔 구성이라, 예산 칸을 빼면 보고만 남고 결정이 남지 않습니다. 192분은 본문의 3시간 12분과 같은 값이니 한쪽만 고치면 어긋납니다. 추이 막대는 “09:40” 99에서 “10:00” 12로 떨어졌다가 “11:15” 63을 거쳐 “12:55” 98로 돌아오는 결제 성공률 모양입니다. 시각과 값을 실제 장애 곡선으로 바꾸면 대응 경과 장의 시각과 그대로 맞아떨어져야 합니다.

비교 슬라이드

“사람을 탓할 때와 구조를 고칠 때”가 좌우로 놓입니다. 왼쪽 “보고가 늦어지고 축소됨”은 책임 추궁이 다음 장애를 키우는 경로이고, 오른쪽 “경보와 절차가 사람을 대신함”이 이 보고가 요청하는 방향입니다. 경영진이 원인 제공자를 묻는 자리에서 이 장을 먼저 펴는 용도로 만들어져 있습니다.

배포 전에 정리할 것

• 표지의 발표자와 소속 자리, 테마에 따라 붙는 영문 라벨.
• 지표 카드 아래 예시 값 각주. 피해 규모에 예시 표기가 남으면 보고 자체가 무의미해집니다.
• 추이 막대의 지수 단위 표기. 성공률로 바꿨다면 백분율로 표기를 고칩니다.

언제 올리고 무엇을 첨부할까

사후 보고는 대체로 장애 종료 후 사흘에서 닷새 사이에 올립니다. 그보다 빠르면 원인이 확정되지 않아 문장을 두 번 쓰게 되고, 늦으면 이미 다른 경로로 소문이 돕니다. 슬라이드에는 고객 영향과 결정 요청만 남기고, 시각별 로그와 재현 조건, 코드 변경 내역은 기술 회고 문서로 분리해 첨부하십시오. 고객 공지문을 이미 냈다면 그 문구를 그대로 첨부해야 대외 설명과 내부 보고가 어긋나지 않습니다. 같은 원인으로 이전에 장애가 있었다면 그 건의 재발 방지 항목이 어디까지 진행됐는지도 한 줄 적으십시오.

흔한 실수

• 기술 용어로 원인부터 설명하기 — 고객 영향을 말하기 전에 아키텍처를 꺼내면 질문이 엉킵니다.
• 재발 방지 항목에 담당과 기한을 빼기 — 마무리 문구가 “책임보다 구조를 고칩니다”인 이유입니다. 기한이 있어야 구조가 바뀝니다.
• 피해 규모를 반올림해서 줄이기 — 고객 문의 건수와 어긋나면 보고 전체의 신뢰가 무너집니다.