Деплой
29.07.2025

Деплой без слёз: как не убить продакшн

Сегодня поговорим о том, что заставляет ИТ-директоров седеть быстрее, чем просмотр логов в 3 утра — о деплое в продакшн. Как можно и как правильно.

Деплой (deployment) — это процесс доставки твоего прекрасного кода до пользователя.

Как доставка пиццы. Можно просто кинуть коробку через забор (FTP upload), а можно организовать целую логистическую сеть с отслеживанием, проверкой качества и возможностью вернуть обратно, если что-то пошло не так.

Почему это вообще тебе важно?

  • Потерянные деньги (простой = убытки)
  • Стресс команды (и твой лично)
  • Недовольные пользователи
  • Звонки в 2 ночи от техподдержки или директора

Хороший деплой — это магия, которая работает незаметно. В этом предложении вся суть.

Театр деплоя, какие бывают:

1. “Ковбойский” деплой (YOLO Deployment)

Что это: Берём код, заливаем на сервер через FTP, молимся. Иногда не проносит.

Плюсы:

  • Быстро
  • Просто
  • Адреналин в крови

💩 Минусы:

  • Может сломать нахрен всё
  • Откат = ещё один деплой
  • Твоя нервная система

Когда использовать: Pet-проект джуна. На работе – Никогда. Серьёзно. Не делай так.

Твой ковбойский деплой

2. Rolling Deployment (Раскатывающий деплой)

Что это: Обновляем серверы по очереди, как домино.

Как работает:

  1. Останавливаем сервер #1
  2. Обновляем код
  3. Запускаем, проверяем
  4. Переходим к серверу #2
  5. И так до конца

✅ Плюсы:

  • Нет простоя (если всё идёт по плану)
  • Можем остановиться на любом этапе
  • Относительно просто

❌ Минусы:

  • Долго для больших кластеров
  • Проблемы совместимости версий
  • Если что-то пошло не так на середине — будет весело

3. Symlink Deployment (Атомарный деплой)

Как работает:

  1. Храним несколько версий в папках releases/
  2. Веб-сервер смотрит на символическую ссылку current
  3. Деплой = атомарная смена ссылки
  4. Откат = смена ссылки обратно

✅ Плюсы:

  • Мгновенное переключение
  • Моментальный откат — просто переключить ссылку обратно
  • История версий — можем вернуться к любому из последних релизов
  • Простота реализации — не нужны сложные инструменты
  • Общие данные сохраняются (uploads, логи, кеш)

❌ Минусы:

  • Требует в 2-3 раза больше места на диске
  • Проблемы с БД миграциями
  • Только для одного сервера — не подходит для кластеров

4. Blue-Green Deployment (Главный герой сегодня)

Что это: У нас есть две одинаковые среды — “синяя” и “зелёная”. Пользователи работают с одной, мы готовим обновление на другой.

Алгоритм действий:

  1. Blue работает, пользователи счастливы
  2. Деплоим новую версию на Green
  3. Тестируем Green (у тебя же есть тесты?)
  4. Переключаем трафик с Blue на Green
  5. Blue становится fallback’ом (если Green говно сломался, переключаем всё раньше, чем прибежит директор)

На уровне веб сервера:

# nginx.conf
upstream backend {
    server blue.internal:8080 weight=100;   # Активная среда
    server green.internal:8080 weight=0;    # Готовим обновление
}

# После деплоя меняем веса:
upstream backend {
    server blue.internal:8080 weight=0;     # Резерв
    server green.internal:8080 weight=100;  # Новая активная
}

Плюсы:

  • Мгновенный откат (просто переключаем обратно)
  • Нулевой простой
  • Полное тестирование перед переключением
  • Спокойный сон ИТ-директора

💰 Минусы:

  • Двойные ресурсы (два одинаковых окружения)
  • Сложности с базой данных (миграции)
  • Более сложная инфраструктура
  • Нужно пояснить за шмот шарить в DevOps

5. Canary Deployment (Канарейка в угольной шахте)

Что это: Выкатываем новую версию только части пользователей. Если “канарейка” выживает — выкатываем всем.

ВК так расскатывает все свои релизы:

95% пользователей  Stable Version (v1.0)
 5% пользователей  Canary Version (v2.0)

✅ Плюсы:

  • Минимальный риск
  • Реальная обратная связь от пользователей
  • Постепенное увеличение нагрузки

Минусы:

  • Сложность мониторинга
  • Нужна хорошая аналитика
  • Сложность в A/B тестировании

6. Feature Flags (Фичи под капотом)

Что это: Код новой функции уже в продакшне, но “выключен” флагом. Включаем когда готовы.

