SLO/SLA и метрики

SLO/SLA и метрики

1) Термины и иерархия

SLI (Service Level Indicator) — измеримый показатель «как видит нас пользователь»: доля успешных запросов, p95 латентности, свежесть данных, доля успешно обработанных батчей и т. п.
SLO (Service Level Objective) — целевое значение SLI на интервале наблюдения (28/30/90 дней). Пример: «99.9% запросов /pay завершаются ≤ 400 мс».
Error budget — 1 − SLO. При SLO 99.9% бюджет ошибок = 0.1% времени/запросов.
SLA (Agreement) — юридически значимый уровень обслуживания: включает SLO, измерение, исключения, компенсации/штрафы.

2) Принципы проектирования

Симптомы > внутренние метрики. SLI должны отражать реальный пользовательский опыт.
Малое количество ключевых SLI. На сервис — 2–5 основных: успешность, латентность, пропускная способность/свежесть, корректность.
Охват критических путей. Для каждого бизнес-сценария (checkout, login, webhook, ETL-загрузка) — свой набор SLI/SLO.
Строгая семантика «успеха». Не «код 200», а «пользователь получил ответ в срок и результат валиден».
Разделение внешних и внутренних SLO. Внутренние — строже; внешний SLA ≤ на 1–2 девятах ниже.

3) Каталог SLI (референс)

3.1 API/онлайн-сервисы

Успешность: `SLI_success = 1 − (5xx + timeout + business_error) / all_requests`

Латентность: p95/p99 `http_server_duration_seconds` по маршрутам/методам/арендаторам

Пропускная способность: `RPS`/лимиты/квоты

Корректность: доля валидных ответов (сигнатуры, схемы, инварианты)

3.2 Вебхуки/асинхронные доставки

Доставка: доля событий, подтвержденных в T секунд и ≤ N ретраев

Заказчики: доля подписчиков без длительной задержки (пер-тенант)

3.3 Данные/ETL/DWH

Свежесть (freshness): `now − last_successful_ingest_ts`

Полнота: `ingested_rows / expected_rows`

Корректность: доля записей, прошедших проверки качества

Пайплайны: доля джоб завершенных до дедлайна

3.4 Мобильные/клиентские SDK

Клиентский успех: доля сессий без фатальных ошибок

Латентность round-trip: p95 от запроса до рендера

Кэш-хиты: доля обслуженных из кэша (как симптом перформанса)

