SLO / Budget Review

Я регулярно вижу SLO Review, на которых статус команды «сейчас всё горит / всё хорошо» — и никаких решений по бюджету. Это не ревью, это отчёт о погоде. SLO / Budget Review — это разговор о приоритетах: накопленный долг по надёжности через burn rate, балансировка feature work vs 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, кто принимает решение, exit-критерии возврата к feature work.

Фасилитирует SLO Review в своей команде: ведёт повестку, формулирует решения по бюджету, отслеживает action items до закрытия.
Балансирует discussion: не позволяет уйти ни в техническое погружение, ни в общие формулировки; держит фокус на решениях, которые меняют приоритеты следующего спринта.
Корректирует 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». Главный практический источник по структуре ритуала.
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, error budget, ритуалу ревью.

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

Betsy Beyer et al. — Appendix B. Example Error Budget Policy (SRE Workbook). Готовый шаблон Error Budget Policy.
Google SRE — Alerting on SLOs. Какие данные (burn rate windows, alerts) приходят на ревью как входные.

Инструменты

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

Best practices

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

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

Подробнее:

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

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

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

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

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

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

Cadence ревью (еженедельно / ежемесячно / квартально) зависит от размера команды, зрелости SLO и скорости deploy. Универсальной формулы нет; в литературе чаще советуют недельный, на практике встречается всё.
Я не уверен, что в командах с очень частыми deploys (несколько раз в день) недельный ритм оптимален — возможно, нужен ad-hoc trigger при burn rate threshold, а не строгий cadence. Если опыт есть — PR.