Переключение сайта на новую версию редко ломается из-за кода. Чаще сбой происходит там, где никто не назначил, кто принимает решение, и в какой момент команда останавливает выпуск.
В нашей практике почти каждый проблемный релиз объясняется одним из трёх: не было владельца решения, бэкап не проверяли на восстановление, или откат обсуждали в момент сбоя, а не заранее. Ниже — как мы строим план переключения, и почему «окно релиза» — это не время суток, а набор ролей и критериев.
Роли до окна релиза
До того как назначить дату, руководитель определяет три роли:
- Владелец решения — единственный, кто может сказать «продолжаем» или «откатываем». Он доступен в окне релиза, его заместитель указан в плане.
- Технический дежурный — следит за метриками и журналами в первые часы после переключения.
- Проверяющий бизнес-сценарии — подтверждает отправку заявки, оформление заказа, вход в кабинет: то, что приносит деньги.
Если право на откат не определено заранее, в момент сбоя команда теряет время на согласование — а время в окне релиза и есть деньги.
Состав релиза и резервная точка
В список входят версия кода, изменения контента, миграции базы, настройки веб-сервера, DNS и интеграции. Для каждого пункта фиксируют, где лежит исходное состояние и как его вернуть.
Отдельно подчеркну: резервная копия полезна только после проверки восстановления в отдельном контуре. Строка «бэкап сделан» не подтверждает, что из него получится поднять сайт. Однажды мы потратили несколько часов на восстановление из «рабочего» архива, в котором не хватало таблиц — с тех пор проверка восстановления обязательна в каждом плане.
Критерии отката
Откат привязывают к событиям, а не к раздражению:
- ключевой сценарий недоступен;
- данные перестали записываться;
- ошибки затрагивают заметную долю посетителей;
- есть риск некорректной обработки обращений.
Один косметический дефект — не повод для отката, если его можно безопасно исправить в следующем выпуске. Решение принимает названная роль по согласованным признакам, а не голосованием в чате.
Карта переключения шире технической команды
В план включают не только разработчиков. Владелец контента подтверждает заморозку публикаций, маркетолог проверяет рекламные ссылки и цели, продажи принимают маршрут тестовой заявки, администратор отвечает за DNS, сертификат, резервную копию и журналы.
Если один человек держит все решения в голове, при инциденте команда тратит время на поиск полномочий, а не на причину сбоя.
Окно релиза
Окно выбирают не по привычному вечеру пятницы, а по рискам. В него закладывают время на резервную копию и проверку восстановления, само переключение, smoke-тест, наблюдение и возможный возврат. Для каждого шага — исполнитель, резервный исполнитель, ожидаемый сигнал и критерий остановки.
Например, переключение не продолжают, если новая форма не создаёт тестовую запись или критическая страница отдаёт ошибку.
Runbook
Runbook хранит последовательность действий, команды и доступы. Пароли в него не пишут — вместо них ссылки на утверждённое хранилище и владелец доступа. Отдельно фиксируют, что запрещено во время окна: публикация новостей, правка каталога, перенос DNS-зоны, обновление модулей. Чем меньше переменных в окне релиза, тем быстрее диагностика.
Откат должен быть технически возможен
Фраза «при необходимости откатимся» ничего не значит без точки возврата. До релиза проверяют, что старая версия доступна, схема базы совместима либо для неё предусмотрен отдельный сценарий, а DNS и кэш не удержат пользователей на смешанной версии. Для интеграций фиксируют, какие заявки могут попасть в обе системы и как их сверять после возврата — иначе часть обращений потеряется между CRM и почтой.
Нужна ли заморозка контента
Да, если публикация или изменение каталога может разойтись между старой и новой версиями. В плане указывают время начала заморозки и порядок переноса изменений, которые появились после неё.
Контроль после переключения
В первые часы после релиза проверяют доступность главной и целевых страниц, отправку форм, уведомления, выдачу сертификата, редиректы и ключевые интеграции. Проверка идёт по списку, а не по сообщениям в общем чате. При CDN, кэше или нескольких DNS-провайдерах наблюдение продолжают, пока новая версия не станет доступна в согласованных регионах и на типовых устройствах.
Отдельный исполнитель сверяет обращения, поступившие в окно переключения. Его задача — найти заявки, которые могли попасть в старый маршрут, повториться или не дойти до CRM. Итог релиза содержит фактическое время переключения, результаты smoke-теста, обнаруженные отклонения и решение об их устранении.
После окна релиза дежурный получает список наблюдаемых метрик, контакты владельцев интеграций и срок усиленного контроля. Когда период наблюдения завершён, релиз закрывают отдельным решением — а не просто перестают обсуждать его в чате.
Итог
Переключение считают завершённым после smoke-теста, проверки заявок и записи фактических результатов в журнал релиза. План с ролями, резервной точкой и условиями отката нужен до выбора времени публикации — не после.
Top comments (0)