Контракты на данные между командами: зачем это нужно и как это работает
Когда данные пересекают границы команд без явных договорённостей, это заканчивается поломками. Разбираю, что такое контракт на данные и когда он нужен.
Представьте ситуацию: команда аналитики строит отчёт, опираясь на таблицу в базе данных, которую ведёт команда разработки продукта. Разработчики переименовывают поле - у них была причина, это было внутреннее решение. Отчёт ломается. Это обнаруживают в пятницу вечером перед квартальным советом директоров.
Ни одна из команд не сделала ничего неправильного в рамках своей зоны ответственности. Проблема в том, что границы зон ответственности не были явно определены.
Это и есть задача, которую решают контракты на данные.
Что такое контракт на данные
Контракт на данные - это явное соглашение между командой, которая производит данные, и командой, которая их потребляет. Он описывает:
- какие поля и типы данных доступны;
- каковы гарантии свежести (как часто обновляется, с какой задержкой);
- что считается нарушением контракта (изменение схемы, пропуск обновления);
- кто получает уведомление при изменении;
- как выглядит процесс согласования изменений.
Это не юридический документ. Это операционное соглашение - часто просто файл в репозитории, который читают обе команды.
Когда это становится нужным
В небольшой команде, где все сидят в одном Slack-канале и разговаривают каждый день, формальные контракты избыточны. Один вопрос в чате решает всё.
Ситуация меняется, когда:
- данными пользуются несколько команд, которые не общаются напрямую;
- производители и потребители данных работают в разных ритмах (продукт выпускает релиз каждые две недели, аналитика строит модели раз в квартал);
- данные используются в автоматических процессах, которые не могут позвонить и уточнить;
- компания растёт и команды специализируются.
Момент, когда контракт нужен, - это момент, когда "подожди, я спрошу у Миши" перестаёт работать как механизм координации.
Что бывает без контрактов
Без явных соглашений возникает несколько устойчивых паттернов.
Команда-потребитель боится изменений. Любое обновление схемы или структуры данных - потенциальная поломка. Команда строит защитные механизмы, дублирует данные, создаёт буферные слои - всё это технический долг, который накапливается.
Команда-производитель не знает, что изменять нельзя. Для них это "внутренняя таблица". Для потребителей - производственная зависимость.
Отладка занимает много времени. Когда что-то ломается, нет понимания, где проблема и чья ответственность. Команды обвиняют друг друга или тратят часы на поиск источника.
Практический минимум
Полноценная система управления контрактами на данные - это зрелая инфраструктура. Для большинства компаний достаточно начать с малого.
Задокументируйте текущие зависимости. Какие команды используют какие данные? Где это нигде не записано? Это уже первый шаг к видимости.
Введите уведомления об изменениях схемы. Прежде чем думать о контрактах, просто договоритесь: команда, которая меняет структуру данных, уведомляет потребителей за N дней.
Определите, какие данные являются "публичными". Не все внутренние данные должны быть стабильными для внешних потребителей. Разграничение "внутренние данные" и "данные для других команд" - уже значительное улучшение.
Три вопроса для руководителя
Если вы хотите понять, нужны ли вашей компании контракты на данные, задайте эти вопросы:
- Если команда А меняет структуру своей базы данных, как узнает команда Б, которая её использует?
- Были ли у вас инциденты, когда что-то сломалось из-за изменений данных, о которых никто не предупредил?
- Есть ли у вас данные, на которые опираются автоматические процессы или отчёты для руководства?
Если на второй вопрос ответ "да" - контракты на данные решат именно эту проблему.