Тема: Часть 12. Контракты данных: ODCS и контрактные проверки dbt
Уровень сложности: Средний
Расчётное время изучения: 3-4 часа (теория ~1.5 часа, практика ~2 часа, разбор кейсов ~0.5 часа)
Предварительные требования: Уверенное владение SQL (SELECT, JOIN, GROUP BY, оконные функции)
Базовое понимание dbt (модели, материализации, sources, refs)
Знание принципов построения витрин данных (grain, slowly changing dimensions)
Понимание жизненного цикла разработки ПО (PR, ревью, CI/CD)
Базовое знакомство с YAML-синтаксисом
Понятие о data quality и тестировании данных
Цели обучения: Различать два уровня контракта данных: продуктовый (ODCS) и модельный (dbt schema.yml) и понимать, за что отвечает каждый из них
Идентифицировать три типа дрейфа контракта (схемный, семантический, процессный) и формулировать последствия для потребителя
Составлять минимальную заметку влияния на контракт при изменении модели по заданному шаблону
Связывать обязательства ODCS с конкретными dbt-тестами, singular-тестами и ручными фактами ревью, оценивая покрытие
Формулировать промпт для LLM-ассистента (например, Qwen Code) для поиска дрейфа и разрывов в тестовом покрытии без модификации файлов
Обзор: Контракт данных — это проверяемый слой между продуктовым обещанием витрины и её SQL-реализацией. В рамках спецификации SDD Data контракт не является декоративным YAML-файлом, а представляет собой формальное соглашение о схеме, качестве, SLA и политике ломающих изменений. Глава рассматривает два уровня контракта: ODCS (Open Data Contract Standard) как технический контракт дата-продукта и контракт модели dbt как форма конкретной модели. Особое внимание уделяется дрейфу контракта — ситуации, когда код модели меняется, а контракт остаётся прежним, что приводит к тихому расхождению смысла данных у потребителя. Изучаются три типа дрейфа (схемный, семантический, процессный), методика их обнаружения и роль dbt-тестов как доказательной базы контракта. Практическая часть строится вокруг Qwen-запроса, который сравнивает ODCS-спецификацию, описание модели, schema.yml и SQL-код, формируя минимальную заметку влияния на контракт для использования в описании PR.
Ключевые концепции: Odcs (open data contract standard): Стандарт машинно-читаемого описания технического контракта дата-продукта. В рамках курса представлен файлом specs/customer_360_contract.odcs.yaml. Содержит обещание о схеме (поля, типы, обязательность), качестве (SLA на свежесть, полноту, уникальность), политике PII и описании ломающих изменений. Это контракт уровня продукта: он отвечает на вопрос «что обещает витрина внешнему миру».
Контракт модели dbt: Описание формы конкретной dbt-модели в models/schema.yml: имя, описание, колонки с типами, тестами и ссылками на документацию. Это контракт уровня модели: он отвечает на вопрос «как именно реализовано обещание в этом проекте». В учебном примере contract.enforced: true не включается, чтобы не смешивать первый проход с ограничениями адаптера; в продакшене включается там, где материализация это поддерживает.
Два уровня контракта и их разделение: ODCS описывает продукт, schema.yml и тесты — конкретную модель. Ни один слой не заменяет другой. Если оставить только dbt-тесты, можно получить зелёную модель с неправильным смыслом. Если оставить только ODCS, можно получить красивый контракт без доказательств его исполнения.
Дрейф схемы: Первый тип дрейфа контракта. Возникает, когда в модели появляются, удаляются или переименовываются поля, а спецификация ODCS не обновляется. Пример: в mart_customer_360 добавлена колонка product_code, но ODCS продолжает перечислять прежний набор полей. dbt может пройти все тесты, а потребитель получит структуру, не описанную в контракте.
Семантический дрейф: Второй тип дрейфа. Поле остаётся в схеме, но его смысл меняется. Например, метрика risk_event_count_7d начинает считаться за другой временной интервал или включать события иного типа. Технически схема цела, бизнес-смысл изменился. Это самый опасный вид дрейфа, потому что автоматические тесты его обычно не ловят.
Процессный дрейф: Третий тип дрейфа. validation.md, отчёт ревьюера или иной артефакт процесса не отражает фактическое изменение модели. Например, ревьюер одобрил изменение, но забыл обновить матрицу покрытия тестами или запись в changelog. Формально процесс прошёл, фактически доказательная база контракта потеряна.
Доказательная база контракта: Принцип: если ODCS говорит, что поле обязательно (например, not_null), то должен существовать хотя бы один dbt-тест, singular-тест или ручной факт ревьюера, подтверждающий это свойство. Контракт без доказательств остаётся обещанием, которое нельзя ни подтвердить, ни опровергнуть.
Минимальная заметка влияния на контракт: Структурированный блок markdown, который должен появляться в описании каждого PR, затрагивающего модель с контрактом. Содержит шесть полей: изменённые поля, ломающее изменение, влияние на PII, влияние на SLA, покрытие проверками, нужно ли подтверждение человеком. Является доказательством того, что автор PR осознал контрактные последствия.
Grain как часть интерфейса: Принцип, по которому grain (например, «одна строка на customer_id») является частью публичного интерфейса витрины так же, как и список колонок. Изменение grain — ломающее изменение, даже если схема остаётся прежней. Это центральное понятие для понимания семантического дрейфа.
Qwen-запрос для поиска дрейфа: Заданный промпт для LLM-ассистента, который сравнивает четыре артефакта: specs/customer_360_contract.odcs.yaml, specs/models/mart_customer_360.md, models/schema.yml и models/marts/mart_customer_360.sql. Ассистент должен найти дрейф и разрывы в покрытии тестами, при этом запрещено менять файлы. Результат — аналитическая заметка для ревьюера.
Важные даты: Появление стандарта odcs: Спецификация ODCS (Open Data Contract Standard) активно развивается сообществом с 2023 года как попытка унифицировать машинно-читаемые контракты данных по аналогии с OpenAPI для REST.
Внедрение dbt contracts: Функция contract.enforced в dbt появилась в версии 1.5 (конец 2023 года) и стабилизировалась в 1.6+, поддерживая материализации table и incremental для ряда адаптеров.
Концепция data mesh (zhamak dehghani): С 2019-2020 годов концепция data mesh выдвинула контракты данных как обязательный элемент data-as-a-product, что повлияло на появление ODCS и dbt-контрактов.
Эволюция понятия data contract: До 2022 года термин «data contract» использовался скорее маркетингово; с 2023 года стал формализованным инженерным артефактом в крупных компаниях (GoCardless, Shopify, Netflix).
Практические упражнения: Название: Сопоставление обязательств ODCS и dbt-тестов
Проблема: Вам даны два фрагмента. Фрагмент A — выдержка из specs/customer_360_contract.odcs.yaml:
columns:
- name: customer_id
dataType: integer
required: true
primaryKey: true
- name: risk_event_count_7d
dataType: integer
required: true
- name: email
dataType: string
required: false
classification: PIIФрагмент B — выдержка из models/schema.yml:
models:
- name: mart_customer_360
columns:
- name: customer_id
tests:
- unique
- not_null
- name: risk_event_count_7d
tests:
- not_null
- name: email
# тестов нетВыпишите обязательные поля и укажите, каким dbt-тестом, singular-тестом или ручным фактом ревьюера каждое из них покрыто. Для полей без покрытия сформулируйте singular-тест или действие ревьюера.
Решение: Шаг 1. Определяем обязательные поля по ODCS: customer_id (required, primaryKey) и risk_event_count_7d (required). Поле email не обязательное.
Шаг 2. Сопоставляем с тестами в schema.yml:
- customer_id: покрыт тестами unique и not_null в schema.yml. Оба обязательства ODCS (required + primaryKey) закрыты автоматическими тестами.
- risk_event_count_7d: покрыт тестом not_null. Обязательство required закрыто, но не доказано, что значения разумны (например, ≥0). Требуется дополнительный singular-тест на диапазон.
Шаг 3. Для поля email (классифицировано как PII в ODCS, но не покрыто тестами): требуется либо singular-тест на отсутствие email в неожиданных местах, либо явный факт ревьюера: «email не используется в mart, колонка зарезервирована». Этот факт фиксируется в validation.md.
Шаг 4. Итоговая таблица покрытия:
| Поле | Обязательство ODCS | Покрытие |
|---|---|---|
| customer_id | required + primaryKey | unique + not_null ✅ |
| risk_event_count_7d | required | not_null ✅, но нет проверки диапазона ⚠️ |
| PII | нет тестов ⚠️, требуется singular-тест или факт ревьюера |
Сложность: intermediate
Название: Классификация типа дрейфа
Проблема: Для каждой из четырёх ситуаций определите тип дрейфа (схемный, семантический, процессный) и обоснуйте, является ли изменение ломающим.
Ситуация 1: В mart_customer_360 добавлена nullable-колонка product_code. Ситуация 2: Метрика total_revenue в mart_finance переименована в net_revenue и теперь вычитает возвраты. Ситуация 3: Ревьюер одобрил PR с изменением grain, но не обновил validation.md. Ситуация 4: В спецификации ODCS поле email помечено как PII, но в schema.yml оно удалено, а в SQL осталось.
Решение: Ситуация 1: схемный дрейф. Колонка появилась — ODCS и schema.yml расходятся. Изменение НЕ ломающее для существующих потребителей (они просто игнорируют новую колонку), но потенциально семантически значимое: product_code может восприниматься как новая бизнес-метрика. Требуется явное описание в PR.
Ситуация 2: семантический дрейф + схемный. Поле переименовано (схемный) и его смысл изменился (вычитание возвратов, семантический). Это ЛОМАЮЩЕЕ изменение: любой дашборд, который ссылался на total_revenue, либо сломается, либо начнёт показывать другие числа без видимой ошибки.
Ситуация 3: процессный дрейф. Изменение прошло в код, ревьюер одобрил, но артефакт процесса (validation.md) не обновлён. Само изменение может быть любым, но доказательная база потеряна. Ломающим считается, если изменение контрактно значимо, но валидация не зафиксирована.
Ситуация 4: схемный + процессный дрейф. ODCS говорит, что PII-поле есть; schema.yml говорит, что нет; SQL говорит, что есть. Три источника расходятся. Это ломающее изменение с точки зрения процесса: потребитель, читающий schema.yml, решит, что email отсутствует, и может не применять маскирование.
Сложность: intermediate
Название: Составление минимальной заметки влияния
Проблема: Вы — автор PR. Изменение: в mart_customer_360 добавлена nullable-колонка middle_name (отчество), grain не менялся, customer_id остаётся primary key, новые тесты не добавлялись, PII-политика не затронута (middle_name классифицировано как PII в ODCS). Заполните минимальную заметку влияния на контракт по шаблону из главы.
Решение: ```markdown Изменённые поля: добавлена nullable-колонка middle_name (PII) Ломающее изменение: нет (nullable, не меняет grain, существующие потребители не затронуты) Влияние на PII: в mart добавлена PII-колонка middle_name; требуется проверка, что downstream-потребители учитывают классификацию; в schema.yml у поля должен быть classification: PII и тест или singular-правило, запрещающее распространение без маскирования Влияние на SLA: нет (freshness и полнота не затронуты) Покрытие проверками: для middle_name добавлен singular-тест, проверяющий, что колонка присутствует только в marts с уровнем доступа confidential; customer_id по-прежнему покрыт unique + not_null Нужно подтверждение: да, требуется явное подтверждение data steward, так как добавлена новая PII-колонка
Ключевой момент: даже не-ломающее изменение требует подтверждения человека, если оно затрагивает PII или потенциально меняет ожидания потребителей.
Сложность: intermediate
Название: Формулировка Qwen-промпта под конкретную модель
Проблема: У вас есть модель mart_orders с контрактом в specs/orders_contract.odcs.yaml. Сформулируйте промпт для Qwen Code, который проверит дрейф контракта для этой модели. Промпт должен: перечислить все четыре артефакта для сравнения, явно указать, что файлы менять нельзя, и попросить выдать структурированный результат.
Решение: ```text
Сравни specs/orders_contract.odcs.yaml,
specs/models/mart_orders.md, models/schema.yml и
models/marts/mart_orders.sql.
Найди дрейф контракта и разрывы в покрытии тестами.
Файлы не меняй.
Выдай результат в виде:
1. Список обязательных полей по ODCS и их покрытие тестами.
2. Список полей, присутствующих в SQL, но не описанных в ODCS.
3. Список полей, описанных в ODCS, но отсутствующих в SQL.
4. Обнаруженные семантические несоответствия (изменение grain, переименование метрик, изменение логики расчёта).
5. Минимальная заметка влияния на контракт по шаблону из главы.Ключевые элементы правильного промпта: явный список файлов, явный запрет на модификацию, структурированный вывод, привязка к понятиям главы (drift, покрытие, grain).
Сложность: intermediate
Название: Распознавание ломающего изменения
Проблема: Даны пять изменений в моделях с контрактом. Для каждого определите, является ли оно ломающим и требуется ли подтверждение data steward.
- Переименование колонки status в order_status.
- Добавление nullable-колонки discount_amount.
- Изменение grain с «одна строка на customer_id» на «одна строка на (customer_id, month)».
- Удаление колонки legacy_score, которая не использовалась 6 месяцев.
- Изменение формулы расчёта ltv_90d с sum(amount) на sum(amount) - sum(refund).
Решение: 1. ЛОМАЮЩЕЕ. Переименование ломает любой дашборд, ссылающийся на status. Требуется подтверждение steward и миграционный период.
- НЕ ломающее (формально). Nullable-колонка не ломает существующих потребителей. Но если discount_amount воспринимается как новая бизнес-метрика, требуется уведомление и, возможно, подтверждение product owner.
- ЛОМАЮЩЕЕ. Изменение grain — самый опасный вид ломающего изменения: количество строк меняется, downstream-агрегаты выдают другие числа. Требуется обязательное подтверждение steward и продуктовое согласование.
- УСЛОВНО ЛОМАЮЩЕЕ. Если legacy_score действительно не использовался, удаление безопасно. Но «не использовалось 6 месяцев» — слабое доказательство: дашборды могли быть заархивированы, а не удалены. Требуется подтверждение product owner.
- ЛОМАЮЩЕЕ. Семантическое изменение: числа меняются без переименования колонки. Это худший случай — тесты могут проходить, потребители видят другие данные. Требуется подтверждение steward, обязательное уведомление потребителей, обновление ODCS и тестов на диапазон.
Сложность: advanced
Кейсы: Название: Добавление «безопасной» колонки сломало отчётность
Сценарий: Финтех-компания, ~200 сотрудников, 12 marts в dbt. Витрина mart_customer_360 используется командой риск-менеджмента для ежедневного отчёта по клиентам с высоким риском. Контракт в ODCS описывает grain как «одна строка на customer_id» и перечисляет 14 полей, среди которых risk_event_count_7d (обязательное). Дашборд в Tableau агрегирует по customer_id и считает долю клиентов с risk_event_count_7d > 5.
Задача: Аналитик добавил в модель nullable-колонку product_code (код основного продукта клиента), счёл изменение безопасным и оформил PR без обновления ODCS. dbt-тесты прошли, ревьюер одобрил без вопросов. Через три недели команда риск-менеджмента обнаружила, что отчёт по «клиентам с высоким риском» теперь включает в 2.3 раза больше записей. Расследование показало: в Tableau-вычислении случайно использовали product_code как дополнительный ключ группировки, и grain отчёта неявно сменился с customer_id на (customer_id, product_code).
Решение: Команда внедрила три изменения процесса. Во-первых, в шаблон PR добавили обязательный блок «Заметка влияния на контракт» по образцу из главы. Во-вторых, настроили Qwen Code как автоматическую проверку в CI: для каждого PR, затрагивающего модель с ODCS, бот сравнивает четыре файла и оставляет комментарий с подозрениями на дрейф. В-третьих, ввели правило: если PR добавляет nullable-колонку в модель с контрактом, ревьюер должен явно подтвердить, что новая колонка не меняет grain и не воспринимается как бизнес-метрика.
Результат: За первый квартал после внедрения бот обнаружил 7 потенциальных дрейфов до мержа, из них 2 оказались реальными семантическими проблемами, которые были бы пропущены обычными dbt-тестами. Среднее время ревью PR сократилось на 18% за счёт того, что авторы стали заполнять заметку влияния самостоятельно и ревьюеры не тратили время на выяснение «а что эта колонка означает».
Извлечённые уроки: Nullable-колонка не равна безопасному изменению: если она воспринимается как новый ключ группировки, grain меняется неявно
Автоматические dbt-тесты не ловят изменения grain — для этого нужен либо отдельный тест на уникальность ключа, либо явный факт ревьюера
Заметка влияния на контракт работает как чек-лист: сам факт её заполнения заставляет автора PR подумать о потребителе
Связанные концепции: Схемный дрейф
Семантический дрейф
Grain как часть интерфейса
Минимальная заметка влияния
Qwen-запрос для поиска дрейфа
Название: Молчаливое изменение формулы метрики
Сценарий: E-commerce платформа, витрина mart_finance_daily используется финансовой командой для расчёта выручки. Метрика gross_revenue описана в ODCS как «сумма стоимости всех успешно завершённых заказов за день». SQL реализует это как SUM(amount) FROM fct_orders WHERE status = 'completed'. Витрина потребляется тремя дашбордами в Looker и одним ML-пайплайном для прогноза выручки.
Задача: Инженер изменил формулу, добавив фильтр on NOT refunded_at IS NULL, чтобы «не учитывать возвраты в валовой выручке». Изменение прошло ревью как «небольшое улучшение логики». ODCS не обновили, schema.yml не тронули, dbt-тесты прошли. Через месяц финансовая команда обнаружила расхождение между отчётом витрины и отчётом из ERP-системы на 12%. Расследование выявило, что часть возвратов ранее учитывалась в gross_revenue, а теперь — нет.
Решение: Команда остановила изменение, откатила SQL до прежней формулы, обновила ODCS и добавила новую метрику net_revenue с явным описанием «сумма стоимости успешно завершённых и не возвращённых заказов». В schema.yml добавили отдельный тест, проверяющий, что gross_revenue ≥ net_revenue за любой день. В шаблон PR добавили предупреждение: «Если изменение SQL затрагивает расчёт метрик, описанных в ODCS, изменение считается ломающим и требует подтверждения data steward».
Результат: За шесть месяцев после инцидента не было ни одного случая тихого изменения метрик. ML-пайплайн прогноза выручки продолжил работу без сбоев. Команда формализовала политику: «любое изменение формулы метрики = ломающее изменение = требует major-версии контракта и уведомления всех потребителей за 2 недели».
Извлечённые уроки: Семантический дрейф опаснее схемного: схема цела, тесты зелёные, числа молча меняются
Улучшение логики ≠ безопасное изменение, если логика описана в контракте
Контракт должен явно перечислять метрики и их формулы, иначе любая «оптимизация» — это дрейф
Связанные концепции: Семантический дрейф
Ломающее изменение
ODCS как обязательство
Доказательная база контракта
Название: ODCS без тестов: красивый контракт мёртвого продукта
Сценарий: Страховая компания, легаси-проект. Аналитик data governance команды создал ODCS-спецификации для 30 витрин, торжественно закоммитил их в репозиторий и отчитался руководству о «внедрении data contracts». Витрины продолжали разрабатываться как раньше: без привязки к ODCS, schema.yml описывал только малую часть колонок, тестов было мало.
Задача: Через полгода аудит показал, что 18 из 30 ODCS-спецификаций полностью устарели: поля переименованы, метрики пересчитаны, grain изменился. При этом формально контракты существовали, отчётность перед регулятором выглядела «зелёной». Юридический и комплаенс-отделы использовали ODCS как доказательство «у нас всё под контролем», но фактически потребители получали данные, не соответствующие контракту.
Решение: Команда внедрила связь «обязательство ODCS → dbt-тест или singular-тест или факт ревьюера». Для каждого обязательного поля в ODCS был создан хотя бы один тест. В CI добавили проверку: если в ODCS указано required: true, в schema.yml должен быть тест not_null. Если в ODCS указано classification: PII, в schema.yml или singular-тесте должно быть явное правило обращения с этим полем. Все 18 устаревших спецификации были либо обновлены до реального состояния витрин, либо помечены как deprecated с явным SLA до отключения.
Результат: За квартал 100% обязательных полей в актуальных ODCS получили покрытие тестами. Аудит регулятора прошёл без замечаний по data contracts. Команда сформулировала принцип: «ODCS без доказательной базы — это не контракт, это маркетинг».
Извлечённые уроки: ODCS сам по себе не имеет ценности: ценность появляется, когда каждое обязательство проверяемо
Контракт должен быть синхронизирован с реализацией, иначе он становится источником ложной уверенности
Связь ODCS ↔ schema.yml ↔ SQL должна быть автоматизирована в CI, иначе дрейф неизбежен
Связанные концепции: Доказательная база контракта
Два уровня контракта
Процессный дрейф
Связь контракта и тестов
Советы по изучению: Читайте изменения как ревьюер, а не как автор. Автор видит, «стал ли SQL лучше», ревьюер — «осталось ли обещание тем же». Переключайте перспективу при каждом PR с моделью, имеющей контракт.
Заучите шесть полей минимальной заметки влияния и держите их в голове как чек-лист: изменённые поля, ломающее изменение, влияние на PII, влияние на SLA, покрытие проверками, нужно ли подтверждение. Это самый практический навык главы.
Различайте «тест прошёл» и «контракт соблюдён». Тест проверяет одно свойство одной колонки в одной точке времени. Контракт — это совокупность обязательств на жизненном цикле витрины. Зелёные тесты не означают, что контракт жив.
Практикуйте формулировку Qwen-промптов: возьмите свою рабочую модель и попросите LLM-ассистента сравнить ODCS, описание модели, schema.yml и SQL. Оцените, какие дрейфы он нашёл, какие пропустил, и уточните промпт. Этот навык масштабируется.
Не путайте схемный и семантический дрейф. Схемный — это про список колонок. Семантический — про смысл тех колонок, которые остались. Семантический дрейф в 5-10 раз опаснее, потому что автоматические тесты его обычно не ловят.
При добавлении nullable-колонки спрашивайте себя: «Если бы я был потребителем, я бы воспринял эту колонку как новую бизнес-метрику?» Если да — это не «безопасное» изменение, даже если оно nullable.
Помните про grain как часть интерфейса. Изменение grain — это всегда ломающее изменение, даже если все колонки остались прежними. Тест unique на ключе grain — обязательная гигиена для любой модели с контрактом.
Не включайте contract.enforced: true в первом учебном проходе. Сначала научитесь читать дрейф глазами и через Qwen Code. Механическое ограничение адаптера — это уже второй шаг, когда команда понимает, зачем это нужно.
Дополнительные ресурсы: Odcs официальная спецификация: https://bitol-io.github.io/data-contract-specification/ — первоисточник стандарта Open Data Contract Standard, используемого в курсе
Dbt документация по contracts: https://docs.getdbt.com/docs/mesh/contracts — раздел официальной документации dbt о contract.enforced и поддерживаемых материализациях
Статья zhamak dehghani о data mesh: https://martinfowler.com/articles/data-mesh-principles.html — концептуальная основа data-as-a-product и контрактов данных
Dbt-utils пакет: https://github.com/dbt-labs/dbt-utils — стандартные тесты и макросы, расширяющие покрытие контрактных проверок
Great expectations: https://greatexpectations.io/ — фреймворк для data quality assertions, который может служить дополнительным слоем проверок помимо dbt-тестов
Базовый data: https://www.elementary-data.com/ — open-source наблюдаемость данных для dbt, включая аномалии и тесты
Книга 'data contracts' (andrew jones): https://datacontract.com/ — практическое руководство по внедрению data contracts в организации
Qwen code документация: https://qwenlm.github.io/ — материалы по работе с LLM-ассистентом для анализа кода и спецификаций
Резюме: Контракт данных — это проверяемый слой между продуктовым обещанием витрины и её SQL-реализацией. В SDD Data различают два уровня: ODCS описывает продукт (схема, качество, SLA, PII-политика), а schema.yml и dbt-тесты описывают конкретную модель. Ни один слой не заменяет другой: тесты без ODCS дают зелёную модель с неправильным смыслом, ODCS без тестов — красивый контракт без доказательств. Дрейф контракта возникает, когда код меняется, а контракт остаётся прежним, и бывает трёх типов: схемный (поля добавлены/удалены/переименованы), семантический (смысл поля изменился без изменения схемы) и процессный (артефакты процесса не отражают изменение). Семантический дрейф опаснее всего, потому что автоматические тесты его обычно не ловят. Главный практический навык — заполнение минимальной заметки влияния на контракт при каждом PR и формулировка Qwen-промпта для автоматического поиска дрейфа. Запомните шесть полей заметки: изменённые поля, ломающее изменение, влияние на PII, влияние на SLA, покрытие проверками, нужно ли подтверждение. И помните главный принцип: добавление nullable-колонки не равно безопасному изменению, если она воспринимается как новая бизнес-метрика или меняет grain.