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

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

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

Как отвечать

Покажите последовательность и инструменты Java-стека:

• сузить проблему: с какого момента, на всех ли инстансах, что менялось (релиз, конфиг, нагрузка, внешняя зависимость). Совпало с релизом: сначала откат, разбор потом;
• метрики: Micrometer и Spring Boot Actuator отдают их в Prometheus, в Grafana смотрите перцентили задержек, долю ошибок, пул соединений HikariCP, паузы GC, заполнение heap;
• логи и трассировка: структурированные логи с traceId, централизованный сбор (ELK, Loki), трассировка через OpenTelemetry. По одному traceId видно, в каком сервисе застрял запрос;
• диагностика JVM: jcmd <pid> Thread.print для дампа потоков (дедлок, все потоки ждут пул), jcmd <pid> GC.heap_dump и Eclipse MAT для утечек памяти, Java Flight Recorder с малыми накладными расходами прямо на проде, async-profiler для CPU;
• база: медленные запросы, блокировки, план выполнения, N+1 от Hibernate.

Закончите постмортемом без поиска виноватых: хронология, корневая причина, что добавили в алерты и тесты. Для истории из опыта нужны ваши реальные симптомы и цифры. Если крупных инцидентов не было, так и скажите и разберите сценарий вслух, например рост задержек из-за исчерпания пула соединений.

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

Начинают с чтения кода и гипотез, не посмотрев на метрики и не сопоставив начало проблемы с деплоями и изменениями конфигурации.

Перезапускают сервис до снятия дампов. Рестарт лечит симптом и уничтожает улики, поэтому дамп потоков и кучи снимают до него, а флаг -XX:+HeapDumpOnOutOfMemoryError стоит держать включённым заранее.

Называют причину без проверки. «Упала база» это симптом, а корневая причина, например, миграция без индекса. Нужно рассказать, как вы подтвердили гипотезу и как убедились, что исправление сработало.