SLO-платформы и 90-дневный rollout

Команда шестой раз в этом месяце пишет один и тот же 14.4x burn-rate PromQL — другой сервис, та же математика, другая опечатка в строке 4. Recording rule был неправильным. Алерт не сработал во время инцидента. Никто не заметил до постмортема.

Почему ручное написание — ловушка

Канонический MWMBR-набор для одного SLO требует:

• 6 recording rules (ratio_rate на каждое окно: 5м, 30м, 1ч, 6ч, 3д и вариант для медленного горения)
• 3 alert rules (14.4x page, 6x page, 1x ticket), каждый с AND между двумя окнами
• 2 dashboard-панели (burn rate во времени, остаток бюджета)

Ручное написание этого на 80 сервисов означает 480 recording rules и 240 alert-выражений. Любой из множителей 14.4 * 0.001 может быть неправильным (не та SLO-цель, не то окно). Ошибка тихая — recording rule вычисляет значение, алерт срабатывает или нет, и никто не знает, что математика была неправильной, пока реальный инцидент не перестаёт пейджить.

SLO-платформы существуют для этого: ты описываешь SLI и цель в YAML-декларации, платформа генерирует PromQL.

Основные платформы

Минимальная декларация Sloth:

version: "prometheus/v1"
service: checkout
slos:
  - name: availability
    description: "Checkout-запросы успешны"
    sli:
      events:
        error_query: sum(rate(http_requests_total{status=~"5..",job="checkout"}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="checkout"}[{{.window}}]))
    objective: 99.9
    alerting:
      name: CheckoutAvailability
      page_alert:
        labels:
          severity: page
      ticket_alert:
        labels:
          severity: ticket

Sloth читает {{.window}} как шаблонную переменную и выдаёт все шесть recording rules с правильными значениями окна. Burn rates (14.4x / 6x / 1x) и AND-логика между окнами инжектируются автоматически.

Паттерн 90-дневного SLO-rollout’а

SLO-adoption чаще проваливается на культурном уровне, а не техническом. Типовой паттерн:

Недели 1–2 — одна journey, одна команда: Выбери самый важный user journey (checkout, логин, API-эндпойнт, за который платят клиенты). Определи SLI на уровне API gateway. Поставь консервативную цель (начни с 99% даже если кажется, что можно 99.9% — быстро узнаешь baseline). Инструментируй счётчики, добавь Sloth-декларацию, убедись, что recording rules появились в Prometheus.

Недели 3–4 — верификация SLO и бюджета: Наблюдай SLO две недели. Baseline error rate такой, как ожидался? SLI коррелирует с реальными репортами пользователей? Скорректируй цель если базовый уровень значительно лучше (ужесточи) или хуже (слишком жёсткие SLO создают культуру постоянной заморозки — ослабь). Составь черновик error budget policy, но пока не подписывай.

Недели 5–8 — алертинг и подпись policy: Включи MWMBR-алерты. Добавь SLO-дашборд. Проведи fire drill: намеренно сломай сервис на 5 минут и убедись, что 14.4x-алерт срабатывает в течение нескольких минут, пейджит on-call, и гаснет в течение 5 минут после фикса. Подпиши error budget policy с director-level одобрением. Донеси policy до всех стейкхолдеров.

Недели 9–12 — rollout на 5–10 сервисов: Тиражируй паттерн на другие сервисы. Каждая команда использует один Sloth YAML-шаблон. Платформенная команда владеет генератором; продуктовые команды — своими SLO-целями. Проведи первый ежеквартальный SLO-пересмотр: какие SLO запускали алерты, которые имели значение; какие были шумом?

После 90 дней — проверка культуры: Опроси on-call-команды: реагируют ли они на SLO-алерты или игнорируют? Проверь: происходят ли на самом деле feature-заморозки при исчерпании бюджетов? Если нет — повтори коммуникацию policy. 90-дневная точка — когда нужно смотреть, покрывают ли SLO правильные journeys: пробелы на первом проходе обычны.