SLO / Budget Review

Я регулярно вижу SLO Review, где команда рассказывает, что сейчас всё горит или наоборот всё хорошо, и на этом встреча заканчивается. Отчёт о погоде. SLO / Budget Review — это разговор о приоритетах: накопленный долг по надёжности через burn rate, балансировка feature work и reliability work, корректировка SLO-таргетов, когда бюджет либо систематически пробит, либо месяцами не тронут. Без решений ритуал умирает за пару месяцев. Лист — про то, чем working review отличается от формального.

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

Главный навык на уровне L5 — корректировать SLO target, когда он перестаёт давать сигнал. Если бюджет никогда не близок к исчерпанию — target слишком слабый, не отражает реальность пользователя. Если бюджет постоянно сожжён — target слишком жёсткий, команда не успевает. В обоих случаях ревью бессмысленно: его данные не приводят к решениям. Я регулярно вижу команды, которые держат target «в камне», потому что «договорились с продуктом» — это путь к ритуалу без следствий.

Различает SLI / SLO / SLA, читает чужие SLO-дашборды и понимает текущее состояние бюджета.
Отчётно сообщает состояние своего сервиса на ревью команды (1–2 минуты: «target / факт / burn rate / следующий шаг»).

Составляет короткий отчёт по SLO одного сервиса: текущий burn rate, динамика за период, причины расхода, action items.
Пишет или обновляет error budget policy для своего сервиса: условия freeze, кто принимает решение, критерии выхода и возврата к feature work.

Фасилитирует SLO Review в своей команде: ведёт повестку, формулирует решения по бюджету, отслеживает action items до закрытия.
Держит баланс разговора: не позволяет уйти ни в техническое погружение, ни в общие формулировки; держит фокус на решениях, которые меняют приоритеты следующего спринта.
Корректирует SLO targets при систематическом нарушении или, наоборот, при полной незатронутости месяцами. Target в камне = ритуал бессмысленный.

L6+

Внедряет SLO Review как регулярный ритуал в команде/организации; согласует формат, аудиторию и cadence с продуктовыми стейкхолдерами.
Связывает SLO Review с org-level planning / OKR: систематический дефицит бюджета влечёт реальный сдвиг приоритетов на reliability work, а не пометку в Confluence.
Разводит SLO и оценку людей: дефицит бюджета меняет приоритеты, но выполнение цели не попадает ни в премию, ни в личные цели; команду оценивает по охвату и динамике.
Проверяет, есть ли у ритуала основание: согласие руководства на последствия при исчерпанном бюджете. Без него начинает с одного продукта и подписанной политики, а не с расписания встреч.

Материалы

Книги

Alex Hidalgo — Implementing Service Level Objectives (O’Reilly, 2020), глава 8 «Establishing an SLO Review». Рекомендую как основной источник именно по структуре встречи: про SLO и бюджет ошибок подробно пишут и другие, а про то, как провести ревью, — здесь.
Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 4. Рекомендую как фундамент: SLI, SLO, SLA и объяснение, зачем ревью вообще нужен. За устройством самой встречи идти не сюда.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 2. Тоже рекомендую: форматы SLO, устройство бюджета ошибок и примеры ревью — то место, где абстракция четвёртой главы становится конкретной.

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

Betsy Beyer et al. — Appendix B. Example Error Budget Policy (SRE Workbook). Готовый шаблон Error Budget Policy. Рекомендую начинать с него, а не писать политику с нуля: править чужой текст под себя быстрее, чем спорить о структуре с чистого листа.
Google SRE — Alerting on SLOs. Какие данные приходят на ревью как входные: окна burn rate и построенные на них алерты. Рекомендую прочитать до первого ревью, иначе на встречу приносят графики, из которых решение не следует.
Мой разбор — Надёжность строится в диалоге с бизнесом (jtprog.ru, май 2026). Про то, чего шаблон политики выше не даёт: почему SLO остаётся дашбордом, пока правила не проговорены с продуктом, и три признака, что разговор не состоялся. Там же кейс Mercari про User Journey SLO — переименовать артефакт мало, ревью нужно встроить в процесс продукта. Последний раздел отвечает на вопрос, чем мерить команду SRE, когда продуктов несколько, и почему выполнение SLO для этого не годится.
Marco Coulter — Avoiding Goodhart’s Law - Use SLO’s as Tools Not Cudgels (SREcon20 Americas, декабрь 2020). Сам не смотрел, описание по аннотации: SLI, SLO и бюджет ошибок как основа для разговора о том, какую нагрузку выдержит система, вместо красной линии, за которой команду наказывают. В списке стоит потому, что закон Гудхарта приложен к SLO прямо в названии.

Инструменты

Grafana SLO-дашборд — визуализация burn rate / budget remaining / SLI на одном экране. Что именно рисовать и чем — вкусовщина; важно, что без такого экрана ревью превращается в догадки.
Sloth — генератор PromQL для SLI и burn rate, самый известный инструмент в этом ряду. Стандартизирует записи между сервисами и упрощает подключение нового сервиса к ревью.
Nobl9 — коммерческая SLO-платформа. Сам не работал; коллеги рекомендуют её там, где SLO ведут несколько команд сразу и нужен общий портал. Для одной команды платформа тяжела и избыточна.
Error Budget Policy (markdown в репо команды) — документ, фиксирующий правила: что замораживаем при каких burn rate, кто принимает решение, по каким критериям возвращаемся. Как пункт списка его можно пропустить: это не источник, а артефакт самого ритуала, и готовый шаблон для него лежит выше. Без документа решения теряются через месяц.

Шаблоны

Error Budget Policy — заготовка политики из этого репозитория: пороги расхода с действиями, условия заморозки и выхода из неё, исключения, эскалация, согласования. Правило для крупного инцидента и раздел про не-цели сделаны по образцу приложения B из SRE Workbook; проценты в таблице порогов — отправная точка, а не норма.
Ежемесячный SRE Review — повестка и протокол обзора раз в месяц: SLO и бюджет, постмортемы и их action items, алерты, runbook, toil, мощности, резервные копии, дежурства. Частое ревью SLO он не заменяет: это срез по всем практикам сразу, который открывается решениями прошлого месяца и заканчивается таблицей новых.

Best practices

Короткие правила:

Регулярность важнее перфекционизма. Ежеквартальное двухчасовое ревью «обстоятельно» опаздывает: burn rate набегает быстрее, чем за месяц. Пятнадцать минут раз в неделю держат сигнал свежим. Сократить ритуал и не пропускать его важнее, чем сделать идеально и забросить.
Error Budget Policy — документ, а не устная договорённость. «Договорились на ревью, что при burn rate 14× включаем freeze» — через месяц точных условий не помнит никто, включая тех, кто договаривался. Policy документирована, версионирована, согласована с продуктом.

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

Подробнее:

Включай продукт в аудиторию. «SLO Review только для SRE, потом приходим к продукту с готовым решением» — короткий путь к саботажу. Product owners не понимают, откуда взялся freeze, и разумно сопротивляются тому, что свалилось на них готовым. Решение по бюджету, которое не дошло до владельца продукта в момент принятия, означает, что надёжность снижают вслепую. По моим наблюдениям, общее ревью, где сидят обе стороны, — самый быстрый способ выровнять понимание надёжности между SRE и продуктом.

Решения с владельцем и дедлайном, follow-up в начале каждого ревью. «Обсудили — забыли». Без action items с проверкой исполнения ревью превращается в разговор по кругу, и команда перестаёт относиться к нему всерьёз. Разница видна невооружённым глазом: там, где follow-up открывает встречу, по результатам действуют; там, где его нет, обсуждают одни и те же проблемы квартал за кварталом.

Корректируй SLO target, если он перестал давать сигнал. Бюджет никогда не подходит к нулю — target слишком слабый. Бюджет сожжён постоянно — target слишком жёсткий. И в том, и в другом случае ревью перестаёт работать: цифры есть, решений из них не следует. Корректировка target — упражнение техническое и политическое одновременно, потому что менять его придётся вместе с продуктом. Команды этого боятся: «мы же договорились полгода назад». Страх процесса оказывается сильнее реальности, и ревью становится театром.

Есть способ убить ревью надёжнее, чем цель в камне: сделать выполнение SLO показателем, по которому оценивают команду. Тогда начинает работать закон Гудхарта, и первым ломается сам ритуал. На встречу, где от цифры зависит премия, приносят цифру, а проблему оставляют за дверью. Бюджет перестаёт заканчиваться. Инцидентов становится меньше, жалоб — нет. А время, которое уходило на приоритеты, уходит на спор, считать ли вчерашний сбой инцидентом. Снаружи всё это выглядит как успех. Отчёт о погоде из начала листа хотя бы честный.

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

Вопрос «а чем тогда мерить команду» законный, и руководитель его задаст. В своём разборе про диалог с бизнесом я предлагаю охват и динамику вместо абсолюта: у скольких продуктов SLO подписан владельцем и есть действующая политика бюджета, как изменилось сгорание бюджета за квартал. Охват заниженной целью не улучшить. Сгорание улучшить можно, поэтому сравнивать его стоит только там, где цель за квартал не менялась. Похожий ход описан в третьей главе Workbook. В The Home Depot руководителям разработки в годовые цели записали завести SLO для своих сервисов и измерять их; про выполнение этих SLO в пункте ничего нет. У охвата своя лазейка, SLO для галочки, поэтому в счёт у меня идут только подписанные.

На самой встрече от подгонки защищают две привычки. Первая: рядом с цифрой лежит то, что в цифру не укладывается, — темы обращений в поддержку, постмортемы за период, слова дежурных. Когда SLI зелёный, а эти три источника говорят обратное, начинать стоит с них. Вторая: раз в квартал на ревью открывают определение индикатора вместо дашборда. Что считается, что исключено, когда исключение появилось и кто его согласовал. И граница. Ревью лечит только то, что решается в комнате. Если премия за цифру уже записана в систему мотивации, ни повестка, ни фасилитатор этого не исправят, и разговор придётся вести с тем, кто эту систему утверждал. С SLA так не получится вовсе: штраф записан в договоре, цифра там цель по построению. Для меня это довод держать SLO внутренним и не переносить на него договорную логику.

Всё описанное держится на условии, которое до этого места подразумевалось: бизнес согласился платить за надёжность скоростью. В первой главе SRE Book об этом сказано без дипломатии: решение остановить релизы до конца квартала, когда бюджет исчерпан, команда разработки может и не принять, если этого не потребует её руководство. В двадцатой главе Workbook то же записано первым принципом: SRE нужны SLO с последствиями, и обязательство следовать политике бюджета требует согласия руководства компании. Проверяется условие одним вопросом. Что было в последний раз, когда бюджет сгорел в ноль? Если релизы шли как шли, потому что дедлайн важнее, согласия нет, и никакая фасилитация его не заменит.

Мой вывод отсюда неудобный. Улучшать ревью в такой организации бесполезно, честнее его отложить. Еженедельная встреча, после которой ничего не останавливается, приучает всех к тому, что красный бюджет ничего не значит, и вернуть ему вес потом труднее, чем начать с нуля. Работа в этот момент лежит выше ревью: найти один продукт, у владельца которого простой уже болит, перевести его бюджет из процентов в деньги и подписать политику с ним одним. Проценты бизнесу безразличны, сумма за квартал — нет. Как вести такой разговор, разобрано в Stakeholder Management. Обратная граница тоже есть. Сервису, простой которого стоит меньше, чем час команды на встрече, ритуал не нужен вовсе, и это нормальный исход.

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

SLI-based Alerting — алерты на burn rate дают входные данные для SLO Review; без правильно построенных алертов ревью смотрит на запаздывающие или зашумленные данные.
SLO Engineering — инженерная сторона. Без работающего инструментария Review теряет точные данные. Там же про то, как индикатор защищают от подгонки на уровне формулы.
Postmortem Culture — постмортемы крупных инцидентов показывают, что именно съедает бюджет; ревью — точка, где их выводы превращаются в приоритеты.
Blameless Postmortem — короткие постмортемы по budget burn приходят на ревью как материал для решений.
Dev Team Partnership — ревью с участием команды разработки — основной канал, где partnership проявляется в работе с общим бюджетом.
Incident Response — крупные инциденты резко съедают бюджет; их влияние видно на ревью.
Runbooks — качество runbook прямо влияет на MTTR, а значит, и на скорость расхода бюджета.
Stakeholder Management — SLO review — главный регулярный ритуал, где перевод с инженерного на язык бизнеса происходит на практике; по составу участников и тону встречи видно, как в команде устроена работа со стейкхолдерами.

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

Cadence ревью — еженедельно, ежемесячно, раз в квартал — зависит от размера команды, зрелости SLO и скорости деплоя. Универсальной формулы нет. В литературе чаще советуют недельный ритм, на практике встречается всё.

И я не уверен, что для команд, которые катят несколько раз в день, недельный ритм вообще правильный: возможно, там нужен ad-hoc trigger по порогу burn rate, а не расписание. Если у кого-то есть опыт с таким форматом — присылайте PR.