Сервис деплоится раз в день, и после одного из релизов начался постепенный рост 5xx ошибок в течение часа, а не сразу. Как подойти к диагностике и откату?

Короткий ответ

Постепенный (не мгновенный) рост ошибок после деплоя часто указывает на утечку ресурса (памяти, соединений, файловых дескрипторов) или на постепенное исчерпание кэша/прогрева, а не на мгновенно ломающий баг — нужно сопоставить время начала роста ошибок с метриками насыщения ресурсов, а не только с моментом деплоя.

Как это работает подробнее

если ошибки появились не сразу после выката, а нарастали, вероятные причины — утечка памяти, приводящая к OOM через время; постепенное исчерпание пула соединений из-за того, что новая версия не закрывает их корректно; либо постепенное "прогревание" проблемы, зависящей от накопленных данных (например, рост размера кэша в памяти).

Пример / кейс

Ожидаемое поведение: если у подов `version=v42` видно устойчивый рост памяти со временем (а у `v41` — нет), это подтверждает утечку в новом релизе; откат через `kubectl rollout undo` должен остановить рост ошибок в течение нескольких минут, пока анализируется причина утечки.

Пример кода

example.shКопировать

# Память подов новой версии за последний час
kubectl top pods -l version=v42 --sort-by=memory
# Сравнение с версией до деплоя (если ещё есть параллельно во время canary)
kubectl top pods -l version=v41 --sort-by=memory

Что использовать на практике

• Практический подход. Сопоставляют таймлайн деплоя с графиками памяти/соединений/файловых дескрипторов по подам/инстансам именно новой версии; если тренд совпадает — это сильный сигнал к немедленному откату, не дожидаясь полного анализа причины (откат можно сделать быстро, root cause анализировать после). Параллельно проверяют логи на исключения, специфичные для новой версии.

Подводные камни

• Частые ошибки. Ждать полного понимания причины перед откатом, затягивая инцидент, когда откат — быстрый и безопасный первый шаг; откатывать не глядя на метрики, когда рост ошибок на самом деле связан с внешней зависимостью, а не с деплоем; не сохранять дампы/логи упавших инстансов перед их перезапуском, что лишает возможности расследовать причину постфактум.