Как спланировать переключение сайта и возврат при сбое

Определите границы переключения

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

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

Составьте пошаговый лист операции

Укажите ожидаемую длительность шагов по репетиции, а не произвольное обещание. Для зависимых действий отметьте входные условия. Не выполняйте финальный перенос, пока не подтверждена возможность прочитать копию и восстановить нужные компоненты. Инструкция должна быть пригодна другому компетентному участнику, а не только её автору.

Разделите цели восстановления

RTO описывает целевое время восстановления, RPO — допустимую потерю данных по времени. AWS рекомендует определять эти цели в соответствии с потребностями нагрузки. Они не становятся подтверждёнными возможностями только после записи в документ. Нужны доступные копии, понятный процесс и проверка фактического восстановления.

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

Сохраните данные после запуска

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

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

Проведите репетицию на копии

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

Включите в репетицию отказ одного шага. Например, миграция остановилась, а приложение ещё не переключено; либо код выпущен, но интеграция недоступна. Команда должна понимать, что уже изменилось и какие действия допустимы дальше. Паническое повторение всей инструкции с начала способно увеличить повреждение.

Учебный пример нового приёма заявок

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

Если совместимость не предусмотрена, план должен содержать безопасный способ сохранить и перенести эти обращения перед возвратом. Этот пример показывает, почему одной кнопки rollback недостаточно. Количество заявок условное и не является результатом проверки рабочего проекта.

Когда выпуск завершён

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

Пример возврата с сохранением новых обращений

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

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

Рекомендации AWS по восстановлению связывают RTO и RPO с последствиями для конкретной нагрузки и её зависимостей. Эти принципы не требуют выбирать AWS как хостинг и не назначают одинаковые значения всем сайтам. Длительность операции подтверждают репетицией; допустимую потерю данных согласуют отдельно.

В результате должна остаться запись о версии кода, состоянии данных, выполненных проверках и незакрытых действиях. Техническая приёмка SEO-изменений проверяет адреса и сигналы, но не заменяет сверку поступивших заявок. После возврата оценку результата ведут с учётом даты сбоя и повторного выпуска.

Как не потерять обращения при возврате на прежнюю версию

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

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