7 мая 2026 г.·5 мин чтения

SLA, SLO, SLI на собеседовании системного аналитика

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Содержание:

Зачем спрашивают на собесе SA

SA закладывает в требования non-functional, в том числе SLA. На собесе SA: «отличие SLA / SLO / SLI», «как сформулировать SLO», «что такое error budget». Senior — нюансы percentile metrics, multi-window burn rate.

SLI: метрика

Service Level Indicator — что измеряем.

SLI = good_events / total_events

Примеры:

  • Доступность: successful requests / total requests.
  • Latency: requests with p < 300ms / total.
  • Throughput: successful jobs / scheduled jobs.
  • Quality: valid responses / total.

Свойства хорошего SLI:

  • Измеряется на стороне клиента (или близко к нему).
  • Реальная пользовательская боль.
  • Простая формула.

SLO: цель

Service Level Objective — целевое значение SLI за период.

SLO: 99.9% availability over 30-day rolling window
SLO: p95 latency < 300ms over 7 days

Не 100%. Любая система имеет небольшие сбои. 100% — недостижимо и не нужно.

Уровни:

  • 99% — 7.2 часа downtime / месяц. OK для внутренних tools.
  • 99.5% — 3.6 часа.
  • 99.9% — 43.8 минут (3 девятки). Стандарт SaaS.
  • 99.95% — 21.9 минут.
  • 99.99% — 4.4 минуты (4 девятки). Финансы, критическая infra.
  • 99.999% — 26 секунд (5 девяток). Только специальные системы (телеком).

Каждая девятка — порядок дороже в эксплуатации.

SLA: контракт

Service Level Agreement — формальный договор с консекуенциями.

  • Между провайдером и клиентом (внешний SLA).
  • Внутри компании (внутренний SLA, реже).

Структура:

  • Целевые метрики (SLO).
  • Период измерения.
  • Штрафы за нарушение (credits, refunds).
  • Исключения (force majeure, planned maintenance).
  • Reporting.

Связь: SLI ⊂ SLO ⊂ SLA. SLA — обещание клиенту, SLO — внутренний таргет, обычно строже SLA.

Error budget

Error budget = 1 - SLO. Сколько «можно сломаться».

SLO 99.9% → error budget 0.1% = 43.8 минут / месяц

Логика:

  • Если budget есть — можно деплоить рискованные изменения.
  • Если budget исчерпан — фокус на стабильность, замораживаем фичи.

Burn rate. Как быстро тратится budget.

Если SLI = 99% (вместо 99.9% target) → burn 10× нормы

Multi-window burn rate alerting. Стандарт Google SRE — алертить по нескольким окнам (1h fast, 6h medium). Точнее, чем «N% за час».

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Типичные SLI и SLO

Web API:

  • Availability: 200/300 responses / total responses ≥ 99.9%.
  • Latency p95: < 300ms.
  • Latency p99: < 1s.

Async pipeline (ETL):

  • Freshness: data за t-1 доступна к 09:00 в 99% дней.
  • Job success rate ≥ 99%.

Batch reports:

  • Время выполнения < 4 часа.
  • Точность данных = 99.99%.

Streaming:

  • E2E latency p95 < 5s.
  • Lag < 1 минуты.

Что прописывает SA

В нефункциональных требованиях:

Раздел: Производительность
Раздел: Надёжность

NFR-1: API /api/orders должен возвращать ответ за < 300ms (p95) при 100 RPS.
NFR-2: Доступность API ≥ 99.9% за календарный месяц.
NFR-3: При недоступности БД - graceful degradation (кэшированные данные, явное сообщение).
NFR-4: Recovery после crash < 5 минут (MTTR).

Эти SLO — основа для SRE / DevOps выбора инфраструктуры (HA, replication, monitoring).

SA участвует в:

  • Формулировке SLO с продуктом + SRE.
  • Согласовании SLA с клиентом (для B2B).
  • Описании incident response.
  • Обновлении SLO при изменении бизнеса.

Частые ошибки

100% availability target. Недостижимо и дорого. 99.9% / 99.95% — реалистично.

SLO без error budget logic. Без budget'а SLO — просто число. Логика «budget exhausted → stop new features» — критична.

Avg latency вместо percentile. Среднее скрывает выбросы. Используй p95 / p99.

SLI на стороне сервера. Игнорирует сеть, CDN, клиентскую обработку. Меряй ближе к клиенту.

Один SLO на всё. Разные endpoints / операции имеют разную важность. Группировать.

Не пересматривать SLO. Бизнес меняется, нагрузка растёт — SLO должен обновляться. Раз в квартал — review.

Считать downtime только полные обвалы. Деградация (50% запросов медленные) — тоже нарушение.

Связанные темы

FAQ

Что такое MTTR / MTBF?

MTTR (Mean Time To Recovery) — среднее время восстановления после инцидента. MTBF (Mean Time Between Failures) — между сбоями. Метрики надёжности.

SLA для внутренних команд нужен?

Часто внутренние OLA (Operational Level Agreement) или просто SLO — без формальных штрафов.

Кто отвечает за SLO?

Совместно — продукт + SRE / DevOps. SA фасилитирует обсуждение, фиксирует в требованиях.

Это официальная информация?

Нет. Статья основана на Google SRE Book, материалах по reliability engineering.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.

Ещё по теме