Slow is the new down: 5 антипаттернов, из-за которых вы не видите деградацию

«Система работает» - любимая фраза дежурного инженера в 3 часа ночи. Uptime 99.9%, алертов нет. Но пользователи уже пишут в поддержку, что «всё тормозит».

Я специально разбираю именно антипаттерны, а не best practices. Списки в духе «сделайте SLO, внедрите трейсинг, настройте synthetic monitoring» все уже читали. Но реальные проблемы обычно прячутся не в незнании, а в привычках: что именно вы смотрите, на что алертите и что считаете «нормальной работой».

И так, начнем!

1. Алерты только на error rate, но не на latency
Классика жанра: p99 улетел в 10 секунд, ошибок ноль, Grafana молчит. Формально система «жива», фактически для пользователя она уже сломана.
Эта логика не новая: Amazon ещё много лет назад показывал, что каждые дополнительные 100 ms задержки снижали продажи примерно на 1%.
Если у вас есть SLO только на availability, но нет SLO или хотя бы алертов на tail latency (p95/p99), у вас есть мониторинг аварий, но не мониторинг производительности.

2. Смотрите на average, а не на percentiles
Средняя latency почти всегда успокаивает сильнее, чем должна.
Если 90% запросов отвечают за 100 ms, а 10% висят по 5 s, среднее может выглядеть ещё «приемлемо». Но именно в этих хвостах и живёт реальная пользовательская боль.
Поэтому смотреть нужно не только на average, а на p95 и p99. Именно они показывают, как система ведёт себя для тех, кому сейчас хуже всего.

3. Нет baseline - нет и деградации
Если вы не знаете, как выглядела нормальная работа неделю назад, то любое замедление легко объясняется фразой «ну вроде так и было».
Так деградация и живёт неделями после деплоя, пока не придёт жалоба от крупного клиента.
Полезно сравнивать метрики не только с фиксированным порогом, но и с той же точкой неделю назад в то же время: это помогает увидеть постепенное ухудшение на фоне сезонности и дневных паттернов.

4. Мониторите сервис, но не зависимости и не пользовательский путь
Ваш API может отвечать за 200 ms, но внутри ждать базу, кеш, DNS, внешний API или сеть между ними. На дашборде сервис зелёный, а пользовательский сценарий уже «разваливается».
Официальная документация OpenTelemetry хорошо формулирует, зачем здесь нужен tracing: trace показывает путь одного запроса через несколько сервисов и помогает понять, где именно ушло время.
Без трейсинга зависимости часто остаются чёрным ящиком. А без synthetic checks или RUM на критические user journeys вы меряете систему изнутри, а не то, что реально видит пользователь.

5. Нагрузочное тестирование только перед релизом
Если вы проверяете производительность только перед большим релизом, то узнаёте о деградации слишком поздно.
Медленные регрессии чаще приходят не как «всё упало», а как накопительный эффект: изменился план запроса, убрали индекс, вырос объём данных, поменялась библиотека, усилилась конкуренция за CPU.
Поэтому зрелая практика сегодня - не только разовые load tests, но и регулярные synthetic latency checks, плюс continuous profiling (Pyroscope, Parca), чтобы ловить деградацию до того, как о ней напишет клиент.

SRE Report 2026 фиксирует важную вещь: почти две трети респондентов уже считают деградацию производительности настолько же серьёзной, как и даунтайм. Но только 26% организаций действительно проверяют, как улучшение производительности влияет на бизнес-метрики вроде revenue или NPS.

То есть проблема уже признана. Но измерять её по-настоящему умеют пока немногие.

Медленная система - это инцидент без пейджера.
Что из этого у вас до сих пор не настроено?

#sre #observability #performance #latency #opentelemetry