Бывает, что в рабочий мессенджер без остановки сыпятся алерты, тесты уже месяц висят красными и непонятно, кто за что отвечает и что на самом деле важно.
Миккель Денгсё и Петр Янда вместе с дата-отделами сотен стартапов и компаний из Fortune 500 составили «Гайд по созданию высококачественных дата‑продуктов» для тех, кто устал от хаоса и хочет навести порядок в тестах, управлении качеством и инцидентами.
Разберем главные инсайты и наглядные кейсы.
Как выбраться из спагетти-линейджа
У Aiven было свыше 900 dbt-моделей. Из-за круговых зависимостей линейдж превратился в запутанный комок спагетти. Особенно страдали ключевые расчеты вроде ARR с сотнями апстрим-зависимостей: любое изменение цепляло половину стека.
Категории были большими и размытыми: «Маркетинг», «Продажи», «Продукт». Когда где‑то ломались данные, алерты сообщали, что сломался, допустим, «Маркетинг», но никто толком не понимал:
Что именно сломалось?
Насколько это критично?
Кто за это отвечает?
На какие бизнес‑процессы это влияет?
Проблемы диагностировали медленно, а решали с большим трудом.
Методично выделяя из больших продуктов вроде «Маркетинга» продукты поменьше, например «Атрибуция маркетинга», в Aiven стали быстрее находить ошибки и понимать, кто за них отвечает.
Правило 1: мыслите продуктами, а не отделами
Разбейте расплывчатые корзины вроде «Маркетинг» на конкретные продукты под одну задачу: «Атрибуция маркетинга», «CLTV», «Market Research». Так при сбое понятно, что именно рухнуло и как срочно нужно реагировать (атрибуция — сразу, ресерч — позже).
Оформляйте продукт так, чтобы короткая карточка всегда была рядом с кодом: задача, владелец (команда и канал), приоритет (P1–P4), входы/выходы, перечень ключевых таблиц/моделей.
Правило 2: держите правильную глубину
Слишком крупные продукты никак не помогают расставлять приоритеты. В Aiven ушли на уровень внутри домена: в «Маркетинге» выделили, например, «Attribution» (P1) и «Market Research» (P3). Приоритеты сразу перестали быть предметом споров.
Правило 3: назначайте владельца по-взрослому
Не «вся дата-команда» и не «один герой». Привязывайте к командам и их каналам, храните в метаданных (owner-теги, dbt groups), проверьте в CI, что у каждой модели есть владелец. Тогда эскалации предсказуемы.
Если у всего высокий приоритет, то у всего низкий приоритет
Это как с торрентами: если сразу для всех загрузок выставить высокий приоритет, то ничего не изменится, потому что их относительный вес будет тем же.
Так было в Lunar, где каждая команда считала свои данные самыми важными. Это мешало работе.
При этом каждая команда была права: ее данные — самые важные, но только для нее самой. Важность элементов системы не могут оценивать сами элементы.
Решение простое: раз в квартал руководство, стоящее над всеми командами, стало собираться, чтобы определить самые критичные данные на ближайшее время и установить понятные SLA, например, время реакции на сбои.
Правило 1: расставляйте приоритеты сверху, а не снизу
Если каждая команда помечает свои данные как P1, нечем управлять: все важное = ничего не важного.
Как делать:
Раз в квартал собирайте «совет приоритетов» (C-level + лиды продуктов и данных).
Формируйте единый список топ-10 критичных дата-продуктов на квартал.
Решайте по простым критериям: деньги под риском, клиентская поверхность, регуляторный риск.
Для остальных продуктов — P2/P3/P4 по убыванию важности.
Правило 2: привязывайте приоритет к действиям и срокам
Метка P1 без сроков — пустой ярлык. Для каждого уровня задайте явные цели реакции и восстановления.
Как делать:
P1 (клиент видит): подтверждение — 5 мин, обнаружение — до 10 мин, уведомление клиента — до 30 мин, временный обход сразу, фикc в приоритет.
P2 (критичные выгрузки/фон): подтверждение — 30 мин, фикc — в тот же день.
P3 (аналитика/BI): до конца следующего рабочего дня.
P4 (низкий риск): по бэклогу.
Назначьте владельца и on-call под каждый P-уровень.
Правило 3: держите приоритеты в тонусе
Приоритеты расползаются: все снова становятся P1.
Как делать:
Лимит на P1. Например, не больше 8 P1-продуктов на компанию. Хочешь добавить новый P1 — сними один старый.
Пересмотр раз в квартал. Обновляйте топ-10, смотрите факты: какие сбои реально били по деньгам и клиентам.
Фильтр апгрейда. Повышать приоритет можно только с бизнес-обоснованием: деньги под риском, клиентская поверхность, регуляторика.
Публичная доска. Таблица по доменам: список продуктов, их P-уровень и SLA. Видно всем.
Не нужно все тестировать, а то оглохнете от шума
В Google и Monzo на первых порах придавали огромное значение проверкам всех таблиц и столбцов. В результате получали сотни алертов, большинство которых не имели вообще никакого значения.
Помогла смена стратегии: тестировать стали в первую очередь источники данных, которые влияют на все остальное. Шум стих, система стала надежнее.
Правило 1: привяжите тест к действию
Тест без понятного next step — мусор. Ставьте проверку только там, где заранее известно: кто реагирует и что делает.
Пример:
Вчерашние заказы не пришли до 08:15 по графику → владелец перезапускает джоб, если не помогло — переключает на резервный источник и пишет статус.
Плохой тест:
В колонке price есть null. Если нет заранее описанного шага исправления, такой алерт только шумит.
Как понять, что тест полезен:
За квартал тест привел к фиксу хотя бы N раз и почти не давал ложных срабатываний. Если нет, перепишите или выключите.
Правило 2: тестируйте узлы с большим радиусом влияния
Не размазывайте силы по сотням таблиц. Найдите узлы влияния — точки, от которых зависят десятки витрин: каталоги товаров, справочники клиентов, платежные загрузки, ключевые объединения.
Сделайте короткий список топ 20 узлов по числу зависимых артефактов и дайте им усиленные проверки: корректность форматов, полнота, отсутствие дубликатов, стабильная структура, граничные значения.
Например, ошибка в «Каталоге товаров» ломает цены, остатки и маржинальность сразу в десяти отчетах. Один точный тест на каталог дает больше пользы, чем сотня проверок внизу по цепочке.
Правило 3: держите тесты в форме и соблюдайте гигиену
Тесты плодятся, стареют и начинают шуметь. Команда тонет в алертах и перестает реагировать.
Перед добавлением теста — паспорт из 3 строк:
Цель (что ловим) → Владелец (кто чинит) → Действие (что делает при срабатывании). Нет одной из строк — тест не ставим.
Лимит шума (alert budget):
Задайте потолок, например не больше 5 алертов в день на команду. Превысили — пауза на новые тесты, чистим шумные.
Ежемесячный разбор «польза vs шум». Для каждого теста смотрим:
Всего срабатываний.
Полезные (привели к фиксу).
Ложные/дубли.
0 полезных за 90 дней → удалить/переписать. 30% ложных → переписать (порог, окно ожидания, условия). Дубли ловят одно и то же → объединить в один.
Календарь исключений:
Заложите выходные поставщика, окна обслуживания, праздники. Для «свежести» в эти периоды увеличивайте таймаут, иначе получите плановые «ложные» алерты.
Жизненный цикл теста (и когда двигать):
Черновик → Активный → Проверенный → Устарел → Архив. Переводим в «Устарел», если 90 дней без пользы, в «Архив» — после замены новым.
Пример:
Тест «Аномально мало заказов по понедельникам» дал 12 срабатываний, из которых 10 ложных (праздники). Добавили календарь и окно ожидания до 10:00 — за месяц 3 срабатывания, 3 фикса, 0 ложных. Полезность выросла, шум исчез.
Мораль: устранять ошибки в производных — вычерпывать воду, а исправить ошибки в источнике данных — залатать течь.
Превращайте риск в источник доверия
Shalion — платформа екоммерс-аналитики: клиенты видят дашборды и выгрузки, по которым принимают решения. По сути, продукт — сами данные в реальном времени.
Когда данные — это продукт, доверие клиента становится главным KPI. Ошибки неизбежны: падают пайплайны, меняются схемы, растут лаги. Опасна не сама ошибка, а тишина, размытая ответственность и лавина пустых алертов.
Ниже — рабочие правила из практики Shalion: как сделать алерт действием, беречь внимание команды, заранее согласовать реалистичную надежность и мерить не только «как работает», но и «что под контролем». Это поможет превратить риск в источник доверия.
Правило 1: алерт должен вести к действию
Каждое уведомление — мини-план, а не крик «Все пропало». В алерте должны быть: что сломалось, где именно, кто владелец, кого задело, что делать (ссылки на инструкцию и цепочку зависимостей). Договоритесь про реакцию: подтверждение за 5 минут, через 10 — эскалация. Тогда алерты чинят, а не читают.
Правило 2: берегите внимание команды
Не рассылайте 150 уведомлений «Свежесть просела», если упал один пайплайн. Пусть прилетает один сигнал с корневой причиной, списком витрин и владельцем. Некритичные вещи пусть уходят в профильные каналы или в еженедельный разбор.
Правило 3: договоритесь про реальность заранее
Не все должно быть 99,9%. Для клиентской поверхности — да. Для внутренних витрин часто достаточно 95%. Это нормальная инженерная экономика: где риск ниже, там дорогая надежность не окупается. Важно проговорить это с клиентом до инцидентов.
В Shalion не прикидываются, будто ошибок не бывает. Они эти ошибки быстро находят, чинят и открыто сообщают клиенту. Так угроза клиентскому доверию становится источником этого доверия. Снимаем шляпу.
Правило 4: меряйте не только «как работает», но и «что вообще под контролем»
Зеленый дашборд может скрывать красные источники. Если вы смотрите лишь на прохождение проверок в витрине, то не видите, сколько критичных объектов вообще никем не контролируется, сбои проскочат — и ударят по доверию.
Держите рядом две метрики:
Coverage — доля важных объектов, которые вы реально проверяете.
Quality/SLA — доля проходящих проверок на этих объектах.
Правильно их читайте:
Coverage низкий, Quality высокий → иллюзия стабильности. Сначала расширьте покрытие на критичный апстрим (коннекторы, ключевые join), иначе следующий сбой не заметите.
Coverage высокий, Quality низкий → все видно, но работает плохо. Чините причины: договоритесь с источником, оптимизируйте пайплайн, сократите MTTR, усиливайте тесты там, где реально ломается.
Обе высокие → фиксируйте практики и поддерживайте уровень.
Бывает, что Coverage 60% при Quality 99% — это опасный комфорт: 40% цепочки остаются в слепой зоне. Доведите Coverage хотя бы до 90%, потом улучшайте Quality.
Если все проверенные данные в порядке, это значит, что вы не проверили все те, которые не в порядке.
Гайд не привязывается к инструментам, а учит принципам. Подходит командам из 5 человек и большим отделам. Полезен независимо от масштаба компании и зрелости дата-культуры.
Сохраните себе, расскажите коллегам.