파이프라인 선택 경로

운영 인계서는 실패 다음 행동을 정합니다

파이프라인 경로를 선택하면 operations.md가 주 산출물이 됩니다. 분석을 선택한 사람은 운영 담당의 입장에서 복구 가능성을 묻는 질문을 적습니다. 인계서의 독자는 코드를 작성한 사람이 아니므로 정상 명령 하나만으로는 충분하지 않습니다. 어떤 파일이 입력이고 어떤 상태가 공개되었는지, 실패 후 무엇을 읽고 누가 승인하는지 알려 줍니다. 자동화가 제공하는 기능과 문서로만 제안된 기능을 구분하여 새 담당자가 구현되지 않은 보호 장치를 믿고 작업하지 않게 합니다.

스키마는 pipeline.json과 cleaning.HEADER에 연결하고 저장 키는 observations의 region,date 쌍이라고 적습니다. 같은 날짜의 다른 지역은 다른 행이며 같은 지역의 정정 날짜는 기존 키를 갱신합니다. total_vehicles와 rain_mm의 NULL은 실제 영점과 다릅니다. 형식 오류와 품질 기준 초과는 서로 다른 책임이므로 오류 코드별 입력 확인 지점을 씁니다. 열 이름만 나열하는 문서보다 원본, 변환 표, 저장 표의 단위가 어떻게 이어지는지 설명하는 문서가 장애 조사에 유용합니다.

작업의 순서와 공개 경계를 표시합니다

공통 순서는 일별 집계, 지역 매핑과 날씨 결합, 정제, 지표, 그래프, 품질 공개입니다. delivery.py의 build에서 함수 호출을 확인할 수 있습니다. quality.run의 source는 joined.csv이며 report.json은 누적 DB에서 두 수치가 모두 있는 행의 합계입니다. 지표와 그래프는 고정 표본 out/clean.csv를 사용합니다. 따라서 증분 DB에 정정본을 넣었다고 기존 그래프까지 자동으로 정정되었다고 쓰지 않습니다. 정정 보고서와 그림을 함께 제공하려면 승인된 입력을 분석 단계에도 반영해 다시 생성합니다.

초기 공개는 4행·합계 300이고 correction.csv를 적용하면 공개 합계는 305입니다. 이 사례는 저장 경로의 정정 검증입니다. 고정 표본의 chart-data가 여전히 예전 값을 담는다면 각 산출물의 기준 입력을 명시합니다. 최신 파일 이름만 보고 같은 버전이라고 가정하지 않습니다. 보고서 내부 성공 lineage의 입력 해시와 문서의 기준 표본을 연결하고 수정 사유·영향 기간을 전달합니다. 사람이 소비하는 산출물 사이 버전 일치도 기술적인 적재 성공과 별도로 점검합니다.

배치 품질과 누적 품질을 분리합니다

현 게이트는 들어오는 배치의 키 중복·음수·통행 결측률 0.2 초과·강수 결측률 0.4 초과를 차단합니다. 정확히 경계이면 허용하며 빈 배치는 EMPTY입니다. 이 숫자는 여섯 행 표본의 기존 누락을 보존하면서 증가를 진단하는 학습 정책입니다. 누적 DB 전체의 지역별 결측률까지 검사했다고 주장하지 않습니다. 운영으로 확장할 때에는 공개 목적, 공급 지연, 관측 단위를 검토하여 정책 책임자가 기준을 승인하는 절차를 별도로 둡니다.

경보 초안은 종료 코드가 비영점일 때 오류 코드, run_id, 입력 해시, db_committed를 진단 담당에게 전달하는 것입니다. 현재 코드는 외부 경보 전송이나 스케줄러 등록을 하지 않습니다. 미적용이라고 표시하고 알림 대상 역할과 확인해야 할 파일을 문서에 적습니다. 프로세스가 정상 종료했는지와 데이터가 최신인지도 다르므로 실제 자동화에는 기대 입력 날짜와 공급 여부를 보는 검사가 필요합니다. 이 실습에서 제공하지 않은 지연 검사를 이미 구현한 기능처럼 인계하지 않습니다.

품질 오류는 원본 확인으로 시작합니다

