Откат (Rollback)

Откат (rollback) — это действие по возврату работающей системы к предыдущей, заведомо исправной версии — чаще всего используется для быстрой отмены развёртывания, которое, как выяснилось, вызвало ошибки, проблемы производительности или неверное поведение в production. Откаты — ключевая часть реагирования на инциденты: когда вскоре после деплоя что-то заметно идёт не так, самым быстрым и безопасным исправлением очень часто оказывается «отменить изменение, которое только что вышло», а не пытаться исправлять код на лету под давлением, пока инцидент активно продолжается. Почему это важно для разработчиков AI/SaaS: способность быстро и уверенно откатываться — это то, что делает частые развёртывания безопасными: команды, деплоящие несколько раз в день, полагаются на быстрый путь отката как на свою страховочную сеть, поскольку даже хорошо протестированное изменение может повести себя неожиданно под реальным production-трафиком и данными способами, которые staging никогда не выявляет. Медленный или рискованный процесс отката (который сам может дать сбой или занять 30 минут) подрывает всю предпосылку быстрого выпуска изменений, поскольку каждый деплой фактически становится более рискованным. Как это работает: конкретная механика зависит от стратегии развёртывания. При неизменяемых контейнерных развёртываниях откат часто так же прост, как перенаправление балансировщика нагрузки или оркестратора (Kubernetes, ECS) на предыдущий тег образа контейнера, который уже собран и протестирован — новая сборка не требуется, просто переключение трафика, часто завершающееся за секунды-пару минут. При наличии миграций базы данных откаты сложнее, поскольку откат кода приложения при оставлении изменения схемы на месте (или наоборот) сам по себе может вызвать ошибки — хорошо спроектированные миграции пишутся так, чтобы быть обратно совместимыми как минимум в течение одного релиза, специально для того, чтобы откат кода не требовал немедленного, рискованного отката базы данных тоже. Практический пример: команда разворачивает новую версию своего API в 14:00. К 14:15 их дашборд наблюдаемости показывает, что частота ошибок на эндпоинте `/api/checkout` подскочила с базового уровня 0,1% до 8%. Вместо того чтобы пытаться диагностировать и исправить первопричину на лету под давлением, пока реальные клиенты активно не могут оформить заказ, дежурный инженер запускает команду отката, которая перенаправляет production-балансировщик нагрузки на предыдущий, заведомо исправный образ контейнера (который всё ещё работал в кластере, просто не получая трафика). В течение 90 секунд частота ошибок падает обратно до базового уровня; затем команда спокойно расследует первопричину офлайн, без продолжающегося влияния на клиентов, прежде чем позже попытаться исправить и провести новое развёртывание.