Ответ
В DevOps откат — это не ручная процедура, а автоматизированный и спланированный процесс восстановления работоспособности системы. Я реализовывал несколько стратегий в зависимости от контекста.
1. Откат развертывания в Kubernetes: Используется встроенный механизм rollout. Каждый деплоймент хранит историю ревизий.
# Быстрый откат к предыдущей версии
kubectl rollout undo deployment/my-app
# Откат к конкретной ревизии (предварительно посмотреть историю)
kubectl rollout history deployment/my-app
kubectl rollout undo deployment/my-app --to-revision=3В пайплайне этот шаг может быть автоматически запущен при падении health checks после деплоя.
2. Откат инфраструктуры (Terraform):
- Через state: Используется версионирование state-файла в удаленном бэкенде (например, S3). При проблемах можно откатить state к предыдущей версии и применить
terraform apply. - Через код: Стандартный подход — закоммитить и запустить apply предыдущей, рабочей версии кода из Git. Это подчеркивает важность иммутабельности инфраструктуры.
3. Откат релиза в Git (GitOps): При использовании ArgoCD или Flux откат тривиален: нужно просто сделать revert проблемного коммита в Git-репозитории с манифестами. ArgoCD автоматически синхронизирует состояние кластера с предыдущей версией конфигурации.
4. Откат базы данных (наиболее сложный): Требует отдельной стратегии. Я применял:
- Миграции с откатом: Использовал инструменты вроде Flyway или Liquibase, где каждая миграция имеет обратный скрипт (down).
- Синие-зеленые деплойменты: Развертывание новой схемы БД параллельно со старой. В случае проблем переключение трафика обратно происходит на старую, неизмененную схему.
- Резервное копирование/восстановление: Автоматический снепшот БД (например, через AWS RDS snapshot) перед деплоем миграции. В случае провала — быстрое восстановление из снепшота.
Ключевой принцип: Откат должен быть быстрым, предсказуемым и тестируемым. Мы регулярно проводили drills по откату в staging-среде.