Сообщить об ошибкеКороткий ответ
Сначала сравнивают метрики до и после релиза (время ответа по эндпоинтам, нагрузка на БД, использование CPU/памяти), затем сопоставляют список изменений в релизе с затронутыми эндпоинтами, чтобы локализовать подозрительные коммиты, и при необходимости откатывают релиз, пока идёт детальное расследование.
Как это работает подробнее
По дашбордам мониторинга сравнивается поведение «до/после» конкретного момента деплоя — если деградация совпадает по времени с релизом, вероятность, что причина в новом коде/миграции, высокая; далее смотрят, деградировали все эндпоинты или конкретные, что сужает круг подозреваемых изменений.
Пример кода
example.txt
14:00 -- деплой релиза v1.42
14:02 -- p95 latency: 150ms -> 800ms (график на дашборде APM показывает резкий скачок)
14:03 -- проверка: деградировали все эндпоинты или только /orders? -> только /orders
14:04 -- diff релиза: миграция добавила новый JOIN в запрос списка заказов без индекса
14:05 -- решение: rollback до v1.41, индекс добавить и перепроверить план отдельноЧто использовать на практике
- Практика. Частые причины — новая миграция добавила медленный запрос или убрала индекс, новая зависимость или логирование добавили синхронный блокирующий вызов на горячем пути, конфигурация пула соединений или воркеров изменилась неявно; безопасный откат к предыдущей версии — обычно самый быстрый способ вернуть сервис в рабочее состояние.
Подводные камни
- Риск. Начинают профилировать и чинить код в проде вместо немедленного отката при явной деградации, затягивая инцидент; сравнивают метрики без учёта естественных суточных колебаний нагрузки; не используют feature flag, чтобы быстро выключить подозрительную фичу без полного отката.