처음부터 실행하는 운영 인계

다른 사람이 재현해야 인계입니다

본인 터미널에서 한 번 성공한 배포는 다른 담당자의 실행 지식을 보장하지 않습니다. 최종 인계는 안내판 서비스의 구성·입력·명령·확인 근거를 연결하여 다음 담당자가 새 실습 환경에서 같은 버전을 실행하고 실패를 복구할 수 있도록 하는 작업입니다. 기억 속 경로나 이미 켜져 있는 자원에 의존하는 부분을 드러냅니다. README만 전달했다고 인계가 끝나는 것이 아니라 동료가 따라 실행한 결과와 막힌 부분까지 기록합니다. 운영 서버 접근 없이 전용 실습 환경으로 시연합니다.

구성도에는 경계를 표시합니다

사용자 요청은 loopback 포트의 nginx proxy를 지나 전용 Docker network 안의 안내판 서비스로 갑니다. 서비스는 data volume의 notice.txt를 읽고 외부 current/token을 read-only로 받습니다. CI archive는 배포 입력이고 관측 자료는 실행 결과입니다. m08 수집기는 후수집된 span을 보관하며 실시간 자동 계측 서비스라고 쓰지 않습니다. 구성도에는 포트·통신 경로·소유 프로젝트·데이터와 비밀 경계를 표시합니다. 그림에 없는 연결이 명령에 있으면 문서와 설정을 함께 수정합니다.

실행 도구와 산출물을 고정합니다

Java 17과 Spring Boot 3.1.5, 포함한 Maven wrapper, Python, Docker, OpenTofu 및 provider 버전을 문서에 적습니다. 실행용 이미지 ID와 CI의 변경 ID·테스트 요약·archive를 연결합니다. 이 트랙의 imageDigest는 검증한 로컬 image ID이며 registry manifest digest와 같은 값이라고 단정하지 않습니다. 이전 릴리스 archive와 후보 archive는 별도 폴더에 둡니다. 이름만 같은 태그를 다음 사람이 받아도 동일 이미지라고 믿지 않고 로드 후 ID와 platform을 확인합니다.

깨끗한 환경을 정의합니다

새 작업 폴더에 내려받은 코드·준비된 도구만 있는 상태에서 시작합니다. 이미 존재하는 m07 이름, 이전 실습 포트 충돌, 남은 volume이 결과를 대신하지 않게 확인합니다. 다른 사람이 사용 중인 프로세스를 종료하지 않고 별도 실습 환경이나 합의된 포트를 사용합니다. 기존 환경을 이어받는 경우와 처음 생성하는 경우를 README에서 분리합니다. 원본 state·외부 비밀·검증 CI archive가 필요한 단계에서는 누락 오류를 먼저 설명하고 가짜 입력으로 대체하지 않습니다.

빌드부터 배포까지 따라갈 수 있게 씁니다

m01 준비 스크립트와 app의 테스트, m04 CI 이미지 archive, m05/m06 전용 자원과 비밀, m07 rollout 입력을 실행 순서대로 연결합니다. 각 단계는 작업 디렉터리·입력 경로·명령·통과 기준·실패 시 읽을 파일을 갖습니다. 전체 파일을 복사한 m10 미션에는 README-m09부터 앞 실행 문서들이 남아 있습니다. 경로는 본인 제출 환경의 실제 경로로 보완하고 외부 비밀 값은 문서에 넣지 않습니다. 통합 명령은 시연 후 자원 정리까지 포함하므로 목적과 중지 시점을 먼저 읽습니다.

실패 시연과 우연한 오류를 구분합니다

m07의 unready 후보는 준비 검사를 통과하지 못해 트래픽을 바꾸지 않아야 합니다. 정상 /notices는 후보를 받아들이고 오류·지연 fixture에서는 이전 릴리스로 복구해야 합니다. 의도한 실패 입력과 관측 결과를 나란히 보여 줍니다. 다른 네트워크 오류가 났는데도 계획한 롤백 시연이라고 부르지 않습니다. 각 trial의 path·action과 최종 active image, 사용자 응답을 확인합니다. 단순 exit=0이나 프로세스 살아 있음은 사용자 기능 복구를 대신하지 않습니다.

복구가 실제로 끝났는지 연결합니다

