Главная › Новости

Что проверить перед откатом изменений

Опубликовано: 19.07.2026

Откат — это не кнопка «отменить» в текстовом редакторе. На продакшене возврат к предыдущей версии таит несколько неочевидных ловушек, которые способны превратить исправление одной проблемы в каскад новых. Разбор того, что стоит проверить до выполнения rollback, поможет избежать типовых ошибок.

Наличие точки возврата

Первый вопрос — существует ли вообще стабильная версия, к которой планируется вернуться. Звучит тривиально, но на практике встречаются ситуации, когда:

• Предыдущий релиз содержал известные баги, которые терпели из-за нехватки времени
• Миграции базы данных за несколько релизов накопили зависимость от новой структуры
• Конфигурация окружения менялась параллельно с кодом, и старый артефакт с ней несовместим

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

Состояние базы данных

Самый опасный участок при откате — схема и содержимое БД. Здесь возможны три сценария, каждый из которых требует отдельной проверки.

Обратимые миграции

Если в рамках релиза выполнялись ALTER TABLE, DROP COLUMN или переименования, у каждой миграции должен быть down-скрипт. Перед откатом стоит убедиться, что эти скрипты тестировались — на копии продакшена, а не на пустой локальной базе. Частая ошибка: down-миграция написана формально, «для галочки», и на реальных данных падает из-за ограничений целостности.

Новые таблицы и данные

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

Изменения форматов данных

Если новый код записывал в существующие поля данные в новом формате (например, JSON вместо строки, другой разделитель в CSV-колонке), откат вернёт код, который этот формат не понимает. Старая версия может упасть при попытке прочитать «неправильные» записи. Проверка: запросить выборку изменённых записей и прогнать через логику старой версии хотя бы на тестовой среде.

Откат базы данных — это не откат кода. Эти две операции нужно рассматривать отдельно и координировать между собой.

Кэш и состояние сессий

После отката кода в памяти серверов и внешних хранилищ кэша останутся данные, сформированные новой версией. Сериализованные объекты в сессиях пользователей — классический пример. Старый код при десериализации получит неизвестные поля и выбросит исключение. Отдельный срез для темы «что проверить перед откатом изменений»: rankproof.icu/ru/.

Проверка перед откатом:

• Изменилась ли структура сессий или объектов в кэше
• Можно ли сбросить сессии без критического воздействия на пользователей (принудительный разлогин — болезненная, но часто меньшая из бед)
• Есть ли зависимые сервисы, которые кэшируют ответы от откатываемого

Если кэш распределённый (Redis, Memcached), его очистка может занять время и создать всплеск нагрузки на БД — об этом тоже стоит подумать заранее.

Фоновые задачи и очереди

Сообщение, уже стоящее в очереди (RabbitMQ, Kafka, Celery), содержит payload, ожидаемый новой версией обработчика. После отката консьюмер начнёт получать сообщения в незнакомом формате. Возможные последствия: падение обработчика, бесконечный retry-цикл, попадание сообщений в dead letter queue.

Что проверить:

1. Есть ли в очереди задачи, поставленные новым кодом
2. Может ли старый обработчик корректно их проигнорировать или нужно вручную очистить очередь
3. Не сломается ли порядок обработки, если часть задач уйдёт в DLQ

Зависимые сервисы и API-контракты

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

Практический подход: просмотреть логи запросов за время работы новой версии и выявить необычные паттерны — вызовы новых эндпоинтов, использование новых query-параметров. Если такие вызовы есть, откат требует либо согласования с потребителями, либо оставления новых эндпоинтов в виде заглушек.

Мониторинг и алерты

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

Коммуникация

Откат — это инцидент, и он требует координации не меньше, чем сам деплой. Перед выполнением стоит убедиться, что:

• Заинтересованные команды предупреждены — особенно если откат затрагивает общие компоненты
• Служба поддержки знает о временном отсутствии функциональности (если откат убирает фичу)
• Зафиксировано время начала отката для последующего разбора

Краткая сводка

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