Кто владеет пайплайном данных, когда ответ - никто
В большинстве компаний пайплайны данных построены тем, кто нуждался в данных, не принадлежат никому и используются всеми. Это системная хрупкость, а не техническая проблема.
Разговор о пайплайнах данных в компаниях обычно начинается с технического вопроса: какой инструмент использовать, как обрабатывать сбои, как планировать запуски. Это реальные вопросы, но это второй разговор. Первый разговор: кто этим владеет?
В большинстве компаний, которые я смотрю, честный ответ - никто. Пайплайн был построен разработчиком, которому нужны были данные для конкретной фичи. Тот разработчик с тех пор перешёл в другую команду. Пайплайн запускается каждую ночь, иногда что-то ломается, и на оповещение откликается тот, кто оказался рядом в момент срабатывания - не владелец данных, не владелец потребляющего приложения и, как правило, не человек, понимающий, что пайплайн делает.
Это не проблема инструмента. Это проблема модели ответственности.
Как пайплайны остаются бесхозными
Пайплайны строятся постепенно. Первая версия проста: забрать данные из источника, немного трансформировать, загрузить в аналитическую таблицу. Работает. Потом вторая команда обнаруживает таблицу и начинает от неё зависеть. Потом третья. Потом кто-то добавляет трансформацию под новое требование, и теперь у пайплайна три потребителя с разными ожиданиями от того, как должен выглядеть результат.
На протяжении всей этой истории ни разу не принималось решение о том, кто отвечает за пайплайн. Это происходило органически. А органические структуры ответственности, как правило, означают: все от него зависят, но никто не несёт ответственности, когда он ломается.
Что «ответственность» означает на практике
Ответственность за пайплайн - это не про то, кто написал исходный код. Это означает:
- Кто-то рецензирует изменения перед выкаткой в продакшн.
- Кто-то решает, может ли меняться схема результата, и сообщает об этом потребителям.
- Кто-то отвечает за то, что пайплайн работает - не только за отладку когда он упал.
- Кто-то определяет, как выглядит «корректный» результирующий набор данных.
Последний пункт недооценивают. Большинство проблем с качеством данных не обнаруживаются самим пайплайном - задание выполняется успешно, но результат незаметно неправильный, потому что изменилось какое-то предположение выше по цепочке. Владелец - это человек, которому достаточно важно определить, что значит «корректно», и убедиться, что это по-прежнему так.
Простая модель, которая работает
Я видел команды, которые двигаются вперёд с очень лёгкой моделью.
У каждого пайплайна есть именованный владелец - конкретный человек, не команда. Этот человек указан в поддерживаемом документе рядом с информацией об источнике пайплайна, назначении, расписании и списком известных потребителей.
Любое изменение схемы результата требует, чтобы владелец уведомил всех перечисленных потребителей. Это может быть сообщение в Slack или письмо - не обязательно формальный процесс.
Когда пайплайн ломается, оповещение идёт сначала владельцу. Он может эскалировать, но по умолчанию он - первый контакт.
Более трудная часть
Труднее всего - что делать с существующими пайплайнами без владельца. Самый практичный подход, который я видел: когда пайплайн ломается и кто-то чинит его, этот человек становится владельцем на следующие 90 дней. Это заставляет ответственность следовать за реальными знаниями, что обычно и является правильным критерием.
Это также создаёт стимул строить пайплайны, которые легко понять и починить - потому что разработчик знает, что именно ему могут позвонить потом.