Инфраструктурные кочевники: делаем переезды скучными

Почему успешный деплой еще не означает, что инфраструктурный переезд завершен? На опыте пяти миграций расскажу, как наша команда переходила от ручных действий и знаний «в головах» к воспроизводимому процессу с понятными проверками и ответственностью.

Разберем историю внешнего cron, который незаметно маскировал дефект приложения, и повторную миграцию контента Strapi, после которой нас выручил старый резервный бакет. На учебном примере посмотрим, как неочевидная ошибка селектора Kubernetes отправляет запросы не в тот компонент, хотя приложения выглядят работоспособными. Покажу, какую роль в повторяемости развертывания сыграли IaC, Helm и GitOps.

Отдельно расскажу, как мы связали деплои с обновлением паспортов сервисов и стендов: пайплайн собирал сведения из репозиториев развертывания и создавал merge request в репозиторий документации. Обсудим подготовку standby-базы с репликацией до переключения, наблюдение за техническими и бизнес-показателями, репетиции и планирование отката. Поговорим и о командной стороне переезда: передаче знаний, раннем обсуждении рисков и взаимодействии с разработчиками вместо бесконечного переноса старых обходных решений.

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