변경 기록과 리뷰

기록은 다음 담당자의 판단 도구입니다

변경자가 성공했다고 적었는데 다음 담당자는 무엇을 바꿨는지 알 수 없는 기록을 자주 만납니다. 작업을 기억하는 사람에게는 충분해 보여도 장애가 생겼을 때는 사유·차이·검증·복구 조건이 연결되어 있어야 합니다. 이번 레슨은 누적 프로젝트의 evidence/change.md를 작성하고 다른 담당자가 그 문서만으로 적용 대상과 실패 시 대응을 설명할 수 있는지 리뷰합니다. 자동 생성 로그와 사람이 작성하는 판단을 서로 보완합니다.

먼저 변경 사유를 업무 결과로 씁니다

설정을 정리했다는 표현만으로는 변경 필요성을 판단하기 어렵습니다. 새 VM에서도 동일한 계정과 실행 경로를 재현하고, 잘못된 데이터 파일을 선택하면 이전 응답으로 복구하는 연습을 한다고 씁니다. 사유에는 현재 문제, 기대하는 결과, 이번에 다루는 범위를 포함합니다. 앞 모듈의 점검·알림·백업을 대체하는 작업이라고 적지 않습니다. 기존 운영 실습실과 분리된 복구 리허설 사본을 만든다는 목적을 명확히 합니다.

대상과 변경하지 않는 경계를 적습니다

미션 적용 범위는 /srv/bootcamp-m09, bootcamp-config.service, inet bootcamp_m09입니다. 기존 bcweb·bcops·bcapp의 계약을 조회하여 재사용하며 암호나 UID는 바꾸지 않습니다. 기존 앱·timer·백업 경로는 previous에 연결되어 있습니다. 기록에는 실제 설치 경로와 실행 계정, 관리 필드를 이름으로 씁니다. '서버 설정'이라는 넓은 표현은 다른 담당자가 /etc 전체를 교체한다고 오해할 수 있어 피합니다.

차이를 원인과 연결합니다

계획의 resource·field·before·after 행을 표로 옮기고 각 행에 목적을 붙입니다. 모드 0777에서 0750으로 줄이는 이유가 전용 그룹의 읽기와 작업자 쓰기 분리라면 그 접근 조건을 적습니다. 값만 적으면 왜 그 값이 선택됐는지 판단할 수 없습니다. 반대로 목표만 적으면 실제 적용 내용이 맞았는지 비교할 수 없습니다. 긴 파일의 diff는 별도 증거로 연결하고 본문 표에는 사람이 판단할 핵심 차이를 남깁니다.

시각이 다른 증거를 한 상태로 합치지 않습니다

m07 복구 PASS, m08 timer 실행, m09 새 응답은 서로 다른 시점입니다. previous의 checks.jsonl과 recovery.json을 유지한 채 경로·관측 시각·검증 대상을 change.md에 연결합니다. 과거 복구 성공을 현재 복구 가능성의 보장이라고 적지 않습니다. 실제 변경 직전 관측과 사후 관측은 새 시각으로 보관합니다. 대역 테스트는 fixture라고 표시하여 실제 VM의 systemctl·HTTP 조회와 쉽게 구별되게 합니다.

사전 검사의 의미를 제한해서 씁니다

Python 로컬 회귀가 통과하면 비교·파일 적용·되돌림 분기가 의도대로 동작했다는 근거가 됩니다. 그것만으로 VM 계정 권한이나 nft 커널 규칙이 적용됐다는 의미는 아닙니다. systemd-analyze verify는 유닛 문법 확인이고 서비스의 업무 응답 검증은 별도입니다. nft -c는 후보 문법과 커널 수용 가능성을 검사하지만 실제 패킷의 도달을 전부 보여주지 않습니다. 어떤 검사가 무엇을 확인했는지 명령 옆에 한 문장으로 씁니다.

실행 결과를 짧고 추적 가능하게 남깁니다

각 명령에는 실행 계정·시각·대상·종료 코드와 증거 파일 경로를 붙입니다. 로컬 test_change의 13개 통과와 이전 회귀 결과는 실제 로그로 연결합니다. VM 검증이 남아 있으면 PENDING이라고 적고 완료 날짜를 만들지 않습니다. 수치나 응답을 예상으로 채우면 다음 담당자가 재현 실패를 도구 오류라고 판단할 수 있습니다. 출력 원문에 비밀이 들어 있으면 허용된 결과와 코드로 요약하고 원문 공개를 줄입니다.

변경 수 0의 단위를 씁니다

apply.json의 first는 관리 자원 변경 건수이며 second는 같은 상태에서 즉시 다시 적용한 건수입니다. 같은 파일의 내용과 권한 두 행이 한 자원 변경일 수 있습니다. 최초 계획을 별도 사본으로 보관하고 이후 apply를 다시 실행한 기록과 구별합니다. 두 번째 0은 해당 관측 순간의 일치이며 앞으로 드리프트가 없다는 보장이 아닙니다. 새 drift가 생기면 다시 계획을 검토하고 이번 기록의 연속 작업인지 별도 변경인지 판단합니다.

