<b>Аномалия трафика в распределенной системе часто выглядит как «плавающий» инцидент, а не как всплеск</b>

<b>Аномалия трафика в распределенной системе часто выглядит как «плавающий» инцидент, а не как всплеск</b>

В распределенной архитектуре опасны не только пики RPS. Гораздо чаще инцидент маскируется под норму: медленный рост ошибок, смещение латентности между регионами, рост fan-out у одного сервиса, дрейф объемов между очередями и API. Если смотреть только на агрегированный график, можно пропустить деградацию, которая уже режет конверсию и разносит нагрузку по цепочке.

Контроль строят по нескольким плоскостям:
— входной трафик: RPS, p95/p99, доля 4xx/5xx, размер запросов;
— межсервисные вызовы: retry-rate, timeout-rate, circuit breaker opens, неравномерность по shard/region;
— очередь и фоновые задачи: lag, depth, age сообщений, повторная доставка;
— бизнес-сигналы: падение завершенных транзакций при стабильном входе, рост отмен, рассинхрон счетчиков.

Сами пороги лучше не делать статичными. Базовая линия должна учитывать сезонность, день недели, рекламные окна и распределение по сегментам. Для детекта полезнее относительное отклонение и скорость изменения, чем абсолютное значение. Если аномалия видна только в одном дата-центре или у одного пула, это обычно не шум, а локальная деградация сети, DNS, кэша или зависшего downstream.

Отдельно проверяйте корреляцию метрик с логами и трассировками: потеря контекста в одном узле часто выглядит как рост таймаутов везде. Проверяйте логи, истина всегда скрыта в них. Постройте алерты на отклонение формы трафика, а не только на его объем — так вы раньше увидите инцидент и позже получите сюрприз в проде.