4) Формулы и примеры целей

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99.95%` на 30 дней → error budget = 0.05% запросов.

• `uptime = (obs_window − downtime) / obs_window`

• `SLO_latency = p95(route="/pay") ≤ 400 ms` на 7-дневных срезах, с исключением кэш-прогревов (1%)

• `SLO_freshness(dataset="orders") ≤ 10 min` p99 за 24 часа.

5) Error budget и управление изменениями

Бюджет (B): `B = 1 − SLO`.
Расход бюджета (burn): отношение фактических ошибок к допустимым.

• Перерасход (burn > 1) → фичфриз, фокус на надежность.
• При burn rate > X в коротком окне — инцидент и кап. меры.
• Планирование: доля спринта на надежность коррелирует с burn за прошлый период.

6) Алертинг: burn rate и многооконные правила

Идея: ловим быстрые утечки и медленный дрейф.

• Критический: «2% бюджета за 1 час» (быстрый пожар).
• Предупреждение: «5% бюджета за 6 часов» (ползучая деградация).

• Короткое окно (минута-час) для быстрых инцидентов.
• Длинное окно (6–24 часа) для трендов.
• Латентность: алерт по p99 > порога ≥5 мин, с подавлением флаппинга и связь с экземпларами трасс.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Многоарендность (multi-tenant) и сегментация

SLI/SLO считаются по арендаторам/планам/регионам, иначе медиана «замажет» провалы.
Минимальное число событий для статистической значимости (guard-rails).
SLA может различаться по тарифам (например, «Pro 99.9%, Free 99.5%»).

8) Связь с наблюдаемостью и трассировками

Метрики SLI — из гистограмм/счетчиков с exemplars → переход в «плохие» трейсы.
Логи — источник причин: таймауты, коды бизнес-ошибок, лимиты.
Для данных — связка с lineage: «какая джоба задержала метрику свежести».

9) Контракты и SLA

• Определения SLI/метода измерения/окна.
• Исключения (плановые работы, форс-мажор).
• Процедура инцидентов и коммуникаций (статус-страница, RFO/RCA).
• Компенсации (service credits) и порядок запроса.
• Юрисдикция, период действия, условия пересмотра.

• Никогда не обещайте публично SLO строже, чем позволяет архитектура и операционные практики.
• Отделяйте внутренние SLO и внешние SLA.

10) Стоимость и приоритизация

Цена девяток растет не линейно. «99.9% → 99.99%» = иной класс архитектуры (N+1, мультизона, актив-актив).
Ставьте SLO на наиболее ценные пользовательские действия.
Контролируйте стоимость телеметрии: downsampling, квоты, реплика и хранение по классам.

11) Процедуры и отчетность

Еженедельные отчеты: выполнение SLO по сервисам/арендаторам, расход бюджета, топ-причины, планы улучшений.
Постинцидентные RCA: связываем с кусками бюджета; ставим задачи на устранение коренных причин.
Фичфриз: критерии включения/снятия.

12) Шаблоны (для быстрого старта)

12.1 Карточка SLO (пример)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12.2 Таблица «зрелости SLO»

13) Примеры правил (фрагменты)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO для данных и ML (особенности)

Сквозные SLO данных: свежесть p99, полнота p99, время «перепроработки» после сбоя.
Контракты данных: ожидаемые схемы, объемы, дедлайны; нарушение → инцидент данных.
ML: SLO на латентность инференса, SLA на доступность фич-стора, мониторинг дрейфа (качество модели — отдельная тема, вне SLA).

15) Интеграция с безопасностью и приватностью

Логи SLI без PII/секретов; токенизация/маскирование.
Аудит изменений SLO/SLA и публикаций отчетов в неизменяемых журналах.
Для регуляторных путей (платежи/PII) — отдельные, более строгие SLO.

16) Чек-листы

Перед запуском сервиса/фичи

• Определены SLI «успех/латентность/пропускная способность/свежесть».
• Заданы SLO и окна; рассчитан бюджет ошибок.
• Настроены burn-rate алерты (короткое+длинное).
• Дашборды RED + exemplars → трассы; рунибуки инцидентов.
• Многоарендные разрезы и пороги значимости.
• Процедура фичфриза и отчетности.

Эксплуатация

• Еженедельный отчет по SLO/burn, планы hardening.
• Переоценка SLO при изменении архитектуры/нагрузки.
• Периодические «инциденты-учения» и обновление рунибуков.
• Контроль стоимости телеметрии и количества SLI.

17) Runbook’и

Runbook: быстрый рост p99 /pay

1. Алерт p99>порог → открыть дашборд → перейти по exemplar в трейс.
2. Найти узкий CLIENT/SERVER-спан, сравнить регионы/версии.
3. Включить деградацию (кэш/лимит/фоллбек), уведомить команду зависимости.
4. После стабилизации — RCA, задачи оптимизации, обновление SLO-замеров.

Runbook: расход бюджета > 50% за неделю

1. Заморозить фичи, поднять приоритет надежности.
2. Кластеризация ошибок: по маршрутам/арендаторам/зависимостям.
3. Выкатить исправления → подтвердить восстановление тренда.
4. Ретроспектива и корректировка алертов/порогов.

18) FAQ

В: Сколько SLO нужно?
О: Минимум на критические пользовательские сценарии: успех + латентность. Все остальное — по необходимости.

В: Что лучше — доступность по времени или по запросам?
О: По запросам — более пользовательская метрика. По времени удобно для сетевых компонентов/инфры.

В: Почему p95, а не среднее?
О: Среднее скрывает хвост; пользователь чувствует p95/p99.

В: Как не «закрутить гайки» слишком сильно?
О: Начните с реалистичных целей (исторические данные), затем ужесточайте по мере зрелости.

• «Наблюдаемость: логи, метрики, трассировки»
• «Распределенные трассировки»
• «Аудит и неизменяемые журналы»
• «Гарантии доставки вебхуков»
• «Шифрование In Transit / At Rest»
• «Происхождение данных (Lineage)»