복구 조건을 실행 전에 승인합니다

이 리허설의 실패 기준은 /health 상태와 본문, /items 상태와 전체 JSON이 기준과 다른 경우입니다. 실패하면 후보 서비스를 자연 종료까지 기다린 뒤 이전 service.env의 정확한 바이트를 복원하고 새 응답과 체크섬을 확인합니다. 복구 기한·연락 담당자·추가 변경 중단 조건을 문서에 적습니다. 무슨 일이 있어도 되돌린다는 문장보다 어떤 관측이 언제 복구를 시작하게 하는지가 도움이 됩니다.

판정 코드를 사람의 후속 행동으로 연결합니다

APPLIED는 후보 상태가 검증을 통과한 경우이며 이후 관찰 담당자를 지정합니다. ROLLED_BACK은 후보는 실패했지만 이전 상태가 검증된 경우라 변경을 완료로 닫지 않고 실패 원인을 리뷰합니다. RECOVERY_FAILED이면 응답이나 파일 상태를 확정할 수 없으므로 작업을 멈추고 사본·현재 설정·최근 로그를 보존합니다. 연락할 역할과 다음 조회 순서를 써 두면 숫자 2만 보고 여러 사람이 동시에 새 설정을 적용하는 혼란을 줄일 수 있습니다.

담당자 인계에는 수명과 정리 상태가 들어갑니다

bootcamp-config.service는 8초 뒤 자연 종료하는 리허설 앱입니다. 마지막 ExecMainPID=0과 종료 상태를 적고 활성 장기 서비스라고 소개하지 않습니다. 설치된 전용 사본·백업·방화벽 테이블·비활성 유닛은 인계 증거로 유지합니다. 이후 제거가 필요하면 인수자가 소유 범위를 확인하여 별도 작업으로 계획합니다. 기존 timer와 기존 앱에 어떤 변경도 하지 않았다는 것은 적용기 범위와 앞 회귀 검사로 뒷받침합니다.

리뷰 질문으로 모호한 문장을 잡습니다

리뷰어는 이 경로가 누구의 것인지, 현재 값의 조회가 성공했는지, 두 번째 적용이 파일을 쓰지 않았는지, /health만 통과한 것은 아닌지 묻습니다. 작성자는 각 질문에 증거 경로를 대답할 수 있어야 합니다. 모른다면 성공 문구를 먼저 고치기보다 필요한 관측을 추가합니다. 다시 테스트하기 전에 변경이 필요한지 검증만 부족한지 구분하면 같은 설정을 불필요하게 다시 적용하지 않을 수 있습니다.

실패한 기록 예시를 고칩니다

'설정 변경 완료, 이상 없음, 실패하면 백업 복사'는 실패 시점과 복사 대상을 모르게 합니다. 'bad.json 선택 후 /items의 count가 9여서 후보 실패, 전용 시각 디렉터리의 service.env.before 복원, 최종 SHA-256 동일 및 count=3 확인'처럼 씁니다. 이것은 형식 예시이며 실행하지 않은 결과를 자신의 증거로 제출하지 않습니다. 자신의 VM에서 수행하지 못했다면 HTTP 확인 대기라고 표시합니다.

문서 실습의 제출물 기준

이번 실습은 코드 채점 대신 change.md와 짝 리뷰 코멘트를 제출합니다. 사유·대상 표·차이 표·사전 검사·적용 결과·복구 기준·복구 증거·인계 담당자를 빠짐없이 작성합니다. 리뷰어는 명령을 다시 실행하지 않고 먼저 제출 파일의 경로와 시각을 따라 근거가 존재하는지 확인합니다. 누락은 확인 대기 목록으로 남기고 작성자가 보완하거나 한계를 명시합니다. 모든 칸을 문장으로 채웠다고 검증이 완료된 것은 아닙니다.

미션 완료와 다음 장애 대응의 출발점

미션은 previous의 m08 결과, 새 명세와 적용 코드, 첫/두 번째 적용 기록, 실패 후보·복원 해시·업무 응답을 하나의 인계 묶음으로 만듭니다. 체크리스트에서 상태를 확인하는 법과 코드가 왜 그 상태를 만들었는지 설명하는 법을 함께 준비합니다. diff의 자세한 형식은 서재를 참고합니다. 다음 모듈에서는 이 변경 기록을 장애 타임라인과 연결하여 최초 관측과 복구 판단이 언제 이루어졌는지 설명합니다.

change={"resource":"unit","field":"user","before":"root","after":"bcweb"}
print("{resource}.{field}: {before} -> {after}".format(**change))

unit.user: root -> bcweb

for hash_ok,http_ok in [(True,True),(True,False),(False,True)]:
    print(hash_ok,http_ok,"RECOVERED" if hash_ok and http_ok else "REVIEW_REQUIRED")

True True RECOVERED
True False REVIEW_REQUIRED
False True REVIEW_REQUIRED

cat evidence/change.md