SLA, SLO и KPI надежности

1) Термины и различия

SLI (Service Level Indicator) — измеряемый индикатор качества (например, доля успешных запросов, p95 латентности).
SLO (Service Level Objective) — целевое значение SLI за окно времени (например, «успешность ≥ 99.9% за 28 дней»).
Ошибка бюджета (Error Budget) — допустимая доля невыполнения SLO: `1 − SLO`.
SLA (Service Level Agreement) — контрактные обязательства с штрафами/кредитами (внешние).
KPI надежности — операционные метрики процесса (MTTD/MTTA/MTTR/MTBF, %автоматических митигейтов, покрытие алертами и т.п.).

💡 Правило: SLA ≤ SLO; внешний контракт не должен быть строже внутренней цели сервиса.

2) Как выбирать SLI (на базе Golden Signals)

1. Latency — p95/p99 для ключевых эндпоинтов.
2. Traffic — RPS/RPM/поток сообщений.
3. Errors — доля 5xx/бизнес-ошибок (например, платежные «decline по вине PSP» исключать).
4. Saturation — насыщение ресурсов (CPU/RAM/IO/lag).

Критерии хорошего SLI:

Коррелирует с пользовательским опытом (user-perceived).
Технически доступен и стабилен в измерении.
Контролируем (возможны действия для улучшения).
Низкая стоимость сбора.

3) Формулы и примеры

3.1 Доступность (availability)


Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Пример: SLO 99.9% за 30 дней → бюджет ошибок = 0.1%, что эквивалентно 43 мин 12 сек недоступности.

3.2 Латентность

SLO по латентности формулируем как долю запросов, укладывающихся в порог:


Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3.3 Платежи (бизнес-уровень)


Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

💡 Исключаем «decline по карте клиента» из отказов сервиса; включаем только вины платформы.

4) Ошибочный бюджет и burn-rate

Ошибка бюджета — ваш «топливный бак» для инноваций (релизы, эксперименты).

Burn-rate — скорость потребления бюджета:

быстрый канал (детект за ~1 ч),
медленный канал (тренд за ~6–12 ч/24 ч).

Пороговые идеи:

Если burn-rate > 14.4 за 1 час — SEV-1 (съедим дневной бюджет за ~100 мин).
Если burn-rate > 6 за 6 часов — SEV-2 (быстрая деградация).

5) Алертинг по SLO (multi-window, multi-burn)

Индикатор ошибок: доля 5xx или нарушений латентности.

Примеры PromQL (обобщенные):

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

Для SLO по латентности используйте процентильные гистограммы:

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) Примеры SLI/SLO по доменам

6.1 API-шлюз/Edge

SLI-Errors: доля ответов 5xx < 0.1% (28d).
SLI-Latency: p95 ≤ 250 мс (день).
SLO: Availability ≥ 99.95% (квартал).

6.2 Платежи

SLI-Success: оплат успешных (исключая клиентские отказы) ≥ 99.8% (28d).
SLI-Latency: авторизация ≤ 2 секунды для 99% (день).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6.3 Базы данных (PostgreSQL)

SLI-Lag: репликационный лаг p95 ≤ 1 сек (день).
SLI-Errors: доля ошибок запросов ≤ 0.05% (28d).
SLO: доступность кластера ≥ 99.95%.

6.4 Очереди/Стриминг (Kafka)

SLI-Lag: потребительский лаг p95 ≤ N сообщений (час).
SLI-Durability: подтверждение записи ≥ 99.99% (28d).
SLO: доступность брокеров ≥ 99.9%.

7) KPI процесса надежности

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

% инцидентов с автоматической митигацией

Покрытие SLO/алертами топ-путей трафика (целевое ≥ 95%)

Доля релизов с канареечным этапом

Потребление ошибочного бюджета по командам/фичам

8) Как ставить SLO реалистично

1. Измерьте текущую базовую надежность (3–4 недели).
2. Определите «чувствительные» пользовательские пути (логин, депозит, игра).
3. Учтите стоимость каждого девиации (время, деньги, репутация).
4. Выберите амбициозную, но достижимую цель (улучшение на 10–30% к базовой).
5. Пересматривайте ежеквартально.

Анти-паттерны:

Сразу «пять девяток» без обоснования.
SLO по метрикам, не видимым пользователю (например, CPU без связи с UX).
Слишком много SLO → распыление фокуса.

