SLI (Service Level Indicator, индикатор уровня сервиса) — числовая метрика, характеризующая фактическое качество работы сервиса в конкретный момент или период. SLI — фундамент системы управления надёжностью: без точных измерений невозможно ставить цели (SLO) и брать обязательства перед клиентами (SLA).
Иерархия SLI → SLO → SLA
Три термина часто путают. Они образуют иерархию:
- SLI (Service Level Indicator)
- Фактическая измеренная метрика. Пример: за последние 30 дней 99,92% запросов завершились без ошибки — это SLI.
- SLO (Service Level Objective)
- Внутренняя целевая метрика команды. Пример: цель — SLI availability ≥ 99,9%. SLO устанавливается на основе измеренных SLI с запасом.
- SLA (Service Level Agreement)
- Договорное обязательство перед клиентом с последствиями при нарушении. Пример: гарантируем 99,5%, при нарушении — компенсация. SLA всегда ниже SLO (запас на форс-мажор).
Типичные SLI в хостинге
- Availability (доступность) — процент успешных запросов (HTTP 200–299) к общему числу запросов за период. Наиболее распространённый SLI.
- Latency (задержка) — время ответа сервиса. Обычно измеряется перцентилями: p50 (медиана), p95, p99. p99 = 99% запросов обработано быстрее X мс.
- Error rate (частота ошибок) — процент запросов, завершившихся ошибкой (5xx). Обратная метрика к Availability.
- Throughput (пропускная способность) — количество запросов в секунду (RPS/QPS), обработанных сервисом.
- Durability (долговечность) — для хранилищ: вероятность потери данных. AWS S3 гарантирует 99,999999999% (11 девяток).
- Freshness (актуальность) — для кэшей и реплик: насколько данные актуальны по отношению к источнику.
SLI собирают через Prometheus (метрики), Grafana (визуализация), Grafana Loki (логи), Zabbix. Для availability SLI — внешний мониторинг (Uptime Robot, Pingdom) критичнее внутреннего: он видит то, что видит пользователь.
История
Концепция SLI/SLO/SLA систематизирована в Site Reliability Engineering (SRE) — дисциплине, разработанной Google. Первая публичная формулировка концепции — книга «Site Reliability Engineering» (O'Reilly, 2016), написанная инженерами Google. До SRE компании использовали неформальные метрики или фокусировались только на SLA без понимания, как их достичь. Google ввёл понятие error budget (бюджет ошибок): если SLO = 99,9%, то 0,1% — разрешённый бюджет ошибок за месяц. Когда бюджет исчерпан — новые функции не деплоятся, пока надёжность не восстановлена.
На что обращать внимание
SLI должны измерять то, что важно для пользователя, а не то, что удобно измерять. «Сервер запущен» — плохой SLI; «99% запросов получили ответ менее чем за 500 мс» — хороший. Не устанавливайте слишком много SLI: 3–5 критичных метрик на сервис достаточно. Избыток SLI размывает фокус. Latency SLI лучше измерять на p99, а не на среднем — среднее скрывает «хвостовые» задержки, ощущаемые 1% пользователей. Алертинг строится на SLO, а не на абсолютных порогах: если за 1 час израсходовано 5% месячного error budget — это сигнал к реагированию.
SLI/SLO/SLA в хостинге
SLI (Service Level Indicator) — измеримая метрика: процент успешных HTTP-запросов, время отклика p99, доступность. SLO (Service Level Objective) — внутренняя цель: SLI > 99.5%. SLA — договорная гарантия для клиента. Типичные SLI для хостинга: аптайм (из UptimeRobot), TTFB (время до первого байта), error rate (5xx ответы). Визуализация через Grafana: дашборд с Error Budget — сколько «бюджета ошибок» осталось до нарушения SLO. Prometheus + Zabbix собирают сырые метрики, Loki — логи. SLO жёстче SLA: команда должна превышать внутренний SLO, чтобы всегда выполнять SLA.