Production Readiness Review

«PRR назначили на четверг, запуск в пятницу». Я регулярно вижу ревью готовности, которое проводят ради подписи. Чек-лист заполнен за вечер, напротив каждого пункта галочка, а на вопрос «где это посмотреть» команда отвечает «вроде настроено». Такое ревью хуже, чем никакого. После него остаётся документ, по которому сервис готов, и дежурный, который узнаёт об обратном в первую же ночь.

Production Readiness Review — проверка сервиса на рубеже: перед первым выходом в прод, перед передачей под чужое дежурство, после существенной перестройки. Результатов у неё три, и заполненный чек-лист среди них не главный. Первый — список найденных пробелов. Второй — решение по каждому: устранить до запуска или принять исключением с владельцем и сроком. Третий — запись о том, кто на это согласился.

Границы с соседями. Change Governance решает, какие изменения вообще проходят ревью, а какие едут без него; этот лист про само ревью. Service Ownership отвечает за то, кто владеет сервисом после приёмки. Golden Paths делает готовность свойством по умолчанию: всё, что платформа даёт сразу, из чек-листа уходит. Error Budget Gating начинает работать уже после первого релиза.

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

Главный навык на уровне L5 — держать чек-лист коротким. Добавить пункт легко: после каждого инцидента находится вопрос, который «стоило задать на ревью». Убрать трудно, и через пару лет список в сотню строк заполняют не глядя. По моим наблюдениям, ревью умирает именно так, а вовсе не от сопротивления команд.

Заполняет чек-лист для своего сервиса с доказательством на каждый пункт: ссылка на дашборд, результат проверки, дата последнего восстановления из резервной копии.
Отличает «не выполнено» от «к сервису не относится» и оба случая записывает в исключения, а не пропускает молча.

Проводит ревью чужого сервиса: читает чек-лист до встречи, проверяет доказательства выборочно, на встречу выносит только спорное.
Формулирует исключение как задачу: что не сделано, чем это грозит, кто владелец, к какой дате.
Начинает ревью, пока на устранение найденного ещё есть время, и говорит «не допущен», когда времени уже нет.

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

L6+

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

Материалы

Книги

Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 32 «The Evolving SRE Engagement Model», авторы Acacio Cruz и Ashish Bhambhani. Первую половину про фазы PRR пересказывают все. Советую дочитать вторую: там посчитано, во что ревью обходилось самому Google, и объяснено, чем его заменили.
Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 27 «Reliable Product Launches at Scale» и приложение E с чек-листом запуска образца 2005 года. Обязательно прочитать два правила ведения чек-листа: лучшего определения того, какому пункту в нём место, я не встречал.

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

AWS — Operational Readiness Reviews (ORR) (AWS Well-Architected, 2022). Тот же инструмент под другим именем. Ценен происхождением вопросов: они выведены из разборов инцидентов, а ревью устроено как самооценка команды, чтобы не тормозить разработку.
GitLab — Production Library and Readiness. Открытый архив ревью готовности GitLab.com. По моим наблюдениям, живых примеров чужого ревью в открытом доступе почти нет, и этот репозиторий полезен даже в архивном виде.

Инструменты

Чек-лист в репозитории сервиса — markdown рядом с кодом, правки через обычное ревью. По моим наблюдениям, чаще берут именно его: история ревью лежит там же, где история сервиса, и ссылки на доказательства не протухают в чужой вики.
Каталог сервисов со статусом ревью — Backstage или своя таблица, где у сервиса записаны дата ревью, решение и открытые исключения. Имеет смысл, когда сервисов больше, чем помнит один человек.
Автоматические проверки — пункты, которые умеет проверить машина: есть ли алерты, есть ли в них ссылка на runbook, проходит ли откат на стенде. Каждый такой пункт стоит увести из чек-листа в CI. Людям остаётся то, что требует суждения.

Шаблоны

Production Readiness Review — заготовка ревью из этого репозитория: шесть блоков чек-листа, таблица исключений с владельцем и сроком, решение и согласования. Список в ней — отправная точка, под критичность сервиса он сокращается.

Best practices

Самое честное о PRR написали те, кто его придумал. В 32-й главе SRE Book есть раздел с итогами: подключение одного сервиса занимало двух-трёх инженеров на два-три квартала, очередь на ревью измерялась кварталами, а трудозатраты росли вместе с числом сервисов. Хуже того, каждую находку исправляли заново в каждом сервисе, потому что устроены сервисы были по-разному. Ответом стала не лучшая процедура, а фреймворки: проверенные решения записали в код, и сервис на таком фреймворке, как сказано в главе, готов к проду по построению. Подключение после этого укладывалось в одного инженера и один квартал.

Ту же дорогу прошёл GitLab, и её видно снаружи. Инженеры заводили ревью готовности на каждое существенное изменение инфраструктуры GitLab.com: новый сервис, новую функцию, крупную перестройку. Ревью лежали в открытом репозитории. Сейчас он в архиве, а в его описании сказано, что процесс заменён другим, встроенным в цикл разработки.

Из этих двух историй я делаю один вывод. Отдельное ревью готовности — временная стадия. Оно нужно, пока организация не знает, из чего состоит готовность, и пока платформа не выдаёт её сама. Хороший признак здоровья: чек-лист с годами становится короче.

Каждый пункт чек-листа оплачен отказом. У команды, которая вела чек-лист запуска в Google, было два правила: важность каждого вопроса подтверждена, лучше всего прошлым провалом, а каждое указание конкретно и выполнимо для разработчика. Там же есть деталь, которая говорит о цене вопроса больше любых рассуждений: в какой-то момент новый пункт в чек-лист добавляли только с одобрения вице-президента. AWS пришла к тому же с другой стороны, её вопросы для ORR выведены из разборов инцидентов. Пункт, за которым не стоит ни отказ, ни внятное «что случится, если этого не сделать», я считаю кандидатом на удаление.

Пункт отмечается, когда есть доказательство. Ссылка на дашборд, а не слова «дашборд есть». Дата последнего восстановления из резервной копии, а не «бэкапы настроены». Это правило выглядит придиркой и экономит больше всего времени: рецензент проверяет ссылки выборочно, а не расспрашивает команду, и встреча сжимается до спорного. Почему письменная часть важнее встречи, разобрано в Change Governance, повторять не буду.

Исключение — долг с владельцем и сроком. Ревью без исключений не бывает: у нового сервиса нет истории нагрузки, план мощностей на год вперёд взять неоткуда. Такой пункт не удаляют и не закрашивают зелёным. Он уходит в таблицу исключений: что не сделано, почему, кто отвечает и к какой дате. Дальше начинается то, на чём практика обычно ломается. Через три месяца после запуска таблицу никто не открывает. Мне ближе простое правило: просроченное исключение возвращает сервис на ревью, и это записано в решении с самого начала.

У ревью готовности есть границы, и первую я считаю главной. Ревью, которое не может закончиться словами «не допущен», проводить не стоит. Если дата запуска назначена и сдвинуть её некому, честнее сразу заполнять таблицу исключений, чем изображать проверку. Вторая граница — частота. На каждый релиз работающего сервиса ревью не годится: для этого есть конвейер и политика изменений, а ревью на каждый чих превращается в очередь. Третья — масштаб. Команде из пяти человек с тремя сервисами формальное ревью почти ничего не даёт: все и так знают, где чего не хватает. Им хватит самого чек-листа, пройденного вслух.

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

Change Governance — какие изменения идут через ревью, а какие по быстрой полосе; этот лист раскрывает один из его рубежей.
Dev Team Partnership — ревью как часть договора между разработкой и эксплуатацией: что проверяется до того, как сервис берут под дежурство.
Service Ownership — каталог сервисов хранит статус ревью, а владелец сервиса отвечает за исключения после запуска.
Golden Paths — куда уезжают повторяющиеся находки: то, что даёт платформа, проверять на ревью уже незачем.
SLO Engineering и Runbooks — два документа, без которых блок наблюдаемости в чек-листе не закрыть.
Capacity Planning — самый частый источник исключений у нового сервиса.
Action Items Tracking — исключения живут по тем же правилам, что задачи из разбора: владелец, срок, критерий.
Error Budget Gating — следующий рубеж: ревью пускает сервис в прод, гейт по бюджету решает, что едет в него дальше.

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

Повторное ревью я для себя не закрыл. «Существенное изменение» легко написать в правилах и трудно распознать в жизни: архитектура меняется по одному сервису и по одному запросу за раз, и момента, когда сервис стал другим, никто не замечает. Привязка к календарю проще, но тогда ревью приходит по расписанию, а не по поводу.

Рядом лежит самооценка. AWS строит на ней свою программу, и на масштабе другого пути, похоже, нет. Я не уверен, какой долей выборочных проверок удерживается честность самооценки и удерживается ли вообще. Если у вас есть опыт, расскажите через PR.

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