Перейти к содержанию

Change Management

Обзор

Data contracts решают социотехнические проблемы. Технические инструменты (CI/CD, schema validation) — необходимое, но недостаточное условие. Change management — процесс согласования изменений между исторически разрозненными командами.

CODEOWNERS в GitLab

Файл contracts/CODEOWNERS определяет кто должен approve изменения в каждом контракте:

# Каждый контракт: owner + consumers approve
contracts/domains/sales/orders/* @sales-integration @analytics @data-science @bi
contracts/domains/warehouse/inventory/* @warehouse-team @logistics

Настройка GitLab:

  1. Settings → Merge request approvals → Require approval from CODEOWNERS
  2. Protected branches → main → Require merge request + approvals
  3. При изменении контракта GitLab автоматически назначает reviewers из CODEOWNERS

Роли в процессе

Data Producer

Команда, которая генерирует и владеет данными. Отвечает за:

  • Schema (структура данных)
  • Quality (правила валидации)
  • SLA (freshness, availability)
  • Migration при breaking changes

Data Consumer

Команда, которая использует данные. Имеет право:

  • Approve/reject breaking changes через MR
  • Создавать Issues при обнаружении проблем с качеством
  • Запрашивать новые поля или изменения в schema

Platform Team (Kruma)

Предоставляет инструменты, инфраструктуру и guardrails:

  • CI/CD pipeline для валидации контрактов
  • Шаблоны и документацию
  • Monitoring и alerting инфраструктуру
  • НЕ отвечает за качество данных конкретного домена

Maturity Curve

Внедрение data contracts проходит через три уровня зрелости:

Уровень Описание Признаки
Awareness Команды знают что контракты существуют Документация доступна, проведены демо, есть pilot
Ownership Каждый data asset имеет явного owner Consumers зарегистрированы, CODEOWNERS настроен, MR flow работает
Governance Автоматический enforcement через CI/CD Метрики adoption, алерты на нарушения, breaking changes ловятся в CI

Perception Gaps

Ключевая проблема — разное восприятие данных разными командами:

  • Software engineers видят данные как побочный продукт: средство для CRUD операций, база данных обслуживает приложение
  • Data engineers видят данные как продукт: основная ценность для аналитики, ML, отчётности

Контракты закрывают этот gap через формализацию ожиданий: producer явно видит кто зависит от его данных и какие поля используются.

Ключевой принцип: НЕ обвинять software engineers, а показать impact их изменений. Когда разработчик видит что переименование колонки сломает 3 downstream системы — мотивация к аккуратности появляется естественно.

Kotter's 8 Steps для внедрения

  1. Establishing urgency — показать стоимость инцидентов. Сколько стоил последний data incident? Сколько часов потратили на расследование?
  2. Creating guiding coalition — найти champion в каждой команде. Один энтузиаст в команде продвигает идею эффективнее чем приказ сверху.
  3. Developing vision — контракты = меньше инцидентов + быстрее delivery. Не "ещё одна бюрократия", а "защита от поломок".
  4. Communicating vision — демо, внутренние talks, документация. Показать конкретный пример: "вот MR, вот как CI поймал breaking change".
  5. Empowering broad-based action — простые шаблоны, CI/CD автоматизация, поддержка platform team. Снизить барьер входа до минимума.
  6. Generating short-term wins — первый steel thread, первый пойманный breaking change в CI. Конкретный результат за первые недели.
  7. Consolidating gains — метрики adoption, расширение на новые домены. Показать trend: было N инцидентов, стало M.
  8. Anchoring in culture — контракты как часть Definition of Done. Новый data asset = контракт по умолчанию.

См. также