Две команды используют разное определение "активного пользователя" в своих SQL-запросах, что приводит к расходящимся выводам о состоянии продукта. Как выстроить governance-процесс для версионирования и синхронизации определений метрик?

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

Governance нужен не ради каталога, а ради управляемого изменения смысла числа. Начните с нескольких метрик, по которым уже возникают споры, и свяжите документацию с исполняемым SQL или semantic layer.

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

Версия должна фиксировать не только текст запроса, но и бизнес-смысл: кто считается активным, временное окно, часовой пояс, зерно и правила исключения. Ломающая смена определения создаёт новую версию или явную дату перехода.

Для каждого потребителя полезно хранить используемую версию, чтобы изменение не создавало тихий скачок. Автотесты могут проверять уникальность зерна, допустимые NULL и контрольные примеры.

Пример кода

metric_versions.sqlКопировать

SELECT metric_name, metric_version, owner_team, effective_from, definition_hash
FROM governance.metric_registry
WHERE metric_name = 'active_user'
ORDER BY effective_from DESC;

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

• Назначьте владельца. Он отвечает за смысл, ревью и уведомление потребителей, но не принимает решение без стейкхолдеров.
• Сделайте путь простым. Pull request с шаблоном изменения эффективнее тяжёлого комитета.
• Мигрируйте явно. Дайте период параллельного расчёта старой и новой версии.

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

• Каталог без обязательного использования. Локальные копии SQL продолжают расходиться.
• Тихая правка задним числом. Исторический дашборд меняется без отметки методологии.
• Governance для всего сразу. Избыточный охват создаёт бюрократию и обход процесса.