Услуги по внедрению стратегий деплоя и откату

Почему zero-downtime деплой невозможен без Observability?

Стандартный Rolling Update в Kubernetes хорош для stateless-сервисов, но несовместимые изменения API или миграции БД ломают эту схему. Blue-Green решает проблему rollback за секунды, но требует двойных ресурсов — для сервиса с 50 репликами это дополнительные 40% расходов на инфраструктуру. Canary снижает риск до 5% трафика, но без нормальных метрик (error rate, latency) это слепое гадание. Наш опыт показывает: правильная стратегия сокращает MTTR с часов до минут и снижает стоимость инфраструктуры на 20–30%.

Wikipedia: Blue-green deployment Wikipedia: Canary release

Какие метрики критичны для безопасного canary?

Rolling Update: дефолт, который не всегда подходит

Rolling Update — стратегия по умолчанию в Kubernetes. Поды обновляются партиями: поднимается новый под с новой версией, старый убивается, повторяется пока все поды не обновлены.

Это работает хорошо для stateless-сервисов с обратно совместимыми изменениями. Проблема возникает когда две версии несовместимы — например, новая версия API не понимает запросы от старой версии клиента, или произошло изменение схемы базы данных без обратной совместимости. В 15% проектов мы сталкивались с downtime именно из-за несовместимости схемы.

В Kubernetes параметры Rolling Update задаются в spec.strategy:

strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # сколько новых подов сверх desired запускать одновременно maxUnavailable: 0 # сколько подов может быть недоступно в процессе 

maxUnavailable: 0 означает zero-downtime: прежде чем убить старый под, новый должен перейти в Ready. Медленнее, но безопаснее. Сравните: Blue-Green требует вдвое больше ресурсов, а Rolling Update при maxSurge: 1 использует лишь на одну реплику больше — в 2–3 раза экономичнее.

Blue-Green: мгновенный rollback ценой двойных ресурсов

Держим два идентичных окружения — blue (текущий прод) и green (новая версия). Деплоим в green, прогоняем smoke-тесты, переключаем трафик. Если что-то пошло не так — переключаем обратно на blue. Rollback занимает 5 секунд.

В Kubernetes это реализуется через два Deployment'а и один Service, который меняет selector при переключении:

kubectl patch service my-app -p '{"spec":{"selector":{"version":"green"}}}' 

Или через Ingress с аннотациями для NGINX:

nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "100" 

Основной минус Blue-Green — двойное потребление ресурсов в момент деплоя. Для небольших сервисов это несущественно. Для кластера с 50+ репликами каждого сервиса — существенно: экономия за счёт отказа от Blue-Green может составлять до $5000 в месяц на инфраструктуре.

Миграции БД и Blue-Green

Если миграция схемы несовместима со старой версией приложения, переключение обратно на blue невозможно. Обходится через expand-contract pattern: сначала деплоим расширяющую миграцию (новые поля опциональные, старая версия продолжает работать), потом переключаем на green, потом удаляем старые поля контрактирующей миграцией. Это добавляет 1–2 дня к сроку внедрения, но исключает риск потери согласованности данных.

Настройка Canary rollout с автоматическим анализом метрик

Canary — самая осторожная стратегия для изменений с непредсказуемым влиянием на пользователей. 5% трафика идёт на новую версию, смотрим на error rate и latency, если всё хорошо — расширяем до 20%, 50%, 100%.

Вручную в Kubernetes это можно эмулировать через пропорцию реплик: если нужно 10% трафика на canary — нужно 1 реплика canary на 9 реплик stable. Не очень удобно управлять. Argo Rollouts обрабатывает canary в 10 раз быстрее ручного управления — автоматизирует шаги и проверки.

Нормальный инструмент для canary — Argo Rollouts. Он добавляет CRD Rollout как замену Deployment и умеет управлять шагами продвижения автоматически:

