DataOps는 데이터 전달과 관찰을 정리합니다. 실행 성공이 내용의 정확성이나 완전한 추적을 증명하지 않습니다.
재실행 통제
재실행의 기대 결과를 정하고 중복이나 부분 결과를 방지합니다. 재현에 필요한 입력, 기간, 규칙, 버전을 보존합니다. 입력이 바뀌면 결과도 달라질 수 있습니다. 통제된 복구 경로도 정의합니다.
버전과 계보 구분
버전은 상태와 변경을 설명하고 계보는 출처, 변환, 결과를 연결합니다. 용도에 따라 완전성, 고유성, 일관성, 적시성, 유효성, 정확성을 평가합니다. 올바른 형식의 값이 틀릴 수 있고 정확한 데이터가 너무 오래될 수 있습니다.
| 항목 | 기록할 확인 사항 |
|---|---|
| 실행 | 기술 상태와 기대 결과 |
| 품질 | 용도에 맞는 내용 확인 |
| 출처 | 출처, 변환, 결과 연결 |
출처와 확인
시간대와 지연 이벤트
보고 기간은 이벤트 시간과 마감 규칙에 달려 있습니다.
- 이벤트 시각, 수신 시각과 업무 시간대를 따로 기록합니다. 가상 예에서 23:30 UTC는 고정 오프셋 UTC+02:00에서 다음 날 01:30입니다. PostgreSQL의 시간대 포함 타임스탬프는 원래 시간대 이름을 보존하지 않습니다.
- 시작은 포함하고 끝은 제외하는 구간을 사용합니다. 업무 시간대에서 경계를 정한 뒤 UTC로 변환합니다. 계절 시간 변경, 월 변경과 시각 없는 날짜를 시험합니다. 현지의 하루를 항상 24시간으로 바꿀 수는 없습니다.
- 허용 지연과 보고서 마감 시각을 정합니다. 같은 식별자를 재처리해 새 이벤트와 중복을 구별합니다. 발표된 버전을 보관하고 수정 영향을 기록합니다. 워터마크는 도착 추정이며 완전성을 보장하지 않습니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}예상 판단
지정 시간대에서 이벤트는 10월 9일에 해당합니다. UTC 시점도 보존합니다.
검증 절차
- 보고 시간대와 기준 시점을 정합니다.
- 자정 근처 이벤트를 재현합니다.
- UTC, 현지 날짜 및 마감 규칙을 보존합니다. 시계 변경 때 모호해지는 현지 시각도 포함하고, 시점을 추정하지 말고 오프셋과 시간대를 보관하세요.
수신 날짜를 이벤트 날짜로 써도 되나요?
보고서 정의가 요구하는 경우에만 가능합니다. 두 시각을 모두 보존하고 지연 이벤트 처리 방식을 설명하세요.
1차 자료: PostgreSQL — Date/time types. 관련 방법: 실무 가이드 읽기.
수집 장애: 로그와 누락 이벤트 대조
생성, 수신과 사용 가능한 이벤트를 구분하며 기록이 없음을 사고가 없다는 증거로 보지 않습니다.
- 애플리케이션, 수집기, 저장소와 책임자를 정리합니다. 비밀이나 고객 데이터 없이 안정된 식별자의 유한한 가상 이벤트 열을 준비합니다. 이벤트 시각과 관찰 시각을 보존합니다. 수집 지연이 자동으로 손실을 의미하지는 않습니다.
- 시험에서 목적지를 중단한 뒤 복구합니다. 대기열, 재시도, 거부와 재시작을 관찰합니다. 영구 대기열은 일부 손실을 줄이지만 용량이 제한되고 저장소에 의존합니다. 가득 찼을 때 행동을 정하고 수집이 서비스를 조용히 막지 않는지 확인합니다.
- 같은 관찰 마감에서 기준과 실제 읽을 수 있는 이벤트를 대조합니다. 중복, 지연과 누락을 따로 셉니다. 네트워크 확인이 최종 사용 가능성을 입증하지는 않습니다. 신뢰할 기준이 없으면 범위 미확인으로 표시하고 손실이나 사고 0으로 쓰지 않습니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"expected_ids": [
"E1",
"E2",
"E3"
],
"received_ids": [
"E1",
"E1",
"E3"
],
"received_rows": 3,
"unique_received": 2,
"missing_ids": [
"E2"
],
"observation_cutoff": "same_for_both_sets"
}예상 판단
가상 예: E1, E2, E3을 기대하지만 E1, E1, E3을 받습니다. 세 행은 완전성을 입증하지 못합니다. E1이 중복되고 마감에 E2가 빠집니다.
1차 자료: OpenTelemetry — Collector resiliency. 관련 방법: 실무 가이드 읽기.
ZIP과 TAR: 디렉터리와 자원 예산 안에서 압축 해제
추출한 파일을 공개하기 전에 경로, 링크와 실제 해제량을 검증합니다.
- 최소 권한의 새 비공개 디렉터리에 추출합니다. 절대 경로, 상위 이동, 불필요한 링크와 특수 파일을 거부합니다. 실제 해석된 대상과 충돌을 대소문자를 포함한 대상 시스템 규칙으로 확인합니다. 문자열 접두사만으로 격리를 입증할 수 없습니다.
- 기록한 바이트, 항목 수, 깊이, 시간과 프로세스 자원에 파일별 및 합계 한도를 둡니다. 압축 크기나 선언 크기만 믿지 않습니다. 불필요한 중첩을 거부하고 허용 시 모든 단계가 총예산을 공유합니다. 라이브러리와 필터를 갱신합니다.
- ../, 절대 경로, 링크, 중복과 예산 초과를 시험합니다. 중단 시 배치를 공개하지 않고 기존 파일을 덮어쓰지 않아야 합니다. 유형과 내용을 검증한 후 공개하고 격리 디렉터리 정리 시 대상을 확인합니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"compressed_mb": 2,
"expanded_mb": 600,
"aggregate_budget_mb": 100,
"first_files_valid": true,
"expected": "stop_on_actual_overrun_and_do_not_promote"
}예상 판단
가상 예: 2 MB 압축 데이터가 600 MB로 늘어나며 예산은 100 MB입니다. 실제 기록량 초과 시 중단하고 앞 파일이 정상 같아도 공개하지 않습니다.
Python — tarfile extraction filters and further verification
1차 자료: Python — tarfile extraction filters and further verification. 관련 방법: 실무 가이드 읽기.