Rollback (откат)

Rollback (откат) — процедура возврата к предыдущему состоянию системы после проблемного обновления. В DevOps-контексте — деплой предыдущей версии приложения. В контексте баз данных — атомарная отмена всех изменений незафиксированной транзакции. В обоих случаях цель — восстановить работоспособность в минимальное время (MTTR, Mean Time To Recovery).

Стратегии отката приложений

Предыдущий Docker-образ — при хранении версионированных тегов в Container Registry откат — деплой образа с предыдущим тегом: docker pull registry/app:v1.23 && docker-compose up -d
Blue-Green Deployment — два идентичных окружения (blue и green), трафик переключается между ними. Откат — переключить балансировщик обратно за секунды
Canary Release — постепенное направление трафика на новую версию (5% → 20% → 100%). При проблемах откат к 0% новой версии без простоя
Git revert — создание коммита, отменяющего изменения, с повторным прогоном CI/CD

Откат базы данных

Откат в базе данных — двойное понятие:

Транзакционный rollback — ROLLBACK в SQL отменяет все изменения текущей транзакции. Гарантируется ACID-свойствами БД. Автоматически происходит при обрыве соединения.
Откат миграции — инструменты миграций (Flyway, Liquibase, Django, Laravel) поддерживают down-миграции, отменяющие изменения схемы. Сложнее отката кода — требует планирования обратной совместимости.

История термина

Термин «rollback» в базах данных появился с внедрением транзакционных СУБД в 1970-х годах (System R от IBM, 1974). В контексте деплоя приложений термин закрепился в 2000-х с распространением Agile и continuous deployment. Blue-Green Deployment описал Мартин Фаулер (Martin Fowler) в 2010 году как паттерн для нулевого downtime при деплое.

Откат и хостинг

На VPS-серверах для возможности быстрого отката рекомендуется:

Создавать снапшот или бэкап базы данных перед каждым деплоем
Хранить минимум 3 последних Docker-образа в registry с тегами по версиям
Настроить команду rollback в CI/CD-пайплайне как отдельный job с ручным триггером
Версионировать конфигурационные файлы в Git

В GitLab CI откат доступен через UI Environments: каждый деплой фиксируется в истории, кнопка «Rollback» запускает повторный деплой предыдущего артефакта. Без этой возможности при критическом инциденте время восстановления (RTO) увеличивается с минут до часов. Для баз данных: бэкап перед деплоем (pg_dump или rsnapshot) — страховочная сетка при неудачной миграции.

Тестирование процедуры отката

Процедура отката должна быть протестирована до того, как она понадобится в production в 2 часа ночи. Рекомендуется проводить «учебные откаты» в нерабочее время: задеплоить специально собранный тестовый релиз и откатить его, зафиксировав время. Команды, никогда не тестирующие откат, обнаруживают проблемы процедуры только в момент реального инцидента. Runbook (документ с пошаговыми инструкциями) для отката должен быть доступен любому инженеру дежурной смены.

Rollback vs Hotfix

Два подхода к реакции на инцидент после деплоя:

Rollback: Возврат к предыдущей рабочей версии. Быстрее (минуты), не требует написания нового кода. Предпочтителен при критических ошибках, затрагивающих всех пользователей.
Hotfix: Оперативное исправление бага в текущей версии с повторным деплоем. Дольше (30+ минут), но позволяет сохранить новые возможности релиза. Предпочтителен при локализованных ошибках, не затрагивающих критический функционал.

Решение принимается на основе масштаба проблемы: если упал checkout-процесс интернет-магазина — немедленный rollback. Если баг в редко используемой функции отчётов — hotfix. Наличие автоматического CI/CD-пайплайна делает оба варианта быстрее: rollback — кнопка в GitLab Environments, hotfix — обычный коммит через пайплайн.