Change Governance

«Мы катим в любой момент, у нас zero-friction culture» — лозунг, за которым часто стоит «у нас нет production readiness, мы катим и надеемся». Change Governance — это дисциплина границ, а не бюрократия: какие изменения идут по быстрой полосе без review, какие требуют PRR, какие вообще не катятся в высокий сезон. Я регулярно вижу команды, уверенные, что выбор бинарный: либо еженедельный CAB, либо полное отсутствие процесса. Между этими полюсами лежит нормальная жизнь — явная классификация и явные рубежи, которые добавляют полминуты к рядовому изменению и пару дней к рискованному. Вот это и есть работающий change governance.

Граница: Progressive Delivery — техника выкатки (canary, blue-green, feature flag). Change Governance — политика и процесс: что считается рискованным, кто согласует, когда заморозка. Architecture Decision Records — про архитектурные решения; change governance — про решения о выкатке, у которых цена ошибки лежит в production.

Что должен уметь

Главный навык на уровне L5 — расклассифицировать изменения так, чтобы 80–90% шли по быстрой полосе (standard, хватает code review), 10–15% — по обычной (PRR или отдельный разбор для нестандартного), а оставшиеся проценты — по процедуре обхода заморозки для аварийных. По моим наблюдениям, сломанный процесс выглядит одним из двух способов. Либо «всё normal», и тогда работа замирает в еженедельных заседаниях CAB. Либо «всё standard», и тогда ни одно нестандартное изменение не получает разбора. Рабочая схема держится на явных критериях категории standard: команда должна понимать, когда разбор не нужен.

Работает по принятому в команде процессу: знает, какому классу изменения какой разбор положен (ревью PR, RFC, PRR), готовит заявку с планом отката, оценкой blast radius и шагами проверки.
Понимает разницу между standard, normal и emergency; не помечает обычное изменение как аварийное, чтобы проскочить мимо разбора.

Проводит Production Readiness Review (PRR) для нового сервиса или крупного изменения: SLO определены, мониторинг и алерты есть, runbook’и написаны, дежурство закрыто, ёмкость посчитана, откат проверен.
Вводит заморозку изменений там, где она нужна: высокий сезон (чёрная пятница, закрытие квартала), крупные запуски, сборка мобильного релиза. Заморозка — не полная остановка, а явный список того, что всё же разрешено.

Проектирует классификацию изменений для команды или организации: критерии standard, normal и emergency, цепочка согласующих под каждую категорию, метрики (доля standard, время до согласования для normal, доля изменений, обернувшихся инцидентом).
Включает привязку к error budget: бюджет сожжён — продуктовые изменения замораживаются автоматически, разрешены только работы по надёжности. Без такой привязки SLO остаётся дашбордом, а не инструментом принятия решений.

L6+

Связывает процесс изменений с программой SLO: оценка риска опирается на данные SLO (там, где инциденты уже случались, вес риска выше), сами оценки калибруются раз в квартал.
Внедряет PRR для новых сервисов как обязательный рубеж перед production: письменный чеклист, владелец процесса, доведение открытых пунктов до общедоступного запуска.

Материалы

Книги

Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 32 «The Evolving SRE Engagement Model». Процесс PRR у Google — каноническое описание этого рубежа перед тем, как сервис берут под опеку SRE. Главный публичный источник по теме.
Jennifer Davis, Katherine Daniels — Effective DevOps (O’Reilly, 2016). Глава про управление изменениями в контексте DevOps: как обойтись без бюрократии, не потеряв контроль.
Mark Schwartz — A Seat at the Table (IT Revolution, 2017). Не SRE-книга, но фундамент про change governance в продуктовых организациях: почему управление изменениями в духе ITIL не работает там, где команда живёт по agile, и что ставить вместо.
Nicole Forsgren, Jez Humble, Gene Kim — Accelerate (IT Revolution, 2018). Связка «процесс изменений — частота выкаток — доля неудачных изменений» (DORA-метрики). Главный аргумент против тяжёлых согласовательных комитетов.