TRAFFIC_MISSING과 RAIN_MISSING에서는 collected의 해시별 payload.csv와 누락 지역·날짜를 읽습니다. DUPLICATE_KEY는 같은 관측의 반복이나 정정본 충돌을 조사하고 NEGATIVE_TRAFFIC은 절대 합계 계약 위반을 조사합니다. 같은 불량 입력의 반복은 품질을 회복하지 않습니다. 승인된 공급 정정본을 받은 뒤 재실행합니다. 기준을 느슨하게 바꾸거나 음수에 절대값을 씌우면 진단 근거가 숨겨집니다. 어떤 오류가 입력 정정 대상이고 어떤 오류가 코드 수정 대상인지 확인 후 조치를 선택합니다.

lineage.json은 최신 시도이며 quality-audit.json은 시도 이력입니다. 공개 report.json 안의 lineage는 해당 성공 보고서의 계보입니다. 최신 시도가 실패하면 별도 lineage와 공개 보고서의 실행 ID가 달라도 자연스러운 상태입니다. 담당자는 세 파일의 역할을 알고 실패 시도와 마지막 성공을 연결해 읽어야 합니다. 감사 파일의 쓰기 자체가 실패할 수 있으므로 기록이 없다는 사실만으로 시도가 없었다고 단정하지 않습니다. 저장 공간과 DB 상태를 직접 확인해야 하는 경계도 문서에 남깁니다.

롤백과 공개 실패는 다른 복구입니다

INJECTED는 DB 쓰기 도중 주입한 장애이며 트랜잭션이 롤백되는지 테스트합니다. PUBLISH는 DB 커밋 뒤 report 파일 교체 직전 주입한 장애입니다. 이때 마지막 정상 파일은 유지되지만 db_committed는 true일 수 있습니다. 실패 보고서를 다시 공개하기보다 DB 상태와 승인 입력을 확인한 뒤 같은 입력을 재처리하여 새 정상 보고서를 만듭니다. 두 실패를 모두 롤백이라고 부르면 저장 상태와 공개 수치가 어긋난 상황에서 담당자가 잘못된 전제를 갖게 됩니다.

DB와 외부 JSON 파일은 하나의 트랜잭션이 아닙니다. 파일 임시 쓰기와 replace는 해당 공개 파일 교체 경계를 줄이지만 모든 단계의 원자성을 제공하지 않습니다. 인계서는 이 한계를 명시하고 DB 확인, 승인 입력 확보, quality.run 재실행, 공개 계보·행·합계 대조의 순서를 적습니다. 오래된 개정본 자동 거절과 동시 실행도 지원하지 않습니다. 따라서 개정 승인 순서를 사람이 확인하고 단일 담당 실행으로 연습합니다. 실제 운영 적용은 별도의 실행 제어 설계가 필요합니다.

접근과 보존을 작업 역할에 연결합니다

공개 담당은 검토된 집계 결과를 사용하고 진단 담당은 원본과 감사 기록을 봅니다. 입력에 새 민감 열이 생기면 공개 필드 허용 목록부터 검토합니다. 이 합성 표본에는 개인정보가 없지만 해시가 익명화 기능을 대신하지는 않습니다. 문서에 접근 역할을 쓴 것은 OS 권한 설정 완료가 아닙니다. 실제 적용 여부는 미적용으로 표시합니다. 보존 목적과 삭제 승인 담당을 합의해야 하며 조직 정책을 확인하지 않은 법정 기간을 임의로 적지 않습니다.

제출 전 실패 사례를 하나 골라 새 담당자처럼 문서를 따라 읽습니다. 어느 원본을 볼지, DB가 커밋되었는지, 마지막 공개는 무엇인지, 재실행 전 누가 승인할지를 답할 수 있어야 합니다. 테스트 이름과 실제 확인 파일을 붙이고 담당자 기억에 의존하는 문장을 고칩니다. 분석 담당에게는 전체 결측률이 통과해도 특정 지역에 누락이 몰린 경우 공개 판단이 달라지는지 묻습니다. 운영 문서의 완료는 기능 목록 작성이 아니라 실패 다음 행동을 근거로 정할 수 있게 만드는 것입니다.