Сообщить об ошибкеКороткий ответ
Единого шаблона для всех сервисов быть не может — пороги burn rate и окна должны зависеть от индивидуального SLO каждого сервиса, его критичности для бизнеса и допустимого времени реакции; стандартный паттерн — 2–4 пары "короткое+длинное окно" с разной чувствительностью (например, 1ч/5м для немедленной реакции, 6ч/30м и 3д/6ч для менее срочных уровней), формализованные как шаблон с параметрами, а не скопированные вручную для каждого сервиса.
Как это работает подробнее
каждая пара окон (короткое и длинное) ловит деградацию с определённой скоростью burn rate; чем критичнее сервис, тем агрессивнее должны быть пороги быстрого окна и тем быстрее должна приходить критическая нотификация, но при этом возрастает риск ложных срабатываний на кратковременный шум. Формализация порогов через параметризованный шаблон (например, в виде Jsonnet/Helm-шаблона, генерирующего alerting rules из SLO-таргета сервиса) позволяет масштабировать подход на десятки сервисов без ручного копирования формул.
Компромисс: единый универсальный шаблон burn rate проще поддерживать и единообразно понимать всей организации, но может быть неоптимален для крайних случаев (очень высокий или очень низкий трафик); индивидуальная настройка каждого сервиса точнее, но требует больше экспертизы от команды сервиса и усложняет аудит на уровне всей платформы. Решение обычно — параметризованный шаблон с несколькими профилями (Tier 1/2/3) как средний путь, который нужно явно обсуждать с владельцами сервисов, а не навязывать централизовано без контекста их нагрузки.
Пример кода
# Параметризованный шаблон (псевдо-Jsonnet) для Tier 1 сервиса, SLO 99.9%
burnRateAlerts(service="checkout", slo=0.999, tier="1"):
- window: "5m", lookback: "1h", burnRate: 14.4, severity: "critical"
- window: "30m", lookback: "6h", burnRate: 6, severity: "critical"
- window: "2h", lookback: "3d", burnRate: 1, severity: "warning"Что использовать на практике
- Практика. для сервисов с разной критичностью стоит явно разделить уровни серьёзности (например, Tier 1 — критичные для revenue, Tier 2 — важные внутренние, Tier 3 — некритичные) и привязать к ним разные policy реакции (кто дежурит, через сколько минут эскалация, нужен ли post-mortem). Важно также синхронизировать окно расчёта burn rate с реальным периодом SLO (30 дней чаще всего) и пересматривать параметры по факту накопленной статистики ложных/пропущенных срабатываний.
- Практика. Применение одного такого шаблона к 30 сервисам Tier 1 с их индивидуальными
slo-значениями генерирует консистентный набор alerting rules без ручного копирования формул — изменения методологии (например, добавление нового окна) делаются один раз в шаблоне и применяются сразу ко всем сервисам этого tier.
Подводные камни
- Частые ошибки. копировать пороги burn rate из одного сервиса в другой без адаптации к его собственному трафику и паттернам нагрузки; не формализовывать генерацию правил как шаблон, из-за чего при изменении SLO одного сервиса приходится вручную искать и чинить разбросанные по разным файлам alerting rules; забывать, что сервисы с низким трафиком статистически менее стабильны в коротких окнах (меньше данных для усреднения), что требует либо более длинных окон, либо других метрик вообще.