Error budget в ретейле: как нарушения SLO за две недели убедили заказчика в canary

SRE-книжку Google прочитали, кажется, все. Error budget как концепция - понятная и симпатичная: договариваешься с заказчиком о допустимом уровне деградации, дальше работаешь в этих границах, а не выясняешь на каждом инциденте, кто виноват и что считается «упало». На бумаге это снимает много конфликтов. Проблема в том, что донести эту идею до нетехнического заказчика из ретейла - отдельное упражнение.

Мы работаем с таким заказчиком уже около года в рамках managed-инфраструктуры. Инфраструктура - Kubernetes, несколько продовых сервисов с разной нагрузкой, деплои несколько раз в неделю. До этого лета мониторинг у них строился по классической схеме: uptime-метрики, alert когда что-то упало, разбор полётов постфактум.

В июле предложили им перейти на SLO с конкретными SLI. Заказчик согласился без сопротивления - звучит разумно, почему нет. Вот тут и начался настоящий разговор.

Как объясняли error budget

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

Мы пошли от конкретного числа. Взяли один ключевой сервис - каталог товаров - и посчитали: при SLO 99,5% за 30 дней допустимо около 3,6 часа деградации. Не катастрофы, не даунтайма - именно деградации, когда часть запросов отваливается или отвечает с ошибкой. Это число заказчику пошло: «3,6 часа в месяц можно тратить на деплои и эксперименты, если остальное время работает нормально».

SLI выбрали два: success rate (доля запросов без 5xx) и p99 latency для критичных эндпоинтов. Окно - скользящие 30 дней. Метрики уже шли в Prometheus, оставалось прописать recording rules и настроить дашборд. Это мы описывали подробнее в контексте своей инфраструктуры - здесь акцент на другом.

Первые две недели

Договорились смотреть на error budget еженедельно - заказчик хотел видеть картину сам, без посредников. Сделали Grafana-дашборд с одним крупным числом: «бюджет потрачен X%». Всё просто.

На первой неделе потратили около 18% бюджета. Это насторожило, но не критично. На второй - ещё 22%. Итого за две недели - 40% месячного бюджета. При такой скорости к концу месяца SLO было бы нарушено.

Стали смотреть, откуда берётся деградация. Ответ оказался неприятно простым: деплои. Каждый раз, когда команда разработки выкатывала обновление в продакшн, несколько минут сервис отдавал ошибки - перезапуск подов, brief unavailability, несовместимость версий на старте. Ничего экзотического. Просто стандартный деплой без какой-либо защиты: rolling update с параметрами по умолчанию, никаких feature flags, никакого канареечного трафика.

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

Разговор с заказчиком

Когда показали эту картину заказчику, реакция была примерно такая: «подождите, мы теряем бюджет просто потому что деплоим новые версии?»

Именно так. И это открыло разговор, который без данных было бы сложно начать. Мы объяснили: feature flags позволяют деплоить код без включения функциональности - изменение доезжает до продакшн, но пользователи его не видят до явного переключения. Canary releases позволяют направить на новую версию небольшой процент трафика и посмотреть на поведение до полного переключения. Оба подхода сокращают риск одного деплоя.

Заказчик это понял, потому что перед ним лежали цифры - не абстрактные рассуждения про «лучшие практики», а конкретный расход бюджета за две недели. Аргумент «мы теряем 40% месячного error budget на деплои» работает лучше, чем «google так делает».

Сейчас мы в процессе: разрабатываем план по canary releases для основных сервисов, параллельно команда разработки смотрит на feature flags. Это небыстро - у них монолит с историей, добавление feature flags требует рефакторинга в нескольких местах. Но направление теперь понятно и мотивировано.

Что стоит учесть при похожем внедрении

Несколько вещей, которые мы вынесли из этого опыта:

• Начинай с одного сервиса, не со всех. Пытаться охватить всю инфраструктуру сразу - значит потратить месяц на настройку и получить данные, которые никто не успел осмыслить.
• Дашборд должен быть для заказчика, не для инженера. Одно большое число «бюджет потрачен X%» - понятно. Таблица PromQL-метрик - нет.
• Еженедельный ритм работает лучше ежемесячного. За месяц всё забывается, причины размазываются. За неделю можно соотнести расход бюджета с конкретными деплоями и инцидентами.
• Деплои - это законный расход бюджета, но его надо считать. Пока команда не видит, сколько бюджета тратит на выкатки, у неё нет стимула что-то менять в процессе деплоя.

Ещё один момент: SLO нарушились - и это нормально. Заказчик воспринял это без паники именно потому, что мы заранее договорились: SLO - это инструмент наблюдения, а не обещание никогда не ошибаться. Если бы первое же нарушение вызвало конфликт, разговора про canary не получилось бы - всё ушло бы в разбор полётов.