Показатель уровня сервиса (SLI), целевой уровень сервиса (SLO), соглашение об уровне сервиса (SLA) и бюджет ошибок нужны затем, чтобы разговор о надёжности перестал быть спором вкусов и превратился в договорённость о риске.
Глава показывает, как показатели, целевые уровни сервиса и бюджет ошибок связывают продуктовые ожидания с эксплуатацией: по ним читают скорость расходования бюджета, ограничивают релизы и решают, когда системе нужнее починка, чем следующая функция.
На интервью эта тема особенно полезна, потому что через неё легко обсуждать дисциплину измерений, допустимый риск и политику выпуска изменений вместо абстрактной фразы о том, что система просто должна быть стабильной.
Практическая польза главы
Практика проектирования
Переводите цели надёжности в измеримые показатели, целевые уровни сервиса, бюджет ошибок и правила оповещения.
Качество решений
Оценивайте архитектуру через пользовательские пути, скорость расходования бюджета и цену отказа, а не только через среднюю доступность.
Аргументация на интервью
Показывайте, когда команда может ускорять выпуск изменений, а когда должна перейти в режим стабилизации.
Формулировка компромиссов
Явно фиксируйте компромисс между скоростью релизов, ожиданиями клиентов, стоимостью надёжности и внешними обязательствами.
Источник
Google SRE Workbook
Практическое руководство по определению показателей и целевых уровней сервиса и работе с бюджетами ошибок.
«Сервис должен работать надёжно» — фраза, под которой продукт и инженеры понимают разное, пока надёжность не выражена числами. Показатели, цели и соглашения об уровне сервиса и есть тот общий язык: они превращают расплывчатое ожидание в измеримые правила, по которым можно спорить и принимать решения. В этой главе разберём (SLI), (SLO), (SLA), и . Вместе они проводят границу между «можно ускорять релизы» и «пора защищать надёжность». Если нужен широкий контекст по инженерии надёжности сервисов, начните с вводной главы раздела.
Показатели, цели и соглашения об уровне сервиса: чем отличаются
SLI
Показатель уровня сервиса
Service Level Indicator
Измеримый сигнал качества пользовательского пути: , , или .
SLO
Целевой уровень сервиса
Service Level Objective
Целевое значение показателя за период. Например: 99.9% за 30 дней.
SLA
Соглашение об уровне сервиса
Service Level Agreement
Внешнее обязательство, у которого есть цена нарушения: компенсации, штрафы или условия поддержки. Поэтому соглашение об уровне сервиса (SLA) ставят заведомо мягче внутренней цели.
Почему это важно
Единый язык для продукта и инженерии
переводит фразу «сервис должен быть стабильным» в конкретные числа и правила принятия решений.
Контроль релизного риска
даёт формальный критерий: можно ускорять или пора включать .
Прозрачная приоритизация
Когда бюджет на исходе, спор «надёжность или новая фича» решается не голосом самого громкого, а цифрой: команда показывает, во что обходится продолжать выпуск.
Предсказуемые ожидания клиентов
фиксирует внешние обязательства, а целевой уровень сервиса помогает держаться внутри этих границ.
Калькулятор 1: допустимое время недоступности
Бюджет ошибок = 0.100%
Допустимое время недоступности
43 мин
В секундах
2 592
Ошибок на 1M запросов
1 000
Формула: budget = (1 - goal) * period. Например, при целевом уровне 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) - Практики внедрения целевых уровней сервиса в промышленной эксплуатации: правила оповещения, скорость расходования бюджета и рабочий ритм команды.
- Observability & Monitoring Design - Показатели уровня сервиса хороши настолько, насколько надёжны данные под ними; здесь — проектирование метрик, логов и трассировки, на которых эти показатели держатся.
- Performance Engineering - Дополняет работу с показателями задержки через профилирование, планирование ёмкости и бюджеты производительности.
- Release It! (short summary) - Расширяет тему политик надёжности паттернами устойчивости и безопасного выпуска изменений.