Когда я только начинал в SRE, думал: SLO — это метрика. Что-то для отчётности. Чтобы тимлид видел “99,9% — хорошо”. Ошибался. SLO — это не цифра в дашборде. SLO — это культура. Это ограничитель. Это “нет” в нужный момент. И вот как я это осознал.

У нас был сервис. Один раз в квартал — ажиотаж, лавина трафика. Остальное время — тихо. Но каждое обновление — как перезапуск реактора.

SLO у нас было заявлено: 99.9% за 28 дней. Кажется — просто. Но я решил посчитать: 100% — 99.9% = 0.1% допустимых простоев 0.001 × (28 × 24 × 60 × 60) = ~40 минут в месяц (0.1 /100 это 0.001 в долях) Хорошо, думаю. 40 минут — это у нас в запасе. Но потом посмотрел — как быстро мы их тратим. Построил график: завёл error budget, начал считать, сколько времени сервис проводит ниже SLO. Добавил burn rate: на сколько процентов бюджета в час мы “сжигаем” при сбое. И тут началось. Деплой → алерт → инцидент 2-го уровня. Латентность поднялась до 2.4 сек (было 200 мс). SLO начал падать. Burn rate — 15% бюджета в час. Я останавливаю команду: «Мы не фиксим. Мы включаем мораторий. Деплои — запрещены, пока burn rate > 5%». Реакция: — Да ладно, это же не критично! — У нас релиз горит! — Это же только латенси, пользователи всё равно голосуют! Говорю: «Сейчас мы сжигаем error budget со скоростью, при которой его не хватит на оставшиеся 27 дней. Если завтра упадёт БД — мы не сможем сказать: “это допустимо”, потому что бюджет будет нулевым. А значит — не сможем ни апдейтить, ни обновлять, ни чинить без нарушения SLO. Это не “бюджет ошибок” — это наша страховая подушка. И мы не имеем права тратить ее на “небольшие” проблемы» Сделали откат, burn rate упал до 0, мораторий — снят. Но главное — нормализовался разговор. Теперь: Любое изменение начинается с вопроса: «а хватит ли у нас бюджета?» Если burn rate высок — автоматический запрет на начало деплоя Если error budget < 30% — команда обязана провести retro до следующего релиза Что изменилось через месяц? 👉 Количество инциденетов упало на 40% (вели статистику + postmortem) Потому что не запускали обновления “просто так” в момент, когда система уже под нагрузкой. 👉 Деплои стали реже, но безопаснее Никто не заявлялся, пока burn rate не ноль. 👉 Разработчики начали думать об устойчивости до релиза Потому что знали: если сломают SLO — просто не пустят в прод. 👉 Появилась обратная связь не через баги — через метрики «Твой сервис сегодня съел 7% бюджета — объясни, почему» — это мощнее любого тикета. SLO — это не про “достигли 99.9%” Это про: ✅ Когда нельзя делать деплой ✅ Когда нужно остановиться, даже если “всё вроде ок” ✅ Когда автоматика блокирует человека — не потому что кто-то сказал, а потому что метрики видят, что плохо SLO — это ограничитель на хаос. Это способ сказать “нет” без криков. Это инструмент управления рисками, а не утилита для отчёта. Хочешь построить культуру надёжности? Не начинай с мониторинга. Начни с глубокого понимания, сколько “плохо” — это ещё “допустимо”. А потом научись использовать этот остаток как рычаг управления процессом. И тогда ты уже не просто инженер. Ты — архитектор стабильности.