Как идентифицировать причины медленной работы сервиса при резком росте трафика

Что проверяют

Есть ли у вас порядок действий под давлением: сначала найти узкое место по метрикам, потом чинить. Следом обычно спрашивают, что вы сделаете в первые пятнадцать минут инцидента и как отличите медленный код от исчерпанного пула или тормозящей зависимости.

Как отвечать

Идите сверху вниз, от симптома к причине:

• метрики сервиса: запросы, ошибки и время ответа по эндпоинтам, причём перцентили p95 и p99, а не среднее. Spring Boot Actuator с Micrometer отдают это в Prometheus, смотрите в Grafana;
• JVM: CPU, заполнение heap после сборки, частота и длина пауз GC (логи через -Xlog:gc*), число потоков. Если heap после каждой сборки растёт, это утечка или раздутый кеш;
• пулы и очереди: HikariCP (hikaricp.connections.pending, active), потоки Tomcat (по умолчанию server.tomcat.threads.max равен 200), очереди executor. Долгое ожидание соединения при спокойной базе значит, что упёрлись в пул, а не в базу;
• зависимости: трейсинг через OpenTelemetry показывает, в каком спане уходит время: база, соседний сервис, Redis;
• снимки живого процесса: несколько jcmd <pid> Thread.print с интервалом. Если потоки стоят в одном месте (ожидание соединения, synchronized), причина видна сразу. Для CPU подойдут async-profiler или JFR, он работает на проде с малыми накладными;
• база: pg_stat_statements, блокировки, план через EXPLAIN ANALYZE.

Затем разделите срочное и правильное. Срочно: масштабировать, включить rate limiting, отключить тяжёлые фичи. Потом воспроизвести нагрузку в Gatling или JMeter и закрепить исправление.

Где спотыкаются

Сразу предлагают добавить инстансов. Если узкое место в базе, новые инстансы откроют больше соединений к ней и сделают только хуже.

Смотрят на среднее время ответа. При росте трафика первыми портятся хвосты: среднее выглядит прилично, пока p99 уже упирается в таймауты.

Начинают с профилировщика на своей машине. Локально нет ни нагрузки, ни реальных данных, картина будет другой, снимать нужно на проде или на стенде под нагрузкой.