«Обновление в 3 часа ночи, сайт ляжет на 20 минут» — знакомая фраза, за которой прячется страх. Страх выкатывать изменения, потому что каждая выкатка — это риск уронить магазин и потерять заказы. В итоге обновления копятся, релизы становятся большими и ещё более рискованными, а команда откладывает их до последнего. Порочный круг, из которого выводит деплой без простоя.
В этой статье разберём две стратегии выкатки интернет-магазина без остановки: blue-green и canary. Как они устроены, чем отличаются, как решать вопрос миграций базы, прогрева кэша и отката, и что учесть именно на 1С-Битрикс с его BitrixVM, композитным сайтом и обновлениями ядра. Выстраивание процессов выкатки мы ведём в рамках аудита и оптимизации решений на 1С.
Коротко
- Простой при выкатке — это прямые потери заказов; деплой без простоя убирает страх и делает релизы частыми и мелкими.
- Blue-green держит две версии и переключает трафик мгновенно; canary выкатывает новую версию постепенно на долю пользователей.
- Ключевые условия — обратно совместимые миграции БД, общие файлы и сессии, прогрев кэша до переключения.
- Откат должен быть штатной операцией с заранее заданными порогами, а не аварийным решением на эмоциях.
Почему простой при выкатке дорого стоит
Для интернет-магазина недоступность — это не техническая неприятность, а прямые деньги. Каждая минута простоя в рабочие часы — потерянные заказы, брошенные корзины и подорванное доверие. В сезон или в пик рекламной кампании цена минуты простоя вырастает многократно.
Но есть и скрытая цена. Когда выкатка означает простой, команда боится релизов и откладывает их. Изменения копятся, релиз становится огромным, риск ошибки растёт — и один большой деплой роняет больше, чем десять мелких. Деплой без простоя разрывает этот круг: обновляться можно часто, мелко и в любое время, а значит, спокойнее и безопаснее.
Blue-green деплой: суть
Blue-green — стратегия с двумя одинаковыми окружениями. «Синее» — текущий боевой, на нём работают пользователи. «Зелёное» — копия, куда вы разворачиваете новую версию и спокойно её проверяете, пока трафик идёт на синее.
Когда зелёное готово и проверено, трафик переключается на него целиком и мгновенно. Синее остаётся нетронутым как «страховка». Если после переключения обнаружилась проблема, вы так же мгновенно возвращаете трафик на синее — откат занимает секунды. Это главная ценность подхода: и выкатка, и откат становятся быстрыми и предсказуемыми.
Canary деплой: суть
Canary (канареечный деплой) идёт осторожнее. Название — от шахтёрских канареек, которых брали в шахту как ранний сигнал опасности. Здесь роль «канарейки» играет небольшая доля пользователей: новую версию сначала показывают, скажем, 5% трафика.
Дальше вы следите за метриками этой доли: если всё хорошо, постепенно увеличиваете процент — 5%, 25%, 50%, 100%. Если метрики ухудшились, выкатку останавливают и откатывают, и проблему увидела лишь малая часть пользователей. Canary особенно ценен для рискованных изменений на большом трафике, где ошибку хочется поймать до того, как её ощутят все.
Blue-green против canary
Стратегии не конкурируют, а решают разные задачи. Выбор зависит от риска изменения, объёма трафика и сложности инфраструктуры.
| Критерий | Blue-green | Canary |
|---|---|---|
| Переключение | Всё сразу | Постепенно, по долям |
| Сложность | Проще | Сложнее (маршрутизация, метрики) |
| Обнаружение проблем | После полного переключения | На малой доле трафика |
| Скорость отката | Мгновенно на синее | Остановить рост доли |
| Когда выбирать | Обычные релизы | Рискованные изменения, большой трафик |
На практике многие начинают с blue-green как более простого, а canary добавляют для особо рискованных выкаток. Общий фундамент — процесс автоматической сборки и выкатки, о котором мы подробно пишем в статье про CI/CD и деплой на Битрикс.
Миграции базы данных без боли
Самое коварное в деплое без простоя — база данных. Она общая для обеих версий, поэтому старый и новый код должны уметь работать с одной схемой одновременно. Ломающее изменение схемы (удалили колонку, которую ещё использует старая версия) обрушит либо синее, либо откат.
Решение — обратно совместимые миграции в несколько шагов:
- Добавьте новое. Новые поля и таблицы создаются так, чтобы старый код продолжал работать.
- Выкатите версию. Новый код начинает использовать новые структуры, старые ещё на месте.
- Дайте отстояться. Убедитесь, что откат не нужен и старая версия больше не понадобится.
- Удалите старое. Отдельным поздним шагом убираете устаревшие поля и код.
Общие данные: файлы и сессии
Две версии магазина должны видеть одни и те же пользовательские данные, иначе клиент «потеряется» при переключении. Особое внимание — трём вещам:
- Загруженные файлы. Каталог upload (картинки товаров, документы) должен быть общим для окружений, а не копией.
- Сессии. Сессии и корзины хранят в общем хранилище, чтобы клиент не разлогинился при переключении.
- Кэш. Кэш у версий свой, но общие ключи и инвалидацию нужно продумать, чтобы не отдавать устаревшее.
- Очереди и агенты. Фоновые задачи не должны выполняться дважды на обеих версиях одновременно.
Прогрев кэша перед переключением
Свежеразвёрнутая версия приходит с пустым кэшем. Если переключить на неё весь трафик, первые запросы пойдут «вхолодную»: медленно, с тяжёлой нагрузкой на базу — магазин заметно затормозит именно в момент выкатки.
Переключение трафика
Технически переключение делается на уровне маршрутизации: балансировщик нагрузки или веб-сервер направляет запросы на нужное окружение. Для blue-green это смена «указателя» с синего на зелёное, для canary — распределение долей трафика между версиями.
Важна атомарность: переключение должно быть мгновенным и одномоментным, без состояния, когда часть запросов идёт на одну версию, часть — на другую (кроме намеренного canary). Здесь же настраивают обработку долгих запросов, чтобы уже начатые операции корректно завершились на своей версии.
Откат как штатная операция
Главная психологическая ценность этих стратегий — откат перестаёт быть аварией. При blue-green откат — это возврат трафика на нетронутое синее окружение, при canary — остановка роста канареечной доли. И то, и другое занимает секунды.
Чтобы откат был спокойным, пороги задают заранее: рост ошибок 5xx, падение конверсии или скорости, всплеск времени ответа. Как только метрики пробили порог — откат по регламенту, а не по эмоциям в момент паники. Так выкатка превращается из стрессового события в рутинную, обратимую операцию.
Особенности 1С-Битрикс и BitrixVM
На 1С-Битрикс общие принципы работают, но платформа добавляет нюансы. Инфраструктуру чаще строят на BitrixVM или похожем окружении, а переключение — на уровне nginx или балансировщика.
- Обновления ядра (update). Обновления через систему update меняют файлы ядра — их прогоняют на зелёном окружении и проверяют до переключения.
- Композитный сайт. Композитный кэш нужно прогреть на новой версии, иначе первые посетители получат «холодные» страницы.
- Управляемый кэш и агенты. Инвалидацию кэша и запуск агентов согласуют между версиями, чтобы не было двойной работы.
- Резервные копии. Перед выкаткой обязателен свежий бэкап — как последняя линия отката при проблемах с БД.
Устройство самого окружения и его роль в стабильности мы подробно разбираем в статье про хостинг и инфраструктуру BitrixVM. Отдельная тема — обмен с 1С и агенты: при выкатке важно, чтобы регулярные обмены и фоновые задачи не задваивались между версиями, и эту логику мы закрываем услугой автоматизации на 1С.
С чего начать на своём проекте
Внедрять сразу canary с полной автоматизацией не нужно. Разумный путь — от простого. Начните с blue-green на двух каталогах или двух серверах и ручного переключения через веб-сервер: это уже даёт мгновенный откат и убирает простой.
Параллельно наведите порядок в миграциях (обратная совместимость), вынесите файлы и сессии в общее хранилище, настройте прогрев кэша. Когда базовый blue-green работает надёжно, добавляйте автоматизацию выкатки и, при необходимости, canary для рискованных релизов. Так вы получаете пользу быстро и наращиваете зрелость процесса по мере роста нагрузки.
Частые ошибки
- Ломающие миграции. Меняют схему БД несовместимо, и откат или старая версия падают.
- Разные файлы у окружений. upload не общий — картинки и документы теряются при переключении.
- Переключение на холодный кэш. Не прогрели версию — магазин тормозит в момент выкатки.
- Двойные агенты. Фоновые задачи выполняются на обеих версиях, дублируя работу.
- Откат на эмоциях. Пороги не заданы заранее, решение об откате принимают в панике.
- Нет бэкапа. Выкатывают без свежей резервной копии, лишая себя последней страховки.
Чек-лист деплоя без простоя
- Стратегия выбрана. Blue-green для обычных релизов, canary — для рискованных на большом трафике.
- Миграции совместимы. Изменения схемы обратно совместимы и разбиты на шаги.
- Данные общие. Файлы upload, сессии и корзины в общем хранилище для обоих окружений.
- Кэш прогревается. Композитный и каталожный кэш наполняются до переключения.
- Переключение атомарно. Трафик меняется мгновенно на уровне балансировщика или веб-сервера.
- Пороги отката заданы. Метрики 5xx, скорости и конверсии с ясными порогами до деплоя.
- Агенты согласованы. Фоновые задачи не дублируются между версиями.
- Бэкап готов. Свежая резервная копия сделана перед выкаткой.
Вывод
Простой при выкатке — это не неизбежность, а следствие процесса, который можно изменить. Blue-green и canary превращают релиз из стрессового ночного события в спокойную обратимую операцию: две версии, мгновенное или постепенное переключение и откат за секунды снимают страх обновлений.
На 1С-Битрикс всё это реализуемо и без тяжёлого DevOps — если позаботиться о совместимых миграциях, общих файлах и сессиях, прогреве композитного кэша и заранее заданных порогах отката. Начните с простого blue-green, доведите его до надёжности и наращивайте зрелость. Тогда обновления станут частыми, мелкими и безопасными, а магазин перестанет терять заказы на каждой выкатке.
