Подготовьте план запуска сайта и условия отката

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

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

Шаг 1. Опишите границы переключения

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

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

При изменении URL подготовьте карту переноса страниц. В инструкции Google для такого переезда выделены подготовка нового сайта, соответствия адресов, редиректы и наблюдение после переноса. Планируйте эти проверки явно; появление новой страницы в поиске не является мгновенным условием успешного переключения. Источник: Google Search Central.

Шаг 2. Заполните последовательность

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

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

Шаг 3. Продумайте новые данные

Выберите правило для изменений во время запуска. Будет ли редактор продолжать публикации? Где окажутся заявки, полученные между началом и окончанием работ? Кто сверит новые записи, если потребуется возврат?

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

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

Шаг 4. Запишите условия остановки и отката

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

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

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

Шаг 5. Разделите проверки и наблюдение

Сразу после переключения проверьте фактически открывающуюся версию, ключевые страницы, мобильный путь, разрешённую заявку и работу редактора в нужной роли. При переносе URL — также соответствия адресов, редиректы и настройки индексирования. Зафиксируйте, что проверено на рабочем адресе, а что только на тестовом.

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

Закрытие окна запуска и завершение поискового переезда — разные результаты. Не обещайте сохранение позиций только на основании успешной технической проверки.

Проверьте результат урока

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

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

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