Твои действия во время деплоя

Мои действия во время деплоя

Во время деплоя я действую как дирижёр оркестра, координируя автоматизированные процессы и готовый вмешаться вручную при любых отклонениях. Мой подход основан на принципах неизменяемой инфраструктуры, CI/CD и полной наблюдаемости. Вот пошаговый алгоритм, который я применяю:

1. Преддеплойная подготовка и проверка

Перед запуском любого деплоя я выполняю серию обязательных проверок:

• Валидация пайплайна: Убеждаюсь, что все этапы CI (сборка, тестирование, сканирование безопасности) прошли успешно. Проверяю артефакты (образы Docker, пакеты) в артифакт-репозитории (например, Nexus, JFrog Artifactory).
• Анализ изменений: Изучаю, что именно меняется в этом релизе — код приложения, конфигурация инфраструктуры (Terraform/Ansible), переменные окружения. Оцениваю риск.
• Проверка окружения: Убеждаюсь, что целевое окружение (Staging/Production) здорово: мониторинг показывает "зелёный" статус, нет активных инцидентов, ключевые метрики (CPU, память, ошибки) в норме.
• Коммуникация: Информирую команду (разработчиков, тестировщиков, менеджеров) о начале деплоя, его ожидаемой длительности и потенциальном воздействии.

2. Запуск деплоя и стратегия развёртывания

Я запускаю деплой через систему оркестрации (Kubernetes, AWS CodeDeploy, Ansible Tower), используя одну из безопасных стратегий:

• Сине-зелёный деплой (Blue-Green): Разворачиваю новую версию на параллельном, идентичном "зелёном" окружении. После полного развёртывания и проверки переключаю трафик (например, с помощью Ingress Controller в k8s или ALB в AWS).
• Canary-релиз: Разворачиваю новую версию на небольшом проценте подов/серверов (например, 5%), направляю на них часть трафика, анализирую метрики, и только затем постепенно наращиваю долю.

Пример команды для Canary-деплоя в Kubernetes с использованием Istio:

# VirtualService для направления 10% трафика на canary-версию
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp-vs
spec:
  hosts:
    - myapp.example.com
  http:
  - route:
    - destination:
        host: myapp
        subset: stable
      weight: 90
    - destination:
        host: myapp
        subset: canary
      weight: 10

3. Непрерывный мониторинг во время и после деплоя

Это самый критический этап. Я наблюдаю за ключевыми дашбордами в реальном времени:

• Технические метрики: Загрузка CPU/памяти, потребление сети, время ответа (latency), rate ошибок (например, 5xx в Nginx/Istio).
• Бизнес-метрики: Количество успешных транзакций, конверсия, активные пользователи — всё, что показывает, что приложение не просто "работает", а "работает правильно".
• Логи приложения: Ищу появление новых ошибок (ERROR, FATAL) или подозрительных паттернов с помощью ELK-стека или Loki.

Если метрики выходят за установленные SLO (Service Level Objectives), например, ошибок становится больше 0.1%, я немедленно инициирую откат (rollback).

4. Процедура отката (Rollback)

Откат должен быть быстрым (одной командой) и предсказуемым. В зависимости от инструментария:

• В Kubernetes это может быть откат к предыдущему revision Deployment:

  kubectl rollout undo deployment/myapp
  

• При сине-зелёном деплое — это мгновенное переключение трафика обратно на "синее" стабильное окружение.
• В Terraform — применение предыдущего, проверенного состояния.

После отката я анализирую корневую причину (Root Cause Analysis) неудачного деплоя вместе с командой разработки.

5. Постдеплойные действия

После успешного деплоя:

• Финальная проверка: Выполняю smoke-тесты или проверяю критичный функционал вручную.
• Документирование: Обновляю версию в документации, создаю тег релиза в Git.
• Уведомление: Сообщаю команде об успешном завершении.
• Сбор метрик деплоя: Записываю ключевые показатели — время деплоя, успешность, количество инцидентов — для улучшения процесса в будущем.

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