9) Отчетность по SLO и бюджетам

Стандартный отчет (еженедельно/ежемесячно):

Выполнение по каждому SLO: факт vs цель, тренды, confidence.
Сводка потребления ошибок: сколько бюджета «сожжено», чем, кем (релиз/инцидент).
Топ-пять причин деградаций, CAPA-план и статус задач.
Влияние на бизнес: конверсия, ND, удержание, LTV.

10) Связь с релизной политикой

Бюджет ошибок < 50% → свободные релизы.
50–80% → «осторожный режим»: только low-risk/канареечные выкладки.

💡 80% → заморозка релизов, фокус на стабилизации и долге.

11) SLA (договорные) — шаблоны пунктов

Обязательство доступности: например, 99.9%/месяц.
Исключения (Force Majeure): DDoS вне разумного контроля, провайдеры третьих сторон.
Окно измерения и зона ответственности: источники метрик, метод расчета.
Кредиты/штрафы: таблица уровней (например, недоступность 60–120 мин → кредит X%).
Процедуры эскалации и уведомлений: сроки, каналы.
Данные и приватность: маскирование, хранение, Legal Hold.
План работ по предотвращению повторов (CAPA) в случае нарушения.

💡 Внешний SLA должен ссылаться на конкретные, проверяемые SLI и методику расчета.

12) Инструменты измерения

Пассивные метрики: Prometheus/Mimir/Thanos, экспортеры.
Логи: Loki/ELK для подсчета успехов/ошибок на уровне бизнеса.
Синтетика: активные пробы (логин/депозит/игра) по cron.
Трассировка: Tempo/Jaeger для «узких мест» p99.
Оплата/финансы: источники ground truth для платежного SLI.

13) Примеры запросов (шаблоны)

Доля успешных API-запросов (исключая 4xx как клиентские):

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

SLO-карточка:

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

Платежный успех (по бизнес-событиям в логах/стриме):


success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

💡 Уточните фильтры, чтобы исключать «decline по клиенту».

14) ФинОпс и надежность

Cost per 9: стоимость добавления «девятки» растет экспоненциально.
Кривая выгод: оптимум там, где прирост выручки/снижение потерь ≥ стоимость дополнительных «9».
Портфель SLO: разные уровни для разных путей (критичные платежи «дороже», отчетность «дешевле»).

15) Качество SLO/алертов — чек-лист

SLI коррелирует с UX и бизнес-метриками.
Окно и агрегирование согласованы (rolling 28d/квартал).
Алерты multi-window, без флаппинга, с ролевой маршрутизацией.
Документация: владелец, формула, источники, runbook.
Демо-панель SLO с ошибочным бюджетом и burn-индикаторами.
Регулярный пересмотр целей (ежеквартально).
Тесты синтетики по ключевым сценариям.

16) План внедрения (4 итерации)

1. Неделя 1: инвентаризация пользовательских путей, черновики SLI, базовые дашборды.
2. Неделя 2: формализация SLO, расчет бюджетов, алерты (fast/slow burn).
3. Неделя 3: интеграция с процессом инцидентов/релизов, freeze-правила.
4. Неделя 4+: договорные SLA, квартальные ревью, финопс-модель «cost per 9».

17) Мини-FAQ

Нужно ли иметь один SLO на сервис?
Лучше 2–3 ключевых (успех + латентность) вместо десятков второстепенных.

Что делать, если бюджет исчерпан?
Заморозка релизов, фокус на стабилизации и CAPA, снятие экспериментальных фич.

Как избежать конфликта между скоростью релизов и надежностью?
Планируйте релизы «по бюджету», внедряйте канареечные выкладки и feature-flags.

Итог

Надежность управляется не набором разрозненных метрик, а системой: SLI → SLO → ошибка бюджета → burn-алертинг → процесс инцидентов → CAPA → SLA. Стандартизируйте определения, источники данных и отчетность, привяжите цели к пользовательскому опыту и экономике, и регулярно пересматривайте уровень «девяток» в зависимости от реального ROI.

SLA, SLO и KPI надежности

MTTD (Mean Time To Detect)

MTTR (… To Restore)

% инцидентов с автоматической митигацией

Доля релизов с канареечным этапом

Итог

Свяжитесь с нами

Быстрая связь

Видео скоро обновится

Мы сейчас очень загружены проектами