Как это выглядит обычно:

// PHP код
if (FeatureFlag::isEnabled('new_payment_system', $user)) {
    return $this->newPaymentProcessor->process($payment);
} else {
    return $this->oldPaymentProcessor->process($payment);
}

Плюсы:

  • Мгновенное включение/выключение
  • A/B тестирование из коробки
  • Откат без деплоя

Минусы:

  • Усложняет код
  • Технический долг (старые флаги)
  • Нужна система управления флагами

Самое страшное место – БД

Blue-Green с базой данных — это как жонглирование бензопилами. Одна ошибка и… привет, восстановление из бэкапа в 3 утра.

Главная проблема: У тебя две среды, но база данных одна. Как обновить схему БД без поломки старой версии приложения?

Стратегии выживания:

1. Shared Database (Одна база на всех)

Как работает: Blue и Green используют одну БД. Миграции должны быть совместимы с обеими версиями.

-- ❌ Плохо: удаляем колонку сразу
ALTER TABLE users DROP COLUMN old_field;

-- ✅ Хорошо: поэтапная миграция
-- Деплой 1: добавляем новую колонку 
ALTER TABLE users ADD COLUMN new_field VARCHAR(255);
-- Деплой 2: переносим данные, обе версии работают 
UPDATE users SET new_field = old_field WHERE new_field IS NULL;
-- Деплой 3: удаляем старую (через несколько релизов) 
ALTER TABLE users DROP COLUMN old_field;

Плюсы:

  • ✅ Просто в настройке
  • ✅ Нет проблем с синхронизацией
  • ✅ Одна точка правды

Минусы:

  • ❌ Медленные миграции (backward compatibility)
  • ❌ Накапливается технический долг
  • ❌ Разработчики тебя ненавидят за “костыли”

2. Database Per Environment (Своя база для каждой среды)

Плюсы:

  • ✅ Полная изоляция
  • ✅ Можно тестировать любые миграции
  • ✅ Быстрый откат = переключение базы

Минусы:

  • ❌ Синхронизация данных = чистый ад
  • ❌ Двойные ресурсы
  • ❌ Сложность с пользовательскими данными

3. Read Replicas для тестирования (очень мало где сможет пригодиться)

production_db: master (для Blue)
green_environment: read_replica (для тестов)

Плюсы:

  • ✅ Реальные данные для тестирования
  • ✅ Не влияем на продакшн
  • ✅ Дешевле полного дублирования

Минусы:

  • ❌ Read-only ограничения
  • ❌ Лаг репликации (данные отстают)
  • ❌ Нельзя тестировать миграции записи

4. Database Branching (Современный подход)

Database Branching – это возможность создавать “ветки” базы данных, как в Git для кода. Каждая ветка – это полная копия БД, которую можно независимо изменять, тестировать и затем сливать обратно.

Инструменты: PlanetScale (MySQL), Neon (PostgreSQL), Xata или собственные решения

# Создаём ветку базы для Green
planetscale branch create myapp green-deployment
# Применяем миграции к ветке
planetscale schema apply myapp green-deployment
# Тестируем на ветке
# Если всё ОК — мержим в main
planetscale deploy-request create myapp green-deployment

Плюсы:

  • ✅ Как Git, но для базы данных
  • ✅ Безопасные миграции
  • ✅ Лёгкий откат

Минусы:

  • ❌ Не все БД поддерживают
  • ❌ Дополнительные инструменты
  • ❌ Стоимость

5. Event Sourcing + CQRS (Для продвинутых и богатых)

Event Sourcing – храним историю, а не состояние. Вместо хранения текущего состояния БД мы храним все события, которые к этому состоянию привели. Можем “перемотать” базу к любому моменту.

В обычной БД:

Баланс: 1000₽

В Event Sourcing:

События:
1. Счёт открыт: +0₽
2. Пополнение: +1500₽
3. Покупка кофе: -150₽
4. Зарплата: +50000₽
5. Аренда: -30000₽
6. Покупка: -350₽
---
Текущий баланс = сумма всех событий = 21000₽

CQRS – читаем и пишем в БД раздельно. Суть: Разделяем операции чтения (Query) и записи (Command) на разные модели.

Плюсы:

  • ✅ Полная история изменений
  • ✅ Лёгкий откат к любому состоянию
  • ✅ Аудит из коробки

Минусы:

  • ❌ Сложность архитектуры – намного сложнее обычного CRUD
  • ❌ Нужно переучивать разработчиков
  • ❌ Не подходит для простых CRUD приложений

Как не проспать катастрофу?