release-evidence.json의 finalImageId가 previousImageId와 일치하고 restorePreviousResponseEqual이 true인지 확인합니다. 안내판 조회 응답과 원본 데이터 비교까지 보여 줍니다. handoff_audit는 정상·오류·timeout 세 trial과 원복 버전·복원 응답을 검사합니다. 데이터 복원과 이미지 원복은 목적이 달라 각각 증거를 갖습니다. 사람이 보고서를 읽으며 실제 사용자 요청이 어느 경로로 갔는지와 복구 이후 기능 결과를 대조합니다. 문자열로 복구 완료라고 쓴 문장만으로 완료를 인정하지 않습니다.

관측 자료와 회고를 같은 사건으로 묶습니다

m08 windows.json의 요청 ID를 로그·trace의 API/store span에 연결하고 비교 자료를 함께 보관합니다. m09 report.json의 source_sha256이 그 원천 파일과 일치해야 합니다. 원천이 바뀐 보고서는 새 계산 또는 보존 사본 대조가 필요합니다. 다섯 요청 표본을 28일 SLO 준수의 증명으로 쓰지 않고 보고서 scope 한계를 설명합니다. alert_demo는 합성 연속 창의 정책 시연이며 실제 m08 phase에서 발생한 경보라는 주장과 분리합니다. 회고의 원인 가설과 확인 사실도 구분합니다.

운영 체크리스트는 행동을 담습니다

점검표에는 정기 사용량 확인, 입력 archive 무결성, 외부 비밀 갱신, 데이터 복원 연습, 경보의 첫 조사, 실습 자원 정리와 보존 재검토를 넣습니다. 각 항목은 담당 역할·주기 또는 조건·확인 방법·실패 시 행동을 갖습니다. 단순히 모니터링이라고 적으면 새 담당자가 어느 파일을 읽는지 알 수 없습니다. 알림이 발생하면 원천 창과 요청 실패를 확인하고 m07 복구 제약을 검토하도록 적습니다. 데이터 형식이 바뀌면 이전 버전 복원이 가능한지 먼저 확인합니다.

기록의 신뢰도도 전달합니다

명령 실행 로그·시각·작업 공간·image ID·입력 hash가 증거의 출처를 설명합니다. 오프라인 테스트, 고정 fixture, 실제 Docker 실행을 구별하여 표기합니다. Docker/OpenTofu 실행이 아직 없으면 PENDING을 남기고 실제 통과 숫자를 만들어 쓰지 않습니다. 로그에 비밀과 개인 데이터가 없는지 확인한 안전한 범위만 공유합니다. 자동 검사는 필수 필드와 해시·동작을 확인하지만 원인 해석과 운영 대응의 타당성 전체를 대신하지 않습니다. 동료 리뷰에서 숫자와 결론의 연결을 확인합니다.

정리 뒤에도 재현 입력을 보존합니다

최종 결과에는 사용량 inventory와 백업·복원 기록, destroy 검토 주소, cleanup-result를 연결합니다. 전용 자원은 0이어도 이전 및 후보 image archive와 보존 데이터가 남아야 새 환경에서 시연을 다시 만들 수 있습니다. 보존 checksum이 일치하고 비실습 자원이 유지됐는지 제출 자료로 보여 줍니다. 보존 폴더의 담당과 재검토 시점도 적습니다. state·plan·비밀은 공개 인계 문서에 첨부하지 않고 필요한 사람이 안전하게 접근할 절차를 설명합니다. 실제 정리를 다시 실행할 때는 새 환경인지부터 확인합니다.

동료의 실행 기록으로 마무리합니다

동료에게 새 환경의 준비부터 의도한 실패와 복구, 사용량 보고서, 정리까지 따라 해 보게 합니다. 걸린 시간보다 어느 입력이 부족했고 어떤 확인 기준이 모호했는지를 기록합니다. 누락된 작업 경로·도구·생성 순서를 README에 반영하고 미해결 항목에는 담당과 다음 확인 방법을 붙입니다. 제출 기준은 구성도·고정 버전·CI 근거·복구 근거·관측과 회고·보존과 정리·미확인 목록을 모두 찾을 수 있는 문서입니다. 빌드와 배포 배경은 더 읽기로 보내고 여기서는 실행 가능한 연결을 완성합니다.