У бизнеса и инженерной команды часто разные представления о надёжности. Для бизнеса простой означает потерянные продажи, сорванные операции и недовольных клиентов. Для команды — инциденты, дежурства и риск новых релизов.
Проблема начинается, когда единственным требованием становится «никаких сбоев». Абсолютной надёжности практически не бывает, а попытка приблизиться к ней стоит всё дороже и может замедлить продукт сильнее, чем редкие допустимые сбои.
Какую проблему мы решаем
SLO — Service Level Objective — задаёт целевой уровень качества конкретного сервиса. Например, не абстрактное «работает хорошо», а договорённость о доступности, задержке или доле успешных операций за определённый период.
Error Budget — это допустимый запас отклонения от цели. Если компания согласилась, что сервис не обязан быть идеальным каждую секунду, этот запас можно использовать как пространство для изменений, экспериментов и релизов.
Смысл подхода не в красивой метрике. Он заставляет ответить на бизнес-вопрос: какой уровень надёжности нам действительно нужен и сколько мы готовы платить за его повышение?
Что получает бизнес
Главная выгода — возможность сравнивать стоимость риска со стоимостью надёжности.
Если минутный сбой критичного платёжного процесса напрямую останавливает выручку, высокий SLO оправдан. Если редко используемый внутренний отчёт недоступен несколько минут, та же инженерная цена может не иметь смысла.
SLO также уменьшает бессмысленные споры между «надо быстрее выпускать» и «надо перестать всё ломать». Пока Error Budget не исчерпан, команда может активнее менять систему. Если бюджет ошибок уже потрачен, приоритет смещается в сторону надёжности.
Так разговор о качестве становится частью управления продуктом, а не только внутренней задачей эксплуатации.
Что получает команда
Команда получает ясные цели вместо требования «делайте надёжно». Можно понять, какие метрики действительно отражают пользовательский опыт и где находится граница приемлемого риска.
Это помогает выбирать между новой функциональностью, техническим долгом и работой над устойчивостью. Не каждый инцидент требует архитектурной революции, но систематическое превышение допустимого бюджета становится сильным аргументом для изменений.
Важно, чтобы SLO измерял то, что действительно важно клиенту или бизнес-процессу. Метрика доступности сервера бесполезна, если пользователь всё равно не может завершить заказ.
Что получает клиент
Клиент получает более предсказуемый сервис. Компания заранее определяет, какие операции должны быть особенно надёжными и где сбои неприемлемы.
Одновременно клиент выигрывает от того, что продукт не замораживается ради недостижимого идеала. Новые функции продолжают появляться, пока фактический уровень риска остаётся в согласованных пределах.
Чем мы за это платим
Нужно правильно выбрать показатели, построить измерение и договориться о целях. Это организационная работа, а не только настройка мониторинга.
Слишком мягкий SLO может легализовать плохой сервис. Слишком жёсткий — заставить компанию постоянно тратить деньги на запас надёжности, который клиенту не нужен.
Есть и культурная цена: если Error Budget превращается в инструмент наказания, команды начинают скрывать проблемы или оптимизировать метрики вместо качества.
Когда SLO и Error Budget не нужны
Для маленькой внутренней системы без существенной цены простоя формальная система целей может быть избыточной. Иногда достаточно базового мониторинга и здравого смысла.
Подход становится особенно полезен, когда сервис критичен, релизы происходят часто, несколько команд спорят о приоритетах или стоимость дополнительной надёжности уже заметна для бизнеса.
Что стоит спросить перед решением
- Какой сбой действительно чувствует клиент или бизнес-процесс?
- Какова цена минуты или часа недоступности для разных функций?
- Какая метрика отражает реальный пользовательский результат?
- Сколько надёжности мы готовы покупать деньгами и скоростью изменений?
- Что команда должна делать, когда Error Budget исчерпан?
В итоге
SLO не обещает идеальную систему. Он помогает договориться, насколько хорошей она должна быть.
Для бизнеса это способ перестать покупать надёжность вслепую и связать допустимый риск со скоростью развития продукта.