Базовые метрики для старта:

  • HTTP статус-коды — рост 4xx/5xx ошибок = проблема
  • Время ответа — увеличение в 2+ раза = тормозит
  • Доступность эндпоинтов — /api/health, /login, /checkout должны отвечать

Health Checks уровнем выше

  • Глубокие проверки — не просто HTTP 200, а реальная работа БД/кэша
  • Зависимости — проверяй внешние API, очереди, файловое хранилище
  • Потребление ресурсов — CPU/RAM не должны скакать
  • Бизнес-процессы — регистрация, оплата, поиск работают?

Автоматический откат – уровень топ компаний

  • Триггеры отката — error rate >5%, response time >3 сек, health check fail
  • Время на принятие решения — максимум 2 минуты на анализ
  • One-click rollback — откат должен быть в один клик, а не в 10 команд на проде!

Если через 15 минут метрики не стабилизировались — откатываемся.

Лучше быстрый откат, чем долгое выяснение причин на директорате.

Когда что использовать?

🏠 Один сервер, один разработчик (Pet-проекты)

Типичные проекты:

  • Личный блог на WordPress
  • Лендинг студии веб-дизайна
  • Интернет-магазин на OpenCart
  • CRM на 1С-Битрикс для ИП

Что использовать:

  • Symlink Deployment — идеально для начала
  • ✅ Feature Flags — если хочешь выглядеть профессионально

Почему не Blue-Green: Зачем тебе два сервера по 5к₽/месяц для сайта, который приносит 20к₽? Считай бабки бро, даже если они не твои.

🏢 Малый бизнес (1-5 разработчиков)

Типичные системы:

  • amoCRM — продажи + интеграции с сайтом
  • Битрикс24 — CRM + проектное управление
  • RetailCRM — для интернет-магазинов
  • Мегаплан — управление задачами + CRM

Сценарий использования:

  • 1 основной сервер + 1 резервный
  • База данных на том же сервере
  • 1000-10000 пользователей
  • Простой в 30 минут = потеря 50000₽

Что использовать:

🟢 Blue-Green — если есть бюджет на второй сервер
🟢 Feature Flags — для A/B тестов в CRM

🏭 Средний бизнес (5-20 разработчиков)

Типичные системы:

  • Salesforce — корпоративная CRM
  • Microsoft Dynamics — ERP + CRM
  • SugarCRM — кастомизируемая CRM
  • Pipedrive — продажи + автоматизация
  • Собственная разработка на Laravel/Symfony

Архитектура:

  • 3-5 серверов приложений
  • Отдельный сервер БД (MySQL Master-Slave)
  • Load Balancer (nginx/HAProxy)
  • Redis для сессий
  • 10000-100000 пользователей

Что использовать:

🟢 Blue-Green — стандарт для этого уровня
🟢 Canary — для критичных обновлений
🟢 Feature Flags — обязательно для A/B тестов на клиентах

🏙️ Крупный бизнес (20+ разработчиков)

Типичные системы:

  • 1С:CRM — интеграция с 1С:Бухгалтерией
  • МойСклад CRM — для торговых сетей с кучей филиалов
  • Мегаплан Энтерпрайз — проектное управление + CRM для госсектора
  • Битрикс24 Энтерпрайз — корпоративный портал + CRM + документооборот
  • Собственная микросервисная архитектура

Архитектура:

  • 10+ микросервисов
  • Kubernetes кластер
  • Отдельные БД для каждого сервиса
  • Очередь сообщений (RabbitMQ/Kafka)
  • 10000+ пользователей
  • Интеграция с 20+ сервисами

Что использовать:

🟢 GitLab CI/CD — вся инфраструктура и конфигурация описаны в Git-репозитории
🟢 Canary + Feature Flags — двойная страховка
🟢 Blue-Green per microservice — каждый сервис независимо
🟢 Chaos Engineering — сломай систему контролируемо

Как понять когда пора апгрейдить деплой?

Пора переходить с YOLO на Symlink:

  • Первый платящий клиент
  • Команда больше 1 человека
  • Деплой чаще 1 раза в неделю

Пора переходить с Symlink на Blue-Green:

  • Простой стоит дороже второго сервера
  • Клиенты жалуются на нестабильность
  • Есть SLA с клиентами

Пора внедрять Feature Flags:

  • A/B тестирование критично для бизнеса
  • Нужно быстро отключать проблемные фичи
  • Разные версии для разных клиентов

Сложность деплоя должна расти вместе с бизнесом, а не опережать его.

Kubernetes для блога — это как Камаз для поездки в магазин за хлебом.
Но в то же время, помни: лучший твой деплой — тот, о котором никто не знает.

Да прибудет с вами спокойствие!