Статьи и доклады

ITIL 4: Change Enablement. Современный ITIL отказался от «Change Management» в пользу «Change Enablement» (сдвиг тонкий, но важный). Полезно для словаря и для разговора с корпоративным IT.
Knight Capital Group — распоряжение SEC по итогам разбора событий 1 августа 2012 года (Release 34-70694). Не статья про governance, но первичный источник кейса: там по шагам расписано, что именно пошло не так с выкаткой (см. ниже).
John Allspaw — On Being a Senior Engineer (Kitchen Soap, 2012). Косвенно: процесс изменений держится на суждении опытного инженера, а не на регламенте, и любой стандарт приземляется на конкретный контекст.

Инструменты

Issue tracker (Jira / Linear / GitHub Issues) — основное место для заявки на изменение: класс, владелец, согласующий, статус. Без такой записи процесс существует только в Slack.
ServiceNow Change Management / Jira Service Management — корпоративные платформы; нужны там, где есть регуляторные требования (SOX, ISO 27001, PCI-DSS). Для команды до 50 человек обычно перебор.
FireHydrant Change Tracking / incident.io — платформы для инцидентов, которые заодно ведут изменения: видно, что катилось перед инцидентом, и это работает и на разбор, и на будущую оценку риска.
Чеклист PRR как живой документ — markdown в репозитории или страница в Notion. Самый важный инструмент здесь вообще не про технологию. По моим наблюдениям, простой чеклист выигрывает у любой специализированной платформы в командах до двух сотен инженеров.
Анти-инструмент: еженедельный CAB как основной механизм. Если через заседание идут 80% изменений, процесс мёртв: команда его либо обходит, либо саботирует.

Best practices

Главный публичный кейс — Knight Capital Group, August 1, 2012. За 45 минут утром на Уолл-стрит компания потеряла $440M из-за ошибки выкатки: скрипт выкатки отработал на семи серверах из восьми; восьмой поднял старую версию кода, где тот же feature flag означал совсем другое, и отправил на биржу миллионы ошибочных заявок. Компания не обанкротилась в прямом смысле — через четыре дня её спасли экстренным вливанием капитала, но самостоятельным бизнесом она быть перестала и в следующем году была поглощена. Разница между «умерла» и «перестала себе принадлежать» в этой истории невелика. Документ SEC разбирает это по шагам: переиспользованный флаг никто не пропускал через PRR, скрипт выкатки не проверял, одна ли версия кода на всех восьми серверах, а процедуру отката, единственную вещь, которая могла бы всё это остановить в первые минуты, не проверяли вообще ни разу — ни на учениях, ни в тестовой среде. Я регулярно вижу команды с тем же набором: «выкатим на N серверов, потом проверим», «флаг переиспользовали, записи об изменении нет». Разница только в цене. Без биржевых оборотов Knight Capital последствия мельче, всё проходит незаметно, и команда ничему не учится. Этот кейс я держу как лучшее публичное напоминание, что процесс изменений не украшение.

Минимум, который отделяет живой процесс от его отсутствия, состоит из трёх вещей. Первое — классификация. Пока нет явной разницы между standard, normal и emergency, все изменения равнозначны, и команда либо тонет в процессе, либо обходит его целиком. Ориентир — 80–90% изменений в быстрой полосе, где хватает code review.

Дальше — откат. У каждого изменения он есть, и для рискованных он проверен заранее, на staging. «Откатим, если что» планом не считается: в момент, когда откат понадобится, выяснять его работоспособность уже поздно.

И PRR как обязательный рубеж перед выходом нового сервиса в production: письменный чеклист, владелец процесса, доведение открытых пунктов до конца. Без последнего PRR превращается в театр — пункты записали, никто к ним не вернулся.

