[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2gh9mhbz3unu9":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":7,"section":8,"preview":9,"heroImage":8,"previewImage":10,"headMarkup":11,"lifecycleId":34,"bodyMd":35,"bodyHtml":36},"plan-pereklyucheniya-starogo-sayta-na-novyy-roli-okno-reliza-i-otkat","План переключения старого сайта на новый: роли, окно релиза и откат",true,"2026-08-30T09:00:00+03:00",null,"План переключения старого сайта на новый: роли, окно релиза и откат. Практический порядок проверки, роли и границы ответственности.","\u002Fcontent-media\u002Farticles\u002Fplan-pereklyucheniya-starogo-sayta-na-novyy-roli-okno-reliza-i-otkat\u002Fassets\u002F35a019c32059.webp",[12],{"tag":13,"type":14,"key":15,"json":16},"script","application\u002Fld+json","plan-pereklyucheniya-starogo-sayta-na-novyy-roli-okno-reliza-i-otkat-faq",{"@context":17,"@type":18,"mainEntity":19},"https:\u002F\u002Fschema.org","FAQPage",[20,26,30],{"@type":21,"name":22,"acceptedAnswer":23},"Question","Кто принимает решение о начале релиза?",{"@type":24,"text":25},"Answer","Руководитель релиза подтверждает готовность после чек-листа владельцев сайта, инфраструктуры, контента и связанных систем. Полномочия и заместитель должны быть указаны в плане заранее.",{"@type":21,"name":27,"acceptedAnswer":28},"Нужна ли заморозка контента?",{"@type":24,"text":29},"Да, если публикация или изменение каталога может разойтись между старой и новой версиями. В плане указывают время начала заморозки и порядок переноса изменений, которые появились после неё.",{"@type":21,"name":31,"acceptedAnswer":32},"Когда требуется откат?",{"@type":24,"text":33},"Откат запускают по заранее определённым критериям: потере ключевого сценария, риску потери данных или массовой технической ошибке. Решение не принимают по впечатлению от отдельных визуальных замечаний.","lc_26aeb69fb0a0457467de082fe9c31b31","# План переключения старого сайта на новый: роли, окно релиза и откат\n\n## До окна релиза\n\nПереключение нельзя начинать с команды «выкатываем». До окна релиза руководитель назначает владельца решения, технического дежурного и человека, который подтверждает бизнес-сценарии: отправку заявки, оформление заказа, вход в кабинет или другой критичный маршрут. В плане фиксируют точное время, каналы связи и правило, по которому команда прекращает выпуск.\n\n## Состав релиза и резервная точка\n\nВ список релиза входят версия кода, изменения контента, миграции, настройки веб-сервера, DNS и интеграции. Для каждого пункта отмечают, где лежит исходное состояние и как его вернуть. Резервная копия полезна только после проверки восстановления в отдельном контуре; запись «бэкап сделан» не подтверждает, что из него получится вернуть сайт.\n\n## Решение об откате\n\nОткат связывают не с раздражением от отдельного дефекта, а с заранее оговорёнными событиями: ключевой сценарий недоступен, данные перестали записываться, ошибки затрагивают заметную долю посетителей или возник риск некорректной обработки обращений. Владелец решения должен быть доступен в окне релиза. Если право на откат не определено, команда теряет время на согласование в момент сбоя.\n\n## Карта переключения начинается с ограничений\n\nВ план релиза включают не только техническую команду. Владелец контента подтверждает момент заморозки публикаций, маркетолог проверяет рекламные ссылки и цели, продажа принимает маршрут тестовой заявки, а администратор отвечает за DNS, сертификат, резервную копию и журналы. Если один человек держит все решения в голове, при инциденте команда тратит время на поиск полномочий.\n\nОкно релиза выбирают не по привычному вечеру пятницы, а по рискам. В него закладывают время на резервную копию и проверку восстановления, переключение, smoke-тест, наблюдение и возможный возврат. Для каждого шага нужен исполнитель, резервный исполнитель, ожидаемый сигнал и критерий остановки. Например, переключение не продолжают, если новая форма не создаёт тестовую запись или критическая страница отдаёт ошибку.\n\n### Что записать в runbook\n\nRunbook хранит последовательность действий, команды и доступы не в виде паролей, а как ссылки на утверждённое хранилище и владельца доступа. В нём отдельно указывают, какие изменения запрещены во время окна: публикация новостей, правка каталога, перенос DNS-зоны, обновление модулей. Это снижает число переменных, когда нужно понять причину сбоя.\n\n## Откат должен быть технически возможен\n\nФраза «при необходимости откатимся» ничего не означает без точки возврата. До релиза проверяют, что старая версия доступна, схема базы данных совместима либо для неё предусмотрен отдельный сценарий, а DNS и кэш не удержат пользователей на смешанной версии. Для интеграций фиксируют, какие заявки могут попасть в обе системы и как их сверять после возврата.\n\nРешение об откате принимает названная роль по заранее согласованным признакам: недоступность ключевого сценария, потеря данных, ошибка оплаты или массовая ошибка авторизации. Не стоит откатывать сайт из-за одного косметического дефекта, если его можно безопасно исправить в следующем выпуске. После релиза команда сохраняет фактическое время шагов и отклонения от плана: это материал для следующего окна, а не поиск виноватого.\n\n## Частые вопросы\n\n### Кто принимает решение о начале релиза?\n\nРуководитель релиза подтверждает готовность после чек-листа владельцев сайта, инфраструктуры, контента и связанных систем. Полномочия и заместитель должны быть указаны в плане заранее.\n\n### Нужна ли заморозка контента?\n\nДа, если публикация или изменение каталога может разойтись между старой и новой версиями. В плане указывают время начала заморозки и порядок переноса изменений, которые появились после неё.\n\n### Когда требуется откат?\n\nОткат запускают по заранее определённым критериям: потере ключевого сценария, риску потери данных или массовой технической ошибке. Решение не принимают по впечатлению от отдельных визуальных замечаний.\n\n\n## Итог\n\nПереключение считают завершенным после smoke-теста, проверки заявок и записи фактических результатов в журнал релиза. План с ролями, резервной точкой и условиями отката нужен до выбора времени публикации.\n\n## Контроль после переключения\n\nВ первые часы после релиза проверяют доступность главной и целевых страниц, отправку форм, уведомления, выдачу сертификата, редиректы и ключевые интеграции. Проверка идёт по списку, а не по сообщениям в общем чате. Если используется CDN, кэш или несколько DNS-провайдеров, наблюдение продолжают до момента, когда новая версия доступна в согласованных регионах и на типовых устройствах.\n\nОтдельный исполнитель сверяет обращения, поступившие в окно переключения. Его задача — найти заявки, которые могли попасть в старый маршрут, повториться или не дойти до CRM. Итог релиза содержит время фактического переключения, результаты smoke-теста, обнаруженные отклонения и решение об их устранении.\n\n### Передача дежурства\n\nПосле окна релиза назначенный дежурный получает список наблюдаемых метрик, контакты владельцев интеграций и срок усиленного контроля. В его журнал попадают не только ошибки, но и подтверждения штатной работы. Когда период наблюдения завершён, команда закрывает релиз отдельным решением, а не просто перестаёт обсуждать его в чате.\n\n![Схема процесса](\u002Fcontent-media\u002Farticles\u002Fplan-pereklyucheniya-starogo-sayta-na-novyy-roli-okno-reliza-i-otkat\u002Fassets\u002Ffcc733f1e946.webp)\n","\u003Ch1>План переключения старого сайта на новый: роли, окно релиза и откат\u003C\u002Fh1>\n\u003Ch2>До окна релиза\u003C\u002Fh2>\n\u003Cp>Переключение нельзя начинать с команды «выкатываем». До окна релиза руководитель назначает владельца решения, технического дежурного и человека, который подтверждает бизнес-сценарии: отправку заявки, оформление заказа, вход в кабинет или другой критичный маршрут. В плане фиксируют точное время, каналы связи и правило, по которому команда прекращает выпуск.\u003C\u002Fp>\n\u003Ch2>Состав релиза и резервная точка\u003C\u002Fh2>\n\u003Cp>В список релиза входят версия кода, изменения контента, миграции, настройки веб-сервера, DNS и интеграции. Для каждого пункта отмечают, где лежит исходное состояние и как его вернуть. Резервная копия полезна только после проверки восстановления в отдельном контуре; запись «бэкап сделан» не подтверждает, что из него получится вернуть сайт.\u003C\u002Fp>\n\u003Ch2>Решение об откате\u003C\u002Fh2>\n\u003Cp>Откат связывают не с раздражением от отдельного дефекта, а с заранее оговорёнными событиями: ключевой сценарий недоступен, данные перестали записываться, ошибки затрагивают заметную долю посетителей или возник риск некорректной обработки обращений. Владелец решения должен быть доступен в окне релиза. Если право на откат не определено, команда теряет время на согласование в момент сбоя.\u003C\u002Fp>\n\u003Ch2>Карта переключения начинается с ограничений\u003C\u002Fh2>\n\u003Cp>В план релиза включают не только техническую команду. Владелец контента подтверждает момент заморозки публикаций, маркетолог проверяет рекламные ссылки и цели, продажа принимает маршрут тестовой заявки, а администратор отвечает за DNS, сертификат, резервную копию и журналы. Если один человек держит все решения в голове, при инциденте команда тратит время на поиск полномочий.\u003C\u002Fp>\n\u003Cp>Окно релиза выбирают не по привычному вечеру пятницы, а по рискам. В него закладывают время на резервную копию и проверку восстановления, переключение, smoke-тест, наблюдение и возможный возврат. Для каждого шага нужен исполнитель, резервный исполнитель, ожидаемый сигнал и критерий остановки. Например, переключение не продолжают, если новая форма не создаёт тестовую запись или критическая страница отдаёт ошибку.\u003C\u002Fp>\n\u003Ch3>Что записать в runbook\u003C\u002Fh3>\n\u003Cp>Runbook хранит последовательность действий, команды и доступы не в виде паролей, а как ссылки на утверждённое хранилище и владельца доступа. В нём отдельно указывают, какие изменения запрещены во время окна: публикация новостей, правка каталога, перенос DNS-зоны, обновление модулей. Это снижает число переменных, когда нужно понять причину сбоя.\u003C\u002Fp>\n\u003Ch2>Откат должен быть технически возможен\u003C\u002Fh2>\n\u003Cp>Фраза «при необходимости откатимся» ничего не означает без точки возврата. До релиза проверяют, что старая версия доступна, схема базы данных совместима либо для неё предусмотрен отдельный сценарий, а DNS и кэш не удержат пользователей на смешанной версии. Для интеграций фиксируют, какие заявки могут попасть в обе системы и как их сверять после возврата.\u003C\u002Fp>\n\u003Cp>Решение об откате принимает названная роль по заранее согласованным признакам: недоступность ключевого сценария, потеря данных, ошибка оплаты или массовая ошибка авторизации. Не стоит откатывать сайт из-за одного косметического дефекта, если его можно безопасно исправить в следующем выпуске. После релиза команда сохраняет фактическое время шагов и отклонения от плана: это материал для следующего окна, а не поиск виноватого.\u003C\u002Fp>\n\u003Ch2>Частые вопросы\u003C\u002Fh2>\n\u003Ch3>Кто принимает решение о начале релиза?\u003C\u002Fh3>\n\u003Cp>Руководитель релиза подтверждает готовность после чек-листа владельцев сайта, инфраструктуры, контента и связанных систем. Полномочия и заместитель должны быть указаны в плане заранее.\u003C\u002Fp>\n\u003Ch3>Нужна ли заморозка контента?\u003C\u002Fh3>\n\u003Cp>Да, если публикация или изменение каталога может разойтись между старой и новой версиями. В плане указывают время начала заморозки и порядок переноса изменений, которые появились после неё.\u003C\u002Fp>\n\u003Ch3>Когда требуется откат?\u003C\u002Fh3>\n\u003Cp>Откат запускают по заранее определённым критериям: потере ключевого сценария, риску потери данных или массовой технической ошибке. Решение не принимают по впечатлению от отдельных визуальных замечаний.\u003C\u002Fp>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>Переключение считают завершенным после smoke-теста, проверки заявок и записи фактических результатов в журнал релиза. План с ролями, резервной точкой и условиями отката нужен до выбора времени публикации.\u003C\u002Fp>\n\u003Ch2>Контроль после переключения\u003C\u002Fh2>\n\u003Cp>В первые часы после релиза проверяют доступность главной и целевых страниц, отправку форм, уведомления, выдачу сертификата, редиректы и ключевые интеграции. Проверка идёт по списку, а не по сообщениям в общем чате. Если используется CDN, кэш или несколько DNS-провайдеров, наблюдение продолжают до момента, когда новая версия доступна в согласованных регионах и на типовых устройствах.\u003C\u002Fp>\n\u003Cp>Отдельный исполнитель сверяет обращения, поступившие в окно переключения. Его задача — найти заявки, которые могли попасть в старый маршрут, повториться или не дойти до CRM. Итог релиза содержит время фактического переключения, результаты smoke-теста, обнаруженные отклонения и решение об их устранении.\u003C\u002Fp>\n\u003Ch3>Передача дежурства\u003C\u002Fh3>\n\u003Cp>После окна релиза назначенный дежурный получает список наблюдаемых метрик, контакты владельцев интеграций и срок усиленного контроля. В его журнал попадают не только ошибки, но и подтверждения штатной работы. Когда период наблюдения завершён, команда закрывает релиз отдельным решением, а не просто перестаёт обсуждать его в чате.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Farticles\u002Fplan-pereklyucheniya-starogo-sayta-na-novyy-roli-okno-reliza-i-otkat\u002Fassets\u002Ffcc733f1e946.webp\" alt=\"Схема процесса\">\u003C\u002Fp>\n"]