Сначала определите, что считается неудачным релизом
Публикация завершилась без ошибки, но важная функция может перестать работать: форма не отправляется, оплата не проходит, фоновая задача застряла, а страницы отдаются с ошибками только под реальной нагрузкой. Поэтому критерии остановки должны описывать пользовательские сценарии и сигналы системы, а не только результат команды деплоя.
Выберите короткий список проверок сразу после релиза: доступность ключевых страниц, вход, отправка тестовой формы, чтение и запись данных, журнал ошибок и состояние очередей. Наблюдайте за ними в течение согласованного периода. Для критичных изменений отдельно определите, кто принимает решение об откате.
Не всякое ухудшение требует полного возврата. Иногда достаточно выключить флаг функции или отменить конфигурационное изменение. Но решение должно учитывать масштаб проблемы и безопасность данных, а не стремление как можно быстрее убрать видимую ошибку.
Разделите код, настройки и данные
Код часто можно переключить на предыдущую версию, если релизы хранятся отдельно и схема публикации поддерживает быстрый возврат. С конфигурацией нужен свой журнал изменений и исходное значение. Секреты и ключи не следует копировать в публичный архив или включать в общий пакет отката.
Изменения базы данных требуют особого внимания. Добавление необязательного поля обычно обратимо проще, чем удаление или преобразование данных. Если новая версия уже записала информацию в новом формате, старый код может её не понимать. В таком случае безопаснее сначала выпустить совместимый переходный релиз, а удаление старой структуры выполнить позже.
Для файлов пользователей, очередей и внешних интеграций укажите отдельный план. Переключение кода не отменит уже отправленные письма, списанные платежи или сообщения партнёру. Не запускайте автоматический повтор таких операций без проверки состояния.
Подготовьте предыдущую версию и способ переключения
Храните предыдущий проверенный артефакт релиза и точно знайте, где он находится. Зафиксируйте версию приложения, миграций, конфигурации и зависимостей. Если возврат требует вручную искать файлы или восстанавливать их из случайной копии, план ещё не готов.
Опишите порядок переключения: кто выполняет действие, какими правами, как проверяет завершение и как отменить сам откат, если он не помог. Для нескольких серверов укажите последовательность и поведение балансировщика. Для одного сервера оцените, будет ли короткий перерыв при замене файлов.
Перед публикацией проверьте процедуру на тестовой среде или при безопасном изменении. Это выявляет недостающие доступы, несовпадающие версии и команды, которые не работают в текущем окружении. План должен быть доступен дежурному, а не только автору релиза.
Откатывайте с сохранением данных для диагностики
При подтверждённом критичном сбое сначала сохраните время события, идентификатор релиза, ключевые сообщения журналов и текущий статус данных. Не задерживайте восстановление ради полного расследования, но оставьте достаточно сведений, чтобы не потерять причину проблемы.
Выполняйте откат по подготовленным шагам и проверяйте состояние после каждого важного действия. Убедитесь, что приложение запущено, база доступна, фоновые процессы не повторяют опасную операцию и пользователи могут выполнить основные сценарии. Одна успешная главная страница не подтверждает работоспособность всей системы.
Если старую версию нельзя безопасно вернуть из-за уже изменённых данных, выберите совместимое исправление или выключите проблемную функцию. Оцените последствия для пользователей и сообщите о временных ограничениях. Непроверенное восстановление из дампа может вернуть потерянные заказы и заявки.
После восстановления устраните причину
Зафиксируйте, когда начался сбой, какие проверки его обнаружили, сколько заняло решение и какие действия сработали. Отделяйте подтверждённые факты от предположений. Цель разбора — найти слабое место процесса или системы, а не назначить виноватого.
Добавьте недостающую проверку, уточните порядок миграции, улучшите совместимость версий или автоматизируйте безопасное переключение. Затем проверьте изменение на тестовой среде. Повторный релиз без устранения причины может воспроизвести тот же отказ.
Хороший план отката короток, доступен и проверен. Он не отменяет резервное копирование и не гарантирует отсутствие простоя, но помогает вернуть совместимое состояние, сохранить данные и быстрее перейти от аварии к управляемому исправлению.