← На главную

Управление изменениями

Если изменения не зафиксированы — это не эксперимент, а шум.

Главная причина "непонятных" движений в выручке — не рынок, а незадокументированные вмешательства. Когда изменения не фиксируются, невозможно понять, что сработало, а что ухудшило. Система становится чёрным ящиком.

Governance = порядок: один рычаг → окно → проверка → запись → вывод. Каждое изменение должно быть оформлено, иметь владельца, guardrails, окно оценки и критерий отката. Без этого система необъяснима.

Минимальный контракт на изменение
Контракт на изменение
  • Цель изменения (механизм, не KPI): что именно хотим изменить в системе
  • Рычаг (что именно меняем): конкретный параметр, конфиг, флаг
  • Область (срезы: платформа/формат/сегмент): где применяем изменение
  • t0 (когда включили): точный момент времени включения
  • Ожидаемый лаг до денег: когда эффект проявится в выручке
  • Окно оценки: на каком окне будем оценивать эффект
  • Cooldown: пауза после изменения, без новых вмешательств
  • Guardrails (3–5 ранних сигналов): метрики безопасности для раннего предупреждения
  • Критерий отката: при каких условиях откатываем изменение
  • Владелец решения: кто отвечает за изменение и принимает решение
Когда не ведём журнал — мы путаем причины

Журнал превращает шум в причинность.

Guardrails: метрики безопасности
Show rate / coverage
Что ловит: Деградацию доступности инвентаря и сжатие coverage.
Почему ранняя: Реагирует до падения выручки, показывает проблемы в delivery.
Типичный порог: Падение на 5–10% относительно baseline за окно 3–7 дней.
Pressure / frequency proxy
Что ловит: Рост давления и насыщение системы.
Почему ранняя: Показывает насыщение до падения выручки, даёт время на реакцию.
Типичный порог: Рост на 15–20% относительно baseline за окно 7–14 дней.
Latency / delivery proxy
Что ловит: Технические проблемы в воронке requests → responses.
Почему ранняя: Реагирует на разрыв воронки до падения объёма показов.
Типичный порог: Рост latency на 20–30% или падение responses ratio на 5–10%.
Segment tails (края распределения)
Что ловит: Проблемы в отдельных сегментах, которые маскирует среднее.
Почему ранняя: Показывает хрупкость системы до того, как проблема распространится.
Типичный порог: Падение в хвосте (q10 или q90) на 10–15% относительно baseline.
Variance (рост дисперсии)
Что ловит: Рост нестабильности системы, увеличение разброса метрик.
Почему ранняя: Показывает дестабилизацию до явных падений.
Типичный порог: Рост дисперсии на 25–40% относительно baseline за окно 7–14 дней.
User experience proxy
Что ловит: Деградацию пользовательского опыта (глубина, скролл, время).
Почему ранняя: Показывает проблемы до падения выручки, связанные с поведением пользователей.
Типичный порог: Падение на 5–10% относительно baseline за окно 7–14 дней.
Собери план изменения
Ритуал принятия решения
Шаг Кто владелец Артефакт
Дизайн изменения Владелец продукта / инженер Контракт на изменение (цель, рычаг, область)
Выбор guardrails Владелец продукта / аналитик Список 3–5 метрик безопасности с порогами
Включение + запись t0 Инженер / оператор Запись в change log с точным временем включения
Мониторинг ранних сигналов Владелец продукта / оператор Ежедневная проверка guardrails в течение cooldown
Оценка окна Аналитик / владелец продукта Анализ эффекта на окне оценки с учётом лага
Решение (оставить/откатить/перепроектировать) Владелец решения Решение с обоснованием и записью в change log
Постмортем Владелец продукта / аналитик Запись: что сработало, что нет, что добавить в мониторинг
Обновление алертов/плейбуков Владелец продукта / оператор Обновлённые алерты, плейбуки, guardrails на основе опыта
Антипаттерны изменения

Governance — это способ сделать систему объяснимой.

← Назад к Эксплуатации системы

Если изменения не зафиксированы — это не эксперимент, а шум.