Безопасный деплой без простоя

MAATRIX

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

Почему обычный деплой опасен

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

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

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

Атомарный деплой через симлинки

Классический приём zero-downtime деплоя — релизы в отдельных папках плюс символическая ссылка на текущую. Структура выглядит так: каталог с релизами, где каждая версия лежит в своей папке с датой, и симлинк current, который указывает на активный релиз. Веб-сервер смотрит именно на симлинк.

/var/www/app/releases/2026-08-24-1200/
/var/www/app/releases/2026-08-24-1500/
/var/www/app/current -> releases/2026-08-24-1500

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

ln -sfn /var/www/app/releases/2026-08-24-1500 /var/www/app/current
systemctl reload php8.3-fpm

Переключение симлинка атомарно — оно происходит мгновенно и неделимо. В следующую же секунду сайт работает на новой версии, без промежуточного состояния. Reload обработчика PHP подхватывает изменения без обрыва текущих запросов.

Мгновенный откат

Главное преимущество релизов в отдельных папках — тривиальный откат. Если после деплоя что-то сломалось, вам не нужно ничего заливать заново: старая версия всё ещё лежит в своей папке. Достаточно переключить симлинк обратно:

ln -sfn /var/www/app/releases/2026-08-24-1200 /var/www/app/current
systemctl reload php8.3-fpm

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

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

Миграции базы данных

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

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

Автоматизация и проверка

Ручной деплой по шагам работает, но человек ошибается, особенно в спешке. Соберите весь процесс в скрипт: выкладка кода в новую папку, установка зависимостей, миграции, переключение симлинка, reload сервисов. Тогда деплой становится одной командой, повторяемой и предсказуемой. Добавьте в скрипт проверку здоровья после переключения — запрос к служебному URL, который подтверждает, что новая версия отвечает. Если проверка не прошла, скрипт может автоматически откатиться на предыдущий релиз.

Отдельно стоит прогонять изменения через staging перед боевым деплоем — тестовая копия ловит поломки до того, как они доедут до продакшена. Связка «проверил на staging, выкатил атомарным деплоем, при проблеме откатил симлинком» — это зрелая эксплуатация сервера, при которой обновления перестают быть источником стресса. Для стабильного продакшена берите VPS с гарантированными ресурсами — например, у MAATRIX, с оплатой из России картой или криптой.

Частые вопросы