Команда разработки регулярно меняет формат событий без предупреждения аналитиков, что ломает дашборды. Предложи решение на уровне процесса/архитектуры и обсуди его издержки?

Короткий ответ

Единого рецепта нет — распространённое решение — ввести «контракт данных» (data contract) между командой-источником и аналитикой: формальная схема событий с версионированием и обязательным уведомлением/review перед breaking change, но это добавляет процессный overhead и может восприниматься инженерами как бюрократия, замедляющая релизы.

Как это работает подробнее

Data contract фиксирует ожидаемую схему события (обязательные поля, типы, допустимые значения) в машиночитаемом виде (например, JSON Schema), и CI инженерной команды проверяет соответствие контракту перед деплоем; несовместимые изменения требуют явного версионирования события (purchase_v2) вместо тихой замены purchase.

Пример кода

event-schema.jsonКопировать

// Пример JSON Schema контракта для события purchase
{
  "type": "object",
  "required": ["event_name", "user_id", "amount", "currency"],
  "properties": {
    "event_name": {"const": "purchase"},
    "amount": {"type": "number", "minimum": 0},
    "currency": {"type": "string", "enum": ["RUB", "USD", "EUR"]}
  }
}

Что использовать на практике

• На практике. Внедрение начинают с критичных для бизнеса событий (например, purchase, signup), а не со всех сразу, и встраивают проверку контракта в пайплайн CI/CD инженерной команды, чтобы breaking change не мог попасть в прод без уведомления аналитиков или автоматического провала сборки.
• Проверка. CI-пайплайн инженерной команды прогоняет пример события перед деплоем против схемы; невалидное событие (например, amount как строка) должно провалить сборку, а не тихо попасть в прод.

Подводные камни

• Частые ошибки. Вводят контракты сразу для всех событий без расстановки приоритетов, что требует огромных первоначальных усилий и быстро забрасывается; либо делают контракт чисто документальным (страница в вики) без технической проверки, из-за чего он не предотвращает инцидент, а лишь позволяет быстрее его объяснить постфактум.
• Компромисс. Жёсткий технический контракт с CI-проверками снижает число инцидентов, но замедляет релизы инженерной команды и требует согласования процесса между командами с разными приоритетами (скорость фич vs стабильность данных). Более лёгкий вариант — только уведомление/чейндж-лог без технической блокировки — дешевле внедрить, но не гарантирует соблюдение и полагается на дисциплину людей. Выбор зависит от того, насколько критичны для бизнеса последствия сломанного трекинга (финансовая отчётность vs внутренний дашборд) и от переговорной позиции аналитики относительно инженерной команды.