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、現地日付、締切規則を残します。 時刻変更時の曖昧な現地時刻も含め、時点を推測せずオフセットとタイムゾーンを保存します。
受信日をイベント日として使えますか？
レポートの定義がそう求める場合に限ります。両方の時刻を保存し、遅着イベントの扱いを説明します。
一次資料：PostgreSQL — Date/time types. 関連する方法：実践ガイドを読む.
収集停止：ログと欠けたイベントを照合する
生成、受信、利用可能なイベントを分け、記録の静けさを障害がない証拠としません。
- アプリ、収集器、保存先と担当者を整理します。秘密や顧客データを含まない、安定した識別子の有限な架空イベント列を準備します。イベント時刻と観測時刻を残します。収集の遅延は自動的に喪失を意味しません。
- テストで宛先を止めて復旧します。キュー、再試行、拒否、再起動を観測します。永続キューは一部の喪失を抑えますが、容量が有限で保存先に依存します。満杯時の動作を定め、収集がサービスを黙って停止させないか確認します。
- 同じ観測締切で参照集合と実際に読めるイベントを照合します。重複、遅延、欠落を別々に数えます。通信の確認は最終的な利用可能性を証明しません。信頼できる参照なしでは範囲は不明であり、喪失ゼロや障害ゼロとしません。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"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が欠けています。
一次資料：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
一次資料：Python — tarfile extraction filters and further verification. 関連する方法：実践ガイドを読む.