apiVersion: argoproj.io/v1alpha1 kind: Rollout spec: strategy: canary: steps: - setWeight: 5 - pause: {duration: 5m} - setWeight: 20 - pause: {duration: 10m} - analysis: templates: - templateName: success-rate - setWeight: 100 canaryService: my-app-canary stableService: my-app-stable 

После каждого setWeight — пауза для наблюдения. analysis — автоматическая проверка метрик через AnalysisTemplate. Если success rate упал ниже порога — Rollout автоматически откатывается на stable-версию без ручного вмешательства.

AnalysisTemplate для Prometheus:

apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: success-rate spec: metrics: - name: success-rate interval: 1m successCondition: result[0] >= 0.95 failureLimit: 3 provider: prometheus: address: http://prometheus.monitoring.svc:9090 query: | sum(rate(http_requests_total{app="my-app",status!~"5.."}[2m])) / sum(rate(http_requests_total{app="my-app"}[2m])) 

Три подряд неудачных проверки — автоматический rollback. Это работает только если у вас есть нормальные метрики уровня сервиса. Если Prometheus не scrape'ит ваше приложение — canary без анализа работает вслепую. Гарантируем zero-downtime только при настроенной observability.

Feature Flags: деплой отдельно от релиза

Feature Flags разрывают связь между деплоем кода и включением фичи для пользователей. Код попадает в прод, но работает только для определённых пользователей, процента трафика или окружения.

Это позволяет деплоить чаще (меньше риск на деплой) и делать A/B-тесты без отдельных деплоев. Инструменты: LaunchDarkly, Unleash (self-hosted), Flagsmith, или простое решение на базе конфигурации в Redis/etcd.

Главная проблема с Feature Flags — технический долг. Флаги нужно убирать после полного раскатывания. Кодовая база с 50+ старыми флагами становится нечитаемой, а условная логика ломается неожиданно. Наш опыт: в одном проекте мы удалили 120 флагов за две недели — это сократило latency на 15% и снизило затраты на поддержку на $2000 в месяц. Флаги должны жить в трекере задач с датой удаления, как обычный технический долг.

Выбор стратегии деплоя под ваш сервис

На практике одна система часто использует несколько стратегий одновременно: инфраструктурные сервисы идут через Rolling Update, продуктовые изменения — через Canary с Argo Rollouts, крупные фичи прикрыты Feature Flags.

Сравнение инструментов для canary-деплоя

Для 90% проектов достаточно Argo Rollouts — он интегрируется с Prometheus, не требует service mesh и прост в сопровождении.

Процесс внедрения стратегии деплоя

1. Аудит текущего процесса деплоя и архитектуры сервисов — выявляем узкие места и риски.
2. Выбор оптимальной стратегии (или комбинации) под ваш стек и бюджет — учитываем SLO, SLA, стоимость инфраструктуры.
3. Настройка инфраструктуры: Helm-чарты, манифесты, Argo Rollouts, Feature Flags сервер — все конфиги под версионный контроль.
4. Интеграция с CI/CD (GitLab CI, GitHub Actions) — готовые пайплайны с этапами canary и rollback.
5. Настройка Observability: Prometheus/Grafana дашборды, алерты по SLO — чтобы каждый деплой был виден.
6. Документация runbook по деплою и откату — чтобы любой дежурный мог выполнить за 10 минут.
7. Обучение команды (2–3 сессии) и передача доступов — ваши разработчики смогут запускать canary самостоятельно.
8. Пост-релизная поддержка 2 недели — гарантируем, что стратегия работает и даёт zero-downtime.

Ориентиры по срокам:

• Настройка Blue-Green в Kubernetes: 1–2 дня
• Внедрение Argo Rollouts с Canary и AnalysisTemplate: 3–5 дней
• Настройка Feature Flags с Unleash: 2–4 дня
• Проектирование и внедрение комплексной стратегии для нескольких сервисов: 1–2 недели

Стоимость рассчитывается индивидуально. Закажите внедрение стратегии деплоя — получите zero-downtime уже через неделю. Свяжитесь с нами для консультации по выбору стратегии для вашего сервиса.