Production Readiness Review — это чеклист, а не собеседование. У Google PRR состоит из письменной части и встречи с вопросами. Команды часто оставляют от него одну встречу раз в неделю, и это не работает: подготовка здесь важнее разговора. Рабочий вариант — команда сервиса заполняет письменный чеклист (SLO определены, мониторинг и алерты на месте, runbook’и написаны, дежурство настроено, ёмкость посчитана, зависимости выписаны, откат проверен, security review пройден), а встреча идёт сверху, а не вместо. По моим наблюдениям, когда PRR живёт только как встреча, чеклист сползает в формальность, и через год от практики остаётся театр.

Привязка к error budget связывает процесс изменений с программой SLO. Без неё SLO — просто дашборд. Смотреть на него незачем. С привязкой SLO становится инструментом решений: бюджет сожжён — продуктовые изменения на паузе, разрешены только работы по надёжности. Это не «всем замолчать», а явный сигнал, что приоритеты сместились. Я регулярно вижу команды, которые объявили SLO и error budget, но привязку так и не сделали: через полгода бюджет хронически в минусе, а поведение не изменилось, потому что за перерасход ничего не следует.

Заморозка — не полная остановка. Распространённый страх звучит как «заморозили, значит, команда простаивает». Рабочая заморозка — это явный список исключений: «на неделе чёрной пятницы едут только починки надёжности и патчи безопасности от SEV2 и выше, продуктовые изменения — после». Список, срок, подписи под ним. Вот и вся дисциплина. Заморозка без списка либо игнорируется, и катят все, либо оказывается болезненно строгой, и важные починки не доезжают.

Категория standard — главный мускул всего процесса. Парадокс в том, что качество мерится не строгостью прохода рискованных изменений, а долей тех, что проходят как обычные и едут по быстрой полосе. Когда разбора требует половина, процесс душит скорость команды. Его начинают обходить, и дальше это уже не остановить: граница, один раз пройденная в обход, обратно сама не восстанавливается. Рабочая пропорция: 80–90% standard (проверенный паттерн, низкий риск — починка бага в одном сервисе, изменение конфигурации, закрытое тестами, подъём зависимости внутри минорной версии), 10–15% normal с PRR или отдельным разбором, единицы процентов — аварийные и обходящие заморозку.

Связанные листья

Progressive Delivery — техника выкатки: canary, blue-green, feature flag. Этот лист про политику, то есть что катим и кто согласует; соседний — про то, как выкатить безопасно.
SLO Engineering — error budget питает решение о заморозке. SLO без такой привязки — дашборд, а не инструмент.
Architecture Decision Records — ADR отвечает за архитектурные решения, вроде выбора технологии или паттерна; change governance — за операционные: что и когда катится.
Action Items Tracking — открытые пункты PRR — те же задачи по итогам разбора; довести их до запуска и есть часть процедуры.
Incident Response — изменение всегда первый подозреваемый: получив вызов, IC первым делом смотрит недавние выкатки.
Service Ownership — каталог сервисов хранит статус PRR (пройден, не пройден, в процессе); это часть ответа на вопрос «есть ли владелец и готов ли сервис к production».
Blameless Postmortem — когда инцидент случился из-за изменения, задачи по итогам разбора почти всегда упираются в процесс: PRR не было, откат не работал, согласование пропустили.
DORA Metrics — доля неудачных изменений и время от коммита до production — прямой сигнал о качестве процесса: тяжёлые согласования растят время, слабая дисциплина разбора растит долю неудач.

Открытые вопросы

Production Readiness Review просится в отдельный лист (TBD): подробный checklist, кто им владеет, как эта практика масштабируется на полсотни сервисов. Рядом — оценка риска изменения (TBD), где нужны рабочие эвристики уровня «blast radius × вероятность × обратимость». Канонической модели тут нет, каждая команда строит свою, и сравнить их между собой негде.

Третья дыра — change management под регуляторику (TBD): формальные требования SOX, PCI-DSS и SOC 2 к записям об изменениях. Это пересечение с листьями про compliance, и писать его нужно вместе с ними.

Я не уверен и в том, где проходит правильная граница между Change Governance и Progressive Delivery в командах с совсем лёгким процессом — деплой по пушу, явного review нет вообще. Если у вас есть рабочая модель, расскажите через PR.