SLI vs технические метрики — дискуссия в чате ALLSLO

Идея

Не каждая техническая метрика является SLI, даже если она «ведёт себя как SLI».

SLI — это всегда метрика с точки зрения пользователя. Технические метрики (глубина очереди, CPU, lag) нужны инженерам и менеджерам, но к SLO их «натягивать» опасно.

Ключевые тезисы

SLI ≠ техническая метрика

• SLI должен отражать пользовательский опыт, а не внутреннее состояние системы
• Глубина очереди пользователю не важна — важен результат (данные доставлены или нет)
• «Не SLI, но ведёт себя как SLI» — это технический health-индикатор, не SLO

Blackbox — только генератор трафика

• Blackbox имеет дискретность: не отличит минуту простоя в прайм-тайм от простоя в 5 утра 1 января
• Не позволяет точно определить виновную команду при инциденте
• Правильная роль blackbox — генерировать трафик там, где его мало; SLI строить по данным балансера или приложения (whitebox)

Владение — основа SLO

• Самое важное при построении SLO — чёткое определение владельца
• SLO, которым владеют >1 команды → конфликты при инцидентах («разбудили не ту команду»)
• Границы сервиса определяются в первую очередь, до написания SLI

Прогрессивный SLI для очереди

Если всё же нужно выразить глубину очереди через SLI-подобную метрику (пример: Kafka, Sloth):

errorQuery:
  clamp_max(
    (
      max(
        sum by (consumergroup, topic, partition) (
          last_over_time(kafka_consumergroup_lag{...}[{{.window}}])
        )
      ) / 20 - 1  # каждые 20 сообщений сверх первых 20
    ) * 5.0 / 100  # уменьшают SLI на 5%
  , 1) > 0
  OR on() vector(0)

totalQuery: last_over_time(obviously_non_existent_metric[{{.window}}]) > 0 OR on() vector(1)

При 420+ сообщениях SLI → 0. Принцип: SLI = 1 - bad / total

Итоги

Рекомендации

1. Не смешивать SLI и технические метрики — вести их в разных системах: SLO в error budget, технические health — в отдельных дашбордах с алертами
2. Менеджеру нужен не SLO, а SLA на технический процесс — помогите ему сформулировать это корректно (например: «lag очереди не превышает X ms в 95% времени за месяц»)
3. Определять владельца SLO до его создания — если ответ «несколько команд», SLO писать нельзя, сначала разбить на компоненты
4. Blackbox использовать только как источник трафика — SLI строить по данным изнутри системы (балансер, трейсы, логи)
5. Учитывать вес инцидента во времени — минута простоя в прайм-тайм ≠ минута простоя ночью; закладывать это в budget burn rate или веса алертов
6. Playwright/synthetic = blackbox — сложные сценарии (30 шагов + авторизация) дают много ложных срабатываний; рассматривать их как smoke-тест, не как основу SLI