DataOps организует доставку и наблюдение за данными. Успешный запуск не доказывает правильность содержимого или полную прослеживаемость.
Контролировать повторы
Определяйте ожидаемый результат повторного запуска и предотвращайте дубли или частичные результаты. Для воспроизведения сохраняйте входы, период, правила и версии; изменённые входы могут дать другой результат. Нужен и контролируемый путь восстановления.
Разделять версии и происхождение
Версии описывают состояния и изменения; lineage связывает источники, преобразования и результаты. Оценивайте полноту, уникальность, согласованность, актуальность, допустимость и точность по назначению. Верный формат может содержать ошибку, а точные данные быть устаревшими.
| Пункт | Что документировать |
|---|---|
| Выполнение | Технический статус и ожидаемый результат |
| Качество | Содержательные проверки по назначению |
| Происхождение | Связанные источники, преобразования и результат |
Источники и проверка
Часовые пояса и поздние события
Период отчёта зависит от времени события и правил закрытия.
- Храните время события, получения и деловой часовой пояс отдельно. В вымышленном примере 23:30 UTC — это 01:30 следующего дня при фиксированном смещении UTC+02:00. Тип PostgreSQL с часовым поясом не сохраняет исходное название зоны.
- Включайте начало и исключайте конец периода. Вычисляйте границы в деловой зоне до перевода в UTC. Проверьте смену сезонного времени, месяца и дату без времени: местный день не всегда равен 24 часам.
- Задайте допустимую задержку и момент закрытия отчёта. Повторите идентификатор, чтобы отличить новое событие от дубликата. Сохраните опубликованную версию и влияние исправления; watermark оценивает поступление и не гарантирует полноту.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}Ожидаемое решение
В указанном поясе событие относится к 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 МБ сжатых данных дают 600 МБ при бюджете 100 МБ. Остановитесь при превышении записанных байтов и не публикуйте пакет, даже если первые файлы выглядят правильными.
Python — tarfile extraction filters and further verification
Первичный источник: Python — tarfile extraction filters and further verification. Связанный метод: прочитать практическое руководство.