От инцидента к enforcement: SLO burn до верифицированного исправления за 35 минут

Алерт SLO burn срабатывает в 10:47. Без непрерывного профилирования и распределённых трейсов дежурный тратит день на угадывание. С ними она находит первопричину и выпускает исправление к 11:22. Окно в 35 минут — не удача; это возврат предыдущих инвестиций в observability под давлением.

Инцидент: /checkout p99 сжигает SLO

В 10:47 срабатывает алерт: “checkout SLO p99 burn rate 14x — 12 часов error budget сожжено за 6 часов.”

Дежурный инженер открывает единый дашборд. Деплоев в последний час нет. Трафик на базовом уровне. Это не спайк — что-то изменилось в downstream-сервисе.

Шаг 1: Observe — 60 секунд

Prometheus: /checkout p99 вырос с 240 мс до 1,4 с. Начался примерно два часа назад. RPS ровный. Error rate ровный. Чистая деградация латентности.

RUM: LCP на стороне клиента не затронут. Это server-side проблема, не bundle-регрессия.

Шаг 2: Profile — 90 секунд

Pyroscope, отфильтрованный по /checkout за последние два часа:

runtime.scanobject:   22%   (базовый: 4%)
runtime.mallocgc:      9%   (базовый: 2%)
encoding/json.Marshal: 24%  (базовый: 4%)
handlers.Checkout:      6%
pgx.Query:             12%

GC-фреймы выросли с 6% до 31%. JSON Marshal вырос с 4% до 24%. Что-то производит намного больше мусора и сериализует намного большие payload, чем прежде.

Шаг 3: Classify — 60 секунд

Allocation-bound (family: GC / фрагмент 04), причём overhead сериализации указывает на необычно большой ответ, производимый, а не только обрабатываемый. Это паттерн family N+1 (фрагмент 05), применённый к межсервисным payload: что-то upstream начало возвращать bulk-данные там, где было достаточно summary.

Амдал по совокупным фреймам GC + Marshal (55%): 1 / (1 - 0,55) = 2,2x. Это снизит p99 с 1,4 с до 636 мс — всё ещё выше SLO 200 мс. Первопричина — не просто “GC горячий”; это то, что вызывает давление GC и Marshal.

Шаг 4: Корреляция трейсов — 5 минут

Открыть Tempo, отфильтровать по медленным /checkout трейсам за последние два часа. Waterfall показывает:

[span] handle_request          1820мс
  [span] auth_check               5мс
  [span] order_query             340мс   (базовый: 12мс)
  [span] inventory_check         850мс   (базовый: 80мс)
  [span] payment_call            280мс   (базовый: 90мс)
  [span] serialise_response      340мс   (базовый: 8мс)

Каждый downstream span и шаг сериализации деградировали на один и тот же множитель. Это паттерн upstream-сервиса, возвращающего ответ намного больше ожидаемого — каждый потребитель раздувается пропорционально.

Проверить историю деплоев: inventory-service выпущен в 10:31 — за 16 минут до начала SLO burn. Diff: добавлено include_full_sku_details: true в ответ /inventory. Прежде возвращались только SKU ID; теперь — полные SKU-объекты. Payload ответа: 8 КБ → 85 КБ на вызов.

Сервис /checkout получает 85 КБ, десериализует (больше аллокаций), выбирает 0,1% нужных данных, затем сериализует собственный ответ с раздутыми данными инвентаря. Все три центра затрат — GC, Marshal, downstream latency — ведут к одной причине.

Шаг 5: Fix — 15 минут

Два параллельных действия:

1. Откатить деплой inventory-service через консоль деплоев.
2. Добавить защитную проверку в /checkout: отклонять любой ответ инвентаря более 64 КБ с ошибкой до обработки.

Оба выпущены в течение 15 минут.

Шаг 6: Verify — 10 минут

Pyroscope после отката: scanobject возвращается к 4%, mallocgc — к 2%, json.Marshal — к 4%. Профиль на базовом уровне.

Prometheus: /checkout p99 на 235 мс в течение 5 минут после завершения отката. Burn rate SLO падает до 0,1x.

Подтверждено улучшение и локального профиля, и headline-метрики.

Шаг 7: Enforce — следующий спринт

Три enforcement-действия, принятые в следующем спринте:

А. PR gate: размер межсервисного ответа. Любой PR к любому сервису, изменяющий схему ответа, должен пройти contract test, проверяющий, что размер тела не превышает 2x текущего медианного. PR, увеличивающие ответ более чем в 2 раза, требуют явного ревью SRE.

Б. Production alert: p99 размера payload на endpoint. Добавить метрику, отслеживающую p99 байт тела ответа на downstream вызов. Алерт при росте более чем на 50% за неделю. При первом срабатывании этого класса регрессии алерт маршрутизируется к дежурному ответственной команды до сгорания SLO.

В. Запись в runbook. “Спайк p99 на /checkout с пропорциональной деградацией всех span → проверить деплои upstream за последние 2 часа на изменения схемы ответа. Проверить inventory-service в первую очередь.” Следующий дежурный решит ту же задачу менее чем за 5 минут вместо начала с нуля.

Итого от алерта до исправления: 35 минут. Итого до enforcement: один спринт (1 неделя). Инженерных часов: ответ на инцидент + postmortem + enforcement: 6 часов. Без непрерывного профилирования + трейсов: оценочно 4–8 часов только на инцидент.