Дизайн SLO/SLI

Действуй как Senior SRE. Спроектируй SLO/SLI для сервиса {{service}} с фокусом на сценарий {{user_journey}}.

Что сделать

1. Выбери SLI, отражающие пользовательский опыт. SLI должен измеряться там, где живёт пользователь, а не там, где удобно инженеру.

   • Latency. Распределение времени ответа (p95/p99). Меряется на edge (ingress/LB), а не внутри приложения. Бакетизируй гистограммы заранее — le="0.1,0.3,1,3" под целевые пороги, иначе histogram_quantile соврёт.
   • Availability. Доля «хороших» запросов от всех (good / total). «Хороший» = HTTP 2xx/3xx + (опц.) p99 < N мс. 5xx по таймауту upstream — это твой fail, не клиента.
   • Quality / freshness. Для пайплайнов: max(now() - last_success_ts) < SLA. Для поиска: doc-set coverage, staleness, NDCG.
   • Correctness. Sampled invariant check (например, total order amount == sum of items). Меряется на части трафика, не на всём.

2. Установи порог и окно. Цель = вероятность, что пользователь увидит хорошее поведение в окне N.

   • 99.9% / 30 дней = 43 мин downtime/мес. 99.95% / 30 дней = 21 мин. Если бизнес говорит "five nines" — посчитай вместе с ними бюджет в часах и стоимость каждой девятки.
   • Rolling 28-day window, не календарный месяц — иначе бюджет «обнуляется» 1-го числа и порождает рискованные релизы.
   • Один SLO на один user journey. Не 40 SLO на сервис — никто не будет их читать.

3. Multi-window multi-burn-rate alert'ы (Google SRE workbook). Два сигнала — fast burn (короткое окно) и slow burn (длинное), чтобы поймать и катастрофу, и медленную деградацию.

   • Fast page: burn rate ≥ 14.4 за 1h И burn rate ≥ 14.4 за 5m → сжигает месячный бюджет за 2% времени (≤ 1h до полного выгорания). Severity P1, page on-call.
   • Slow ticket: burn rate ≥ 1 за 24h И burn rate ≥ 1 за 6h → выгорание за < 30 дней. Severity P3, тикет в backlog команды.
   • Двойное окно (длинное + короткое) убирает шум «5 минут шумнули и затихли».

4. Error budget policy — что делает команда при выгорании. Без политики SLO — просто красивая цифра.

   • 0-50% сожжено: норма, релизим как обычно.
   • 50-100%: повышенный rigor — обязательный canary, feature flag по умолчанию off, post-deploy verification усилен.
   • 100%+ (бюджет исчерпан): freeze фич, только bugfix и reliability work до конца окна. Письменное согласие PM + Eng Manager на любое исключение.
   • Если бюджет регулярно выгорает — SLO либо слишком жёсткий (договариваемся с бизнесом снизить), либо архитектура не тянет (инвестируем в reliability).

5. Как договариваться с бизнесом. SLO — это контракт, а не желание SRE.

   • Не «давайте 99.99%», а «99.9% стоит N инженеро-месяцев и Y$ инфры; 99.95% — 3N/3Y; что выбираем?».
   • Покажи историю: реальная availability за 90 дней. Если ты сейчас даёшь 99.7% — обещать 99.99% завтра нечестно.
   • Зафиксируй в письменном виде: SLO, окно, что считается «хорошим запросом», error budget policy. Подписи: SRE lead + Product + Eng Manager.

Anti-patterns

• ❌ SLI на CPU/memory/disk — это not user-facing, это capacity сигналы. Не путать.
• ❌ 100% SLO — невозможно (зависимости, сеть, харды падают). Делает policy бессмысленной.
• ❌ Один alert «availability < 99.9% за 5 минут» — либо шумит, либо пропускает медленную деградацию.
• ❌ SLO, выставленные SRE без бизнеса — нет mandate'а на freeze фич, бюджет всегда «не считается».
• ❌ Меряем на стороне сервиса, не на стороне ingress — пропускаем сетевые таймауты и DNS-проблемы.

Формат вывода

## SLI каталог
| SLI | Definition (PromQL) | Где меряется | Хороший запрос |

## SLO
| User journey | SLI | Target | Window | Error budget (min/мес) |

## Burn-rate alerts
| Severity | Burn rate | Long window | Short window | Routing |

## Error budget policy
- 0-50%: ...
- 50-100%: ...
- 100%+: freeze rules

## Стейкхолдеры и подписи
| Role | Name | Date |

Принцип: SLO без error budget policy — это marketing slide. SLI без user journey — это инженерный фетиш. Связка SLI → SLO → policy → ритуал — то, что делает observability полезной для бизнеса.