Наблюдаемость данных: как замечать сломанные пайплайны раньше пользователей
Тихий сбой в данных опаснее, чем упавший сервис. Разбираю, что такое data observability и почему это нужно операционным командам, а не только инженерам.
Когда падает сервер или перестаёт открываться приложение, это заметно сразу. Алерты, звонки, инциденты. Команда реагирует.
Когда ломается пайплайн данных - тишина. Отчёт выглядит нормально. Цифры есть. Только через несколько дней кто-то замечает, что показатели не сходятся. Или не замечает вовсе, и компания принимает решения по неверным данным несколько недель.
Это принципиальная разница между наблюдаемостью инфраструктуры и наблюдаемостью данных.
Почему сбои данных тихие
Пайплайн не упал - он просто перестал приносить правильные данные. Источник поменял схему без предупреждения. API стал возвращать пустые поля. Соединение прерывалось в 3 часа ночи и джоб продолжил работу с неполным набором. Трансформация применилась, но к данным прошлой недели вместо сегодняшних.
Ничего из этого не создаёт exception. Нет error log. Есть только тихое искажение.
Мониторинг инфраструктуры это не видит. Он смотрит на CPU, память, доступность эндпоинтов. Но не на то, соответствуют ли данные ожидаемому распределению.
Что такое data observability
Это набор практик и инструментов, который позволяет задавать про данные те же вопросы, что мониторинг задаёт про инфраструктуру:
- Данные свежие? Последняя запись когда поступила?
- Объём нормальный? Сегодня пришло столько же строк, сколько обычно?
- Схема не изменилась? Все колонки на месте, типы совпадают?
- Значения в допустимых пределах? Нет ли нулей там, где их быть не должно, нет ли аномальных выбросов?
- Пайплайн завершился успешно? Не только без ошибок, но и с ожидаемым результатом?
Когда на эти вопросы есть автоматические ответы, команда видит проблему раньше, чем она дойдёт до пользователя отчёта.
Как это устроено на практике
Наблюдаемость данных не требует обязательно покупки специализированного инструмента. Многое можно начать строить самостоятельно:
Мониторинг свежести - простейшая проверка: когда последний раз в таблице обновлялись данные? Это можно настроить в любой системе мониторинга.
Проверки объёма - сравнение количества строк сегодня с медианой за последние N дней. Резкое отклонение в любую сторону - алерт.
Тесты схемы - автоматическая проверка, что структура данных не изменилась неожиданно. dbt-тесты, great expectations или самописные проверки.
Мониторинг распределений - более сложно, но ценно: следить за тем, что ключевые метрики остаются в нормальных пределах.
Что это даёт операционно
Главная ценность - сокращение времени между появлением проблемы и её обнаружением. Этот интервал называется MTTD - Mean Time To Detect. Чем он меньше, тем меньше решений принято по неверным данным.
Второй эффект - снижение тревожности команды. Когда нет мониторинга, все живут с ощущением "что-то может быть сломано, но мы не знаем". Когда мониторинг есть и он молчит - это информация.
С чего начать
Если у вас сейчас нет никакого мониторинга данных - начните с трёх вопросов:
- Какие данные, если сломаются, будут иметь наибольшие операционные последствия?
- Когда эти данные должны обновляться и как это проверить автоматически?
- Какой объём или распределение для них является нормой?
Ответы на эти три вопроса - это уже проект мониторинга. Всё остальное - усложнение поверх этого фундамента.