SLI, SLO, SLA и бюджет ошибок нужны затем, чтобы разговор о надёжности перестал быть спором вкусов и превратился в договорённость о риске.
Глава показывает, как показатели, целевые уровни сервиса и бюджет ошибок связывают продуктовые ожидания с эксплуатацией: по ним читают скорость расходования бюджета, ограничивают релизы и решают, когда системе нужнее починка, чем следующая функция.
На интервью эта тема особенно полезна, потому что через неё легко обсуждать дисциплину измерений, допустимый риск и политику выпуска изменений вместо абстрактной фразы о том, что система просто должна быть стабильной.
Практическая польза главы
Практика проектирования
Переводите цели надёжности в измеримые показатели, целевые уровни сервиса, бюджет ошибок и правила оповещения.
Качество решений
Оценивайте архитектуру через пользовательские пути, скорость расходования бюджета и цену отказа, а не только через среднюю доступность.
Аргументация на интервью
Показывайте, когда команда может ускорять выпуск изменений, а когда должна перейти в режим стабилизации.
Формулировка компромиссов
Явно фиксируйте компромисс между скоростью релизов, ожиданиями клиентов, стоимостью надёжности и внешними обязательствами.
Источник
Google SRE Workbook
Практическое руководство по определению SLI/SLO и работе с бюджетами ошибок.
SLI / SLO / SLA - это язык, который соединяет бизнес-ожидания и инженерные решения. В этой главе разберём , , , и . Вместе они задают понятную границу между ускорением релизов и безопасным выпуском изменений. Если нужен широкий контекст по SRE, начните с вводной главы раздела.
SLI, SLO и SLA: чем отличаются
SLI
Показатель уровня сервиса
Service Level Indicator
Измеримый сигнал качества пользовательского пути: , , или .
SLO
Целевой уровень сервиса
Service Level Objective
Целевое значение показателя за период. Например: 99.9% за 30 дней.
SLA
Соглашение об уровне сервиса
Service Level Agreement
Внешний контракт с последствиями: компенсациями, штрафами или условиями поддержки.
Почему это важно
Единый язык для продукта и инженерии
переводит фразу «сервис должен быть стабильным» в конкретные числа и правила принятия решений.
Контроль релизного риска
даёт формальный критерий: можно ускорять или пора включать .
Прозрачная приоритизация
Команда может обосновать, почему сейчас важнее задачи по надёжности, а не следующая продуктовая функция.
Предсказуемые ожидания клиентов
фиксирует внешние обязательства, а целевой уровень сервиса помогает держаться внутри этих границ.
Калькулятор 1: допустимое время недоступности
Бюджет ошибок = 0.100%
Допустимое время недоступности
43 мин
В секундах
2 592
Ошибок на 1M запросов
1 000
Формула: budget = (1 - SLO) * period. Например, при SLO 99.9% за 30 дней доступно около 43 минут времени недоступности.
Калькулятор 2: скорость расходования бюджета
Наблюдаемая доля ошибок
0.0240%
Скорость расходования
0.24x
Потрачено в окне
0.03%
Остаток бюджета
84.97%
При текущем темпе бюджет закончится примерно через 106 д 5 ч 0 мин.
Бюджет тратится медленно: есть запас для безопасного выпуска изменений.
Как применять в ежедневной работе
- Выберите 1-3 и определите для них .
- Согласуйте с продуктом и стоимостью отказов.
- Опишите : какие релизы допустимы при скорости расходования бюджета ниже 1x, от 1x до 2x и выше 2x.
- Свяжите и с бюджетом ошибок, а не только с инфраструктурными метриками.
Типичные антипаттерны
Мерить только на уровне инфраструктуры (CPU/RAM), а не на пользовательском пути.
Задавать целевой уровень 99.999% без связи с реальной стоимостью, архитектурными ограничениями и ожиданиями бизнеса.
Использовать как внутреннюю инженерную метрику вместо внешнего контрактного уровня.
Игнорировать и смотреть только на итог месяца, когда бюджет уже исчерпан.
Рекомендации
Определяйте 1-3 ключевых и стройте показатели уровня сервиса именно вокруг них.
Привязывайте релизы к : если бюджет есть, можно принимать риск; если он исчерпан, нужен режим стабилизации.
Используйте быстрые и медленные , чтобы ловить резкие всплески и плавные деградации.
Разделяйте внутренние целевые уровни сервиса и внешние , чтобы честно управлять ожиданиями пользователей.
Источники
Связанные главы
- Site Reliability Engineering (short summary) - Базовая модель SRE: целевые уровни сервиса, бюджеты ошибок, сокращение ручной операционной работы и баланс скорости с надёжностью.
- The Site Reliability Workbook (short summary) - Практики внедрения SLO в промышленной эксплуатации: правила оповещения, скорость расходования бюджета и рабочий ритм команды.
- Observability & Monitoring Design - Покрывает проектирование метрик, логов и трассировки, на которых строятся качественные показатели уровня сервиса.
- Performance Engineering - Дополняет работу с показателями задержки через профилирование, планирование ёмкости и бюджеты производительности.
- Release It! (short summary) - Расширяет тему политик надёжности паттернами устойчивости и безопасного выпуска изменений.