Почему миграция в облако затягивается: три системных причины
Облачная миграция почти всегда занимает дольше запланированного. Три причины, которые я вижу постоянно, и как с ними работать.
Почти каждый проект миграции в облако, который я наблюдал, занял дольше, чем предполагалось в начале. Иногда в полтора раза. Иногда в два. Иногда больше. При этом команды были компетентными, бюджеты выделены, технологические решения верными.
Дело не в технологии. Дело в трёх системных причинах, которые почти всегда присутствуют - и почти никогда не учитываются в первоначальном плане.
Первая причина: скрытые зависимости
На старте проекта обычно есть список систем для миграции. Кажется, что список полный. На практике оказывается, что каждая система связана с другими способами, которые не задокументированы.
Приложение А обращается к базе данных Б напрямую, в обход официального API. Сервис В читает файлы из сетевой папки, которая физически находится на сервере системы Г. Отчётная система Д раз в ночь подключается к Е через старый протокол, о котором никто не помнил.
Эти зависимости обнаруживаются в процессе миграции, а не до неё. Каждая - это стоп, анализ, решение. Умноженное на количество систем - это месяцы.
Что помогает: перед миграцией провести картирование зависимостей. Не по документации - по реальному трафику. Инструменты мониторинга сети за несколько недель покажут, кто с кем реально разговаривает.
Вторая причина: организационное трение
Миграция в облако - это изменение операционной модели, а не только технической. Команда разработки, команда инфраструктуры, ИБ, финансы, операционный бизнес - у каждого свои требования, приоритеты и темп принятия решений.
Типичный сценарий: техническое решение принято, архитектура согласована, и потом проект останавливается на несколько недель, потому что ИБ требует аудит новой конфигурации. Или финансы не могут утвердить изменение модели расходов до следующего квартала. Или бизнес-подразделение не готово к остановке системы в предложенное окно.
Это не технические проблемы. Это проблемы управления изменениями, которые не были предусмотрены в плане.
Что помогает: включить ключевых стейкхолдеров из всех затронутых подразделений в планирование с самого начала. Не для того, чтобы они одобрили техническое решение, а чтобы их ограничения и требования были известны до старта, а не обнаруживались в процессе.
Третья причина: недооценка legacy
Legacy-системы - это не просто старый код. Это системы, в которых за годы накопилась бизнес-логика, которая не задокументирована нигде, кроме самого кода. И часто - кода, который никто из текущей команды полностью не понимает.
При миграции это проявляется так: поднимаем систему в облаке, она технически работает, но что-то ведёт себя не так. Начинаем разбираться - оказывается, в старом окружении была настройка, которая компенсировала поведение другой системы. Или была зависимость от конкретной версии библиотеки. Или поведение зависело от временной зоны сервера.
Всё это находится в процессе, а не до него. И каждая такая находка - время.
Что помогает: реалистично оценить "понятность" legacy-систем. Если систему обслуживает один человек, который знает её лучше всех - это риск для миграции. Если документации нет - заложить время на изучение до начала переноса.
Как планировать реалистично
Я не знаю универсального коэффициента поправки для облачных миграций, потому что он сильно зависит от специфики. Но два правила работают почти всегда.
Первое: любая оценка сроков, сделанная без картирования зависимостей и без участия ИБ и финансов - не оценка, а гипотеза. Относитесь к ней соответственно.
Второе: миграция идёт не по прямой. Закладывайте итерации, откаты и стоп-вехи для оценки прогресса. Проект, который ушёл в долгое плавание без промежуточных точек контроля, очень сложно остановить или скорректировать.