증거로 작성하는 장애 회고

복구 뒤 다음 대응을 개선합니다

안내판이 다시 열리면 사용자 불편은 줄지만 같은 실패가 재발할 위험은 남습니다. 회고는 당시 어떤 증거로 판단하고 어떤 행동이 영향을 줄였는지 기록하여 다음 대응을 개선하는 문서입니다. 누가 잘못했는지 순위를 정하기보다 실패를 허용한 조건·탐지 지연·복구 제약을 찾습니다. 개인의 실수라는 문장만 남기면 코드·검사·절차의 개선 지점이 사라집니다. 이 레슨에서는 m07 실패 배포와 m08 관측 자료를 근거로 타임라인·영향·복구·후속 작업을 작성합니다. 실제 운영 장애를 일으키거나 서버에 접속할 필요는 없습니다.

사건 범위를 한 문장으로 씁니다

제목에 조회 실패와 교육 fixture라는 범위를 드러냅니다. 관측 시작·끝과 대상 버전·사용자 흐름을 설명합니다. 미션의 error 구간은 의도적으로 주입한 실패이므로 실제 원격 저장소 장애라고 쓰지 않습니다. slow 구간의 클라이언트 timeout도 서버가 끝내 실행한 결과와 나누어 적습니다. 실제 운영 사실과 교육 재현 사실을 섞으면 다음 담당자가 잘못된 예방 작업을 선택합니다. 보고서 첫 문단만 읽어도 어느 자료가 원천이며 어떤 결론이 아직 가설인지 알 수 있게 씁니다.

영향은 요청과 사용자를 구분합니다

error 창에서 5개 요청이 모두 500이면 요청 실패 5건이라고 씁니다. 고유 사용자 5명이 피해를 입었다고 바꾸지 않습니다. 같은 사용자가 재시도한 것인지 알 수 없기 때문입니다. 시작·끝 시각은 관측 창의 경계이며 장애 전체 지속 시간이라고 단정하지 않습니다. 요청량·실패량·영향 기능·영향하지 않은 범위·미측정 항목을 함께 적습니다. 비율만 100%라고 쓰면 5건인지 많은 요청인지 해석이 어렵습니다. 영향 숫자는 windows.json의 동일한 구간을 직접 열어 재계산할 수 있어야 합니다.

타임라인에는 증거 경로를 붙입니다

시각은 UTC로 통일하고 각 항목에 사건·행동·관측·증거 파일을 붙입니다. m08 before·healthy·error·slow의 start와 end는 실제 수집 자료에서 가져옵니다. 배열 순서만 보고 같은 길이의 연속 창이라고 가정하지 않습니다. m07 전환·원복 시점은 별도 evidence-m07 기록과 연결합니다. 자료에 없는 신고 시각이나 경보 도착 시각을 만들어 채우지 않습니다. 미확인은 미확인으로 남기고 다음 재현에서 수집할 항목을 정합니다. 사람이 타임라인을 읽으며 복구 행동의 앞뒤를 추적할 수 있어야 합니다.

사실과 가설을 문장으로 분리합니다

사실은 동일 요청 ID의 클라이언트 500, 연결된 API/store span, 주입 설정처럼 자료가 직접 보여 주는 것입니다. 원인 가설은 오류 주입 구간이 실패에 기여했다는 설명입니다. 이 실습에서 store.fixture 상태는 주입 결과이며 실제 원격 DB 고장을 증명하지 않습니다. CPU가 함께 높았다는 상관만으로 CPU 부족이 원인이라고 결론 내리지 않습니다. 가설 옆에는 확인할 추가 자료나 반례 실험을 씁니다. 다른 담당자가 같은 증거를 보고 다른 해석을 제시할 수 있도록 증거와 설명을 나눕니다.

완화와 근본 개선을 나눕니다

이전 검증 릴리스로 복구하는 행동은 현재 사용자 영향을 줄이는 완화입니다. 오류 fixture가 검증에서 빠진 원인을 고치는 작업은 재발 위험을 낮추는 개선입니다. 롤백이 성공했다고 테스트 누락 문제가 해결된 것은 아닙니다. 데이터 복원은 버전 원복과 목적이 다르므로 어떤 데이터를 보존했고 무엇을 되돌렸는지도 적습니다. m07 절차에서 소유권·입력 archive·후보·이전 버전·데이터 검사를 확인하고 회고에 실제 결과를 연결합니다. 명령을 실행했다는 사실만으로 사용자 기능 회복을 주장하지 않습니다.

회복 기준을 사용자 흐름으로 확인합니다

프록시가 이전 버전을 가리키는지 확인한 뒤 /notices 응답과 데이터 계약을 재검사합니다. /health 200만으로 목록 조회가 회복했다고 말하지 않습니다. m08의 healthy 표본이 복구 이전 후보 정상 검사인지 복구 이후 결과인지 구분하여 증거를 붙입니다. 관측 수집이 살아 있고 새 실패가 없는지 추가 창도 확인해야 합니다. 이번 미션 보고서의 recovery는 안내 초안이므로 실제 원복 결과 경로와 조회 검사 결과를 작성자가 보완합니다. 자동 검사에 문장이 있다는 이유만으로 회복 사실이 검증됐다고 보지 않습니다.

후속 작업은 닫을 수 있게 씁니다

"주의한다"나 "모니터링 강화"는 완료 여부를 판단하기 어렵습니다. 예를 들어 오류 창의 bad=5 검사를 회귀로 추가하고 정상 코드에 실패 분류 변이를 넣었을 때 검사가 실패하는지 확인한다는 작업은 결과를 재현할 수 있습니다. 각 작업에는 담당·기한·구체적인 변경·완료 기준을 붙입니다. 완료 기준에는 어느 파일과 어떤 입력으로 확인하는지 적습니다. 담당은 실습에서는 역할 이름으로 충분하며 실제 개인정보를 넣지 않습니다. 작업 수를 늘리는 것보다 영향과 근거가 분명한 우선 작업을 선정합니다.

책임을 피하지 않는 비난 없는 문체

"배포 담당자가 실수했습니다"보다 "검증 단계가 조회 오류 fixture를 실행하지 않아 후보의 실패가 전환 전에 탐지되지 않았습니다"라고 쓰면 개선할 시스템 조건이 드러납니다. 누가 어떤 권한으로 행동했는지는 사실 기록에 필요할 수 있지만 성격이나 능력을 추측하지 않습니다. 확인하지 않은 사건을 사람 탓으로 채우지 않습니다. 잘 된 대응도 남겨 다음에 재사용합니다. 이전 검증 이미지와 데이터 백업을 보존한 점, 요청 ID로 사건을 연결한 점은 재현 가능한 절차의 장점으로 기술할 수 있습니다.

자동 검사의 범위를 이해합니다

check-offline.sh는 회고 필수 섹션·후속 담당·기한·완료 기준과 보고서의 증거 연결을 검사합니다. incident.json의 timeline 항목이 존재하는 phase를 가리켜야 하며 report 생성 때 start와 end를 실제 windows에서 넣습니다. 하지만 "원인이 확정됐다"는 문장의 타당성이나 영향 숫자와 원천 자료의 모든 의미를 자동으로 보증하지 않습니다. 리뷰어는 보고서와 원천 파일을 나란히 열어 숫자·순서·가설·복구 결과를 검토합니다. 형식 검사 통과와 사건 분석 완성은 서로 다른 확인 활동입니다.

오류를 산출물 문제로 읽습니다

FAIL provide m08 windows.json은 관측 원천이 없거나 정책·회고 형식이 잘못되었다는 신호입니다. 먼저 실제 수집 폴더와 파일 이름을 확인합니다. timeline evidence는 존재하지 않는 phase 또는 잘못된 증거 경로를 가리킨 경우입니다. action owner/criterion/due는 담당·완료 기준·기한 중 빈 값이 있는 경우입니다. 오류를 없애려고 임의 시각과 성공 요청을 만들어 실제 evidence-m08에 넣지 않습니다. 오프라인 테스트의 임시 fixture는 보고서 구조 확인용이고 제출할 실제 수집 결과와 분리되어 자동 삭제됩니다.

다음 담당자에게 전달합니다

제출물에는 정책 버전, 측정 범위, 원천 자료 경로, 타임라인, 요청 영향, 가설과 확인 방법, 복구 결과, 담당·기한·완료 기준이 있는 후속 작업을 포함합니다. 비밀·사용자 본문을 복사하지 않고 필요한 요청 ID와 허용된 관측 필드만 연결합니다. Docker 실행이 대기라면 대기라고 명시하고 교육 fixture 초안을 실제 수행 기록으로 포장하지 않습니다. m10에서는 이 회고와 전체 배포·복구 증거를 인계 안내에 묶습니다. 더 읽기의 요청 추적 장은 구간별 증거를 해석하는 배경이며 회고 문서의 문장을 그대로 가져오는 재료가 아닙니다.