Ночное окно обслуживания – привычная плата за релиз. Систему останавливают, выкатывают новую версию, проверяют, поднимают обратно. Если что-то пошло не так в три часа ночи, инженеры откатывают вручную под давлением. Для портала госуслуг, биллинга или внутренней ERP это означает недоступность сервиса и риск потери данных в момент переключения. Голубые-зеленые развертывания (blue-green deployment) убирают это окно простоя: пользователь не замечает момент смены версии.
Как работает схема
Вы держите два идентичных производственных окружения – «голубое» и «зеленое». В любой момент трафик принимает только одно из них, второе простаивает. Допустим, рабочее окружение – голубое. Новый релиз вы разворачиваете в зеленое, прогоняете на нем смоук-тесты, проверяете миграции и интеграции, пока живые пользователи работают с голубым и ничего не замечают.
Когда зеленое окружение готово, вы переключаете маршрутизацию – на уровне балансировщика нагрузки, обратного прокси или записи DNS. Трафик уходит на зеленое, голубое остается нетронутым и горячим. Если в первые минуты вскрывается дефект, откат – это обратное переключение маршрута, а не повторная выкатка. Секунды вместо часов. Старое окружение становится резервом для следующего релиза, и роли «голубое – зеленое» меняются местами на каждом цикле.
Что требует внимания
Главная сложность – состояние, а не код. Сессии, кеши и особенно база данных не клонируются переключением маршрута. Базу данных приходится держать общей для обоих окружений, а схему менять обратимо: сначала добавляете колонки и таблицы, не ломая старую версию, и только после полного перехода удаляете устаревшее. Это дисциплина расширяемых миграций, и закладывать ее нужно в архитектуру с самого начала, а не перед выкаткой.
Удвоение окружений стоит ресурсов. На физическом железе держать вторую копию продакшена дорого, поэтому схема разумна там, где есть виртуализация или приватное облако с возможностью быстро поднять и погасить окружение. Для госзаказчика это дополнительный аргумент в пользу собственной серверной инфраструктуры – тем более на фоне курса на импортозамещение ПО и перевода критичных систем на отечественные и открытые платформы. Окружения должны быть идентичны вплоть до версий ОС: если рабочие места и серверы у вас стандартизированы, например на Windows 10 Enterprise и фиксированном наборе серверного ПО, расхождения между голубым и зеленым сводятся к минимуму.
Где это дает эффект
Схема окупается на системах с жесткими требованиями к доступности и частыми релизами: личные кабинеты, платежные шлюзы, ведомственные порталы. Чем чаще вы выкатываете, тем дороже каждое окно простоя и тем ценнее мгновенный откат. Blue-green также упрощает приемку: заказчик проверяет релиз на боевом по составу окружении до того, как на него пойдет трафик.
Отдельно отметим, что чистое переключение версий дает достоверную аналитику. Вы точно знаете, какая версия обслуживала запрос в каждый момент, без смешения метрик переходного периода. Это важно, когда поверх данных строятся модели и прогнозы: грязный период двойной выкатки портит обучающую выборку.
Blue-green живет не сам по себе, а на подготовленной инфраструктуре с балансировкой, обратимыми миграциями и регламентами отката, которую нужно выстроить заранее.
Вывод
Голубые-зеленые развертывания – это не модный прием, а способ снять простой и страх ночных релизов. Цена – второе окружение и дисциплина миграций. Выгода – релизы в рабочее время, откат за секунды и предсказуемость, которую ценят и бизнес, и государственный заказчик.
