Учебный rollback сайта: как проверить восстановление до аварии

План отката часто выглядит убедительно, пока его не приходится выполнять. Во время настоящего сбоя обнаруживается, что предыдущий каталог удалён, старый образ недоступен, команда требует неизвестного пароля или база уже несовместима. Учебный rollback проверяет эту цепочку заранее на контролируемом релизе и превращает предположения в измеренный порядок действий.

Выберите ограниченный сценарий тренировки

Начните со статического сайта без изменения данных. Подготовьте два исправных релиза: текущий и предыдущий. В новом добавьте безвредный и легко проверяемый маркер версии. Тренировка должна проходить в согласованное окно и не включать удаление файлов, изменение DNS или восстановление рабочей базы.

Когда возврат каталога отработан, отдельно тренируйте:

• неуспешный healthcheck приложения;
• ошибку конфигурации Nginx, обнаруженную до reload;
• недоступный новый контейнерный образ;
• восстановление копии в отдельную базу;
• потерю всего VPS в тестовой среде.

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

Определите успешный результат и время

До начала запишите:

• какой URL и маркер подтверждают активный релиз;
• кто принимает решение об откате;
• какая команда разрешена;
• сколько времени допустим сайт с ошибкой;
• какие данные не должны измениться;
• где находятся журнал и предыдущая версия.

Измеряйте не только длительность скрипта. Отдельно отметьте время появления сигнала, понимания причины, принятия решения, переключения и окончательной проверки. Сумма показывает реальный простой для посетителя.

Зафиксируйте состояние перед тренировкой

На сервере выполните команды только для чтения. Подставьте фактические пути проекта и публичный адрес:

date -u
readlink -f /var/www/example/current
git -C /home/deploy/site rev-parse HEAD
curl --fail --silent --show-error https://example.com/version.txt

Сохраните вывод в журнал тренировки. readlink показывает каталог, на который указывает current, Git — ожидаемый коммит исходников, а публичный запрос подтверждает версию через тот же путь, которым пользуется посетитель.

Если любое значение уже не соответствует журналу последнего релиза, остановите тренировку и сначала разберите расхождение. Нельзя измерять rollback из неизвестного исходного состояния.

Создайте контролируемый повод для возврата

Не ломайте Nginx и не удаляйте файл. Опубликуйте исправный тестовый релиз с маркером, который сценарий smoke намеренно считает неподходящим. Например, проверка может ожидать предыдущий учебный идентификатор. Это позволяет пройти ветку отказа без настоящей поломки сайта.

Убедитесь, что автоматизация остановилась или пометила релиз неуспешным именно по ожидаемой проверке. В журнале должно быть видно имя теста, URL, ожидаемое и полученное значение.

Запустите только штатный rollback

Используйте предусмотренную проектом команду, например ./scripts/rollback.sh. Не переключайте current вручную, если обычный процесс должен выполнять проверки владельца, допустимого каталога и предыдущей версии. Команда обязана отказаться от работы, если предшествующий релиз не найден или путь выходит за каталог releases.

Во время выполнения фиксируйте время и вывод. Скрипт не должен удалять неудачную версию до разбора и не должен затрагивать пользовательские данные.

Проверьте сайт снаружи

После переключения выполните небольшой публичный набор. Следующие команды проверяют HTTPS, маркер версии и код 404; подставьте реальный домен и ожидаемый идентификатор:

curl --fail --silent --show-error --head https://example.com/
curl --fail --silent --show-error https://example.com/version.txt
curl --silent --show-error --output /dev/null \
  --write-out '%{http_code}\n' \
  https://example.com/rollback-test-missing/

Главная должна вернуть успешный ответ, version.txt — предыдущий идентификатор, а последний запрос — 404. Затем откройте вложенную страницу, CSS или JavaScript и одну картинку: возврат одного index.html не доказывает целостность релиза.

На сервере проверьте журнал Nginx или приложения за время тренировки. Новый поток 404/500, ошибки прав и повторные перезапуски означают, что rollback нельзя считать завершённым, даже если главная открылась.

Для приложения проверьте совместимость данных

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

Состояние очередей, фоновых задач и кеша тоже может зависеть от версии. Остановка веб-контейнера не отменяет работу старого worker, поэтому список процессов после rollback должен соответствовать одной согласованной версии.

Отдельно проверьте восстановление копии

Rollback кода не доказывает пригодность backup. В другой тренировке разверните пустую тестовую базу или volume, восстановите туда копию и подключите отдельный экземпляр приложения. Проверьте ключевые записи и зафиксируйте продолжительность.

Не восстанавливайте копию поверх production только ради проверки. Такая операция сама создаёт аварию и может стереть новые данные.

Разберите тренировку по фактам

После завершения ответьте:

1. Сколько заняли обнаружение, решение, переключение и проверка?
2. Все ли команды были в актуальной инструкции?
3. Понадобилось ли право, которого не было у ответственного пользователя?
4. Сохранились ли предыдущий релиз, образ и ключи доступа?
5. Было ли понятно, совместима ли база?
6. Получил ли пользователь правильную версию по публичному адресу?
7. Осталась ли диагностика неудачного релиза?

Исправьте инструкцию и автоматические проверки сразу после тренировки. Запишите дату следующего упражнения после существенного изменения deploy, хостинга, базы или состава команды.

Верните систему в обычное состояние

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

Штатная схема переключения описана в руководстве по атомарному deploy, HTTP-проверки — в статье о smoke-тестах, а ограничения возврата после изменения базы — в материале о миграциях.

Источники

• NIST contingency planning guide
• Nginx: controlling Nginx
• PostgreSQL backup and restore