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.

Материалы

Книги

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 — переименовать артефакт мало, ревью нужно встроить в процесс продукта.

Инструменты

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

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 — упражнение техническое и политическое одновременно, потому что менять его придётся вместе с продуктом. Команды этого боятся: «мы же договорились полгода назад». Страх процесса оказывается сильнее реальности, и ревью становится театром.

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

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.