Как рассчитывается и устанавливается SLO для сервиса?

Как рассчитывается и устанавливается SLO для сервиса

SLO (Service Level Objective) — это целевой порог для одной или нескольких SLI (метрик сервиса), выраженный числом (проценты, миллисекунды, пропускная способность) за выбранный период. Установка SLO — не арифметика в вакууме, а процесс согласования требований бизнеса, ожиданий пользователей и технических возможностей.

Пошаговый процесс установки SLO

  1. Определите пользователей и критичные сценарии
    — какие пользовательские пути важны (логин, оплата, API), какие функции — критичны для бизнеса.

  2. Выберите корректные SLIs
    — доступность (success rate), latency per endpoint (p95/p99), корректность ответов, throughput. SLI должен прямо отражать пользовательский опыт.

  3. Выберите окно измерения
    — rolling window (например, последние 30 дней) или calendar window (календарный месяц). Rolling даёт более гладкую картину; calendar проще для контрактов.

  4. Соберите исторические данные
    — измерьте реальные SLI за прошлые периоды (недели/месяцы). Это даёт базу для реалистичных целей.

  5. Рассчитайте и установите цель SLO с учётом бизнеса и затрат
    — сопоставьте бизнес-риски (потеря денег, репутации) и стоимость улучшений. Часто начинают с SLO немного выше исторического среднего, затем корректируют.

  6. Вычислите error budget и правила реакции
    — error budget = 1 − SLO (в долях). Определите политики: gating релизов, burn-rate алерты, процедуры при исчерпании бюджета.

  7. Пропишите методику измерения и верификацию
    — точное определение «успеха» запроса, какие запросы исключать, как агрегация и обработка данных.

  8. Документируйте и согласуйте с продуктом/бизнесом/поддержкой
    — кто владеет SLO, что делать при нарушении, ответственные за исправления.

Формулы и примеры (с подробными расчётами)

Временная доступность (time-based)
Availability = (Общее время − Время простоя) / Общее время.

Пример: SLO = 99.9% за 30 дней. Посчитаем допустимое время простоя по шагам.

  • 30 × 24 = 30 × 20 + 30 × 4 = 600 + 120 = 720 часов.

  • 720 × 60 = 720 × (6 × 10) = (720 × 6) × 10 = 4 320 × 10 = 43 200 минут.

  • 43 200 × 60 = 43 200 × (6 × 10) = (43 200 × 6) × 10 = 259 200 × 10 = 2 592 000 секунд.

  • Ненадёжность = 1 − 0.999 = 0.001.

  • Допустимое простое время в секундах = 2 592 000 × 0.001 = 2 592 секунд.

  • 2 592 ÷ 60 = 43 целых минуты, остаток 2 592 − (60 × 43) = 2 592 − 2 580 = 12 секунд → 43 мин 12 с.

Request-based пример
Если за период пришло 10 000 запросов и SLO = 99.95%:

  • Ненадёжность = 1 − 0.9995 = 0.0005.

  • Допустимое число неуспешных запросов = 10 000 × 0.0005. Посчитаем: 0.0005 = 5/10 000, значит 10 000 × 5/10 000 = 5 → 5 запросов.

Error budget и burn rate

  • Error budget = 1 − SLO (в долях). Это «сколько» деградации разрешено.

  • Burn rate показывает, как быстро расходуется бюджет:
    burn rate=ошибки за период / длина периодаerror budget / length(SLO window)\text{burn rate} = \frac{\text{ошибки за период / длина периода}}{\text{error budget / length(SLO window)}}
    практическая интерпретация: если burn rate > 1 — вы расходуете бюджет быстрее, чем запланировано; при высоком burn rate активируются меры (приостановка релизов, срочные исправления).

Как формализовать алерты и политику

  • Алерты на симптомы (p95↑, error rate↑, queue depth↑), не на «сырые» внутренние счётчики.

  • Настройте предупреждения по burn rate (например, burn rate > 2 за 30 минут → notify, >8 → stop releases).

  • Свяжите алерты с runbooks и автоматическими действиями.

Практические советы и подводные камни

  • Не берите слишком много SLIs одновременно — сфокусируйтесь на ключевых пользовательских путях.

  • Учтите cardinality: большое число label-значений делает хранение и расчёт дороже.

  • Документируйте методику (как считаются p95, какие запросы исключены).

  • Ревью SLO регулярно (ежеквартально) и пересматривайте при изменении продукта/архитектуры.

  • Разделяйте SLO для разных классов пользователей или функций (критичные vs вспомогательные).

Операционизация

  • Визуализируйте SLO, SLI и error budget в дашборде.

  • Автоматизируйте подсчёт в rolling window и храните историю для постмортемов.

  • Закрепите владельцев и модель эскалации при сгорании бюджета.

Лучшее SLO — тот, который согласован с бизнесом, реализуем технически и измеряется однозначно.

14-08-2025
Medium 4 просмотров