Контракты на данные: как команды договариваются об интеграции
Почему большинство проблем с интеграцией данных между командами - это проблемы договорённостей, а не технологий.
В компаниях с несколькими командами или системами рано или поздно возникает один и тот же сценарий. Команда А передаёт данные команде Б. Через некоторое время команда Б жалуется: данные пришли в другом формате, поля переименованы, часть записей пропала. Команда А отвечает, что ничего не меняла - или что изменения были необходимы. Разбор занимает дни.
Я видел этот сценарий десятки раз. И каждый раз корень не в технологии. Корень в том, что между командами не было явной договорённости о том, что передаётся, в каком формате, с какой частотой и что происходит при изменениях.
Именно это решает концепция data contracts - контрактов на данные.
Что такое контракт на данные
Контракт на данные - это явное соглашение между производителем данных и их потребителем. В него входят:
- структура данных: поля, типы, обязательность;
- семантика: что означает каждое поле, как оно заполняется;
- частота и условия обновления;
- SLA на доступность и задержку;
- процедура изменений: как производитель уведомляет о планируемых изменениях и каков срок предупреждения.
Это может быть оформлено как техническая спецификация, как документ в вики, как schema в системе каталога данных - форма зависит от зрелости инфраструктуры. Главное - это явная и живая договорённость, а не устная или подразумеваемая.
Почему это обычно не делается
Самая частая причина - контракт кажется избыточным бюрократией, пока всё работает. "Мы и так знаем, что туда попадает" - типичный ответ команды, которая производит данные.
Проблема в том, что "знают" - неформально, неполно и разные люди по-разному. Стоит кому-то уйти или потребителей стать больше одного - и неявные знания начинают расходиться с реальностью.
Вторая причина - контракты воспринимаются как ограничение гибкости производителя. "Если я должен предупреждать за две недели, я не смогу быстро итерировать". Это реальное напряжение, но оно не отменяет необходимость договорённости - оно требует выбрать разумный баланс.
Как это выглядит на практике
Начинать не нужно с формальной системы. Достаточно простого документа для каждого критического потока данных:
- источник и назначение;
- список полей с типами и описанием;
- что гарантирует производитель;
- как он уведомляет об изменениях.
Когда это живёт в явном виде, несколько вещей меняются. Новые потребители могут самостоятельно разобраться в данных. Изменения планируются заранее, а не вносятся внезапно. Инциденты разбираются быстрее, потому что есть контракт, с которым можно сравнить.
Где начать
Несколько вопросов для оценки текущего состояния:
- Есть ли в вашей компании документация на ключевые потоки данных между системами или командами?
- Кто уведомляется, когда структура данных меняется? Как быстро?
- Есть ли случаи, когда изменение в одной системе незапланированно сломало что-то в другой за последний год?
- Когда новый разработчик или аналитик приходит в проект, есть ли место, где описана структура данных, или это знание передаётся устно?
Если большинство ответов вызывают дискомфорт - хорошее время начать с документирования двух-трёх самых критических потоков. Не идеально, просто явно.