Пять вопросов, на которые технический директор обязан ответить до миграции унаследованной системы

До начала миграции унаследованной системы руководство должно получить задокументированные ответы на пять вопросов: какова измеримая стоимость текущей системы, какова стратегия миграции данных и кто за неё отвечает, возможна ли параллельная работа старой и новой систем, есть ли проверенный план отката и назначен ли куратор из числа топ-менеджеров с реальными полномочиями. Если ответов нет, организация к миграции не готова. Остановиться на этапе планирования гораздо дешевле, чем прервать проект на полпути.

Замена унаследованной корпоративной системы — одна из самых рискованных технических операций, на которые может пойти организация. В отличие от разработки с нуля, миграция означает разбор самолёта в полёте.

Унаследованная система стоит денег каждый месяц, пока остаётся в работе: латание, простои и функции, которые на ней не построить. Миграция заменяет систему, на которой работает бизнес, пока бизнес продолжает на ней работать.

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

1. Какова измеримая стоимость текущей системы?

«Она старая и медленная» — не обоснование для миграции такого масштаба. Боль нужно оцифровать:

• Сколько инженерных часов уходит на латание системы каждый месяц?
• Во что обошлись простои за последние 12 месяцев?
• Сколько запросов на новые функции заблокировано, потому что архитектура их не тянет?

Если вы не можете назвать точную сумму издержек от бездействия, у вас не будет рычага, чтобы защитить бюджет миграции, когда начнётся турбулентность.

2. Какова стратегия миграции данных и кто за неё отвечает?

Унаследованные системы — это десятилетия недокументированных изменений схемы, осиротевших таблиц и повреждённых записей. Новой системе нужны чистые нормализованные данные.

• Вы делаете миграцию одним переходом за выходные или поэтапно?
• Кто отвечает за очистку и сопоставление данных?
• Что происходит с активными транзакциями в окне переноса?

Если стратегия данных — второстепенная задача, отданная младшему администратору базы, миграция встанет.

3. Можете ли вы работать на старой и новой системе параллельно?

Самый рискованный подход — выключить старую систему в пятницу и включить новую в понедельник. Предсказуемые миграции используют паттерн Strangler Fig: перед унаследованной системой ставится API-шлюз, новая система строится по частям, и трафик постепенно переключается на неё, пока старое приложение продолжает обслуживать остальное (Microsoft Azure Architecture Center). Если ваша архитектура не позволяет работать обеим системам одновременно, вы принимаете на себя лишний риск.

4. Есть ли у вас проверенный план отката?

Исходите из того, что развёртывание провалится. Если вы перешли на новую систему, а наутро она легла под продакшен-нагрузкой, каков точный порядок возврата к старой?

План отката не бывает теоретическим. Он должен быть задокументирован, а время его выполнения — посчитано. Если откат требует вручную развернуть 50 000 транзакций, у вас не план отката, а сценарий катастрофы.

5. Кто ваши внутренние спонсоры и каковы их полномочия?

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

Если среднему менеджменту позволено не переходить или требовать бесконечных доработок, чтобы новая система работала в точности как старая, проект провалится. Нужен спонсор уровня совета директоров с полномочиями обеспечить переход и отказывать в разрастании функционала.

Что делать, если вы не можете ответить на все эти вопросы?

Если вы не можете ответить на эти вопросы с документами в руках, вы не готовы к миграции. Остановка плохо спланированной миграции на этапе планирования стоит политического капитала. Остановка на середине исполнения стоит гораздо дороже — и деньгами, и доверием бизнеса к следующей попытке.

Часто задаваемые вопросы

Почему миграция унаследованной системы так рискованна?

Бизнес продолжает работать на старой системе, пока идёт её замена. Сбой бьёт по текущим операциям, а не только по новому проекту. Это всё равно что чинить самолёт в полёте.

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

Используйте паттерн Strangler Fig. Перед унаследованной системой ставится шлюз API, новая система создаётся по частям, и трафик переводится на неё постепенно. Унаследованное приложение обслуживает остальные функции, пока переход не завершится.

Что делает план отката реальным?

Реальный план зафиксирован документально, а время на его выполнение рассчитано заранее. Если для возврата нужно вручную отменять огромное число транзакций в базе данных, это сценарий аварии, а не план. Исходите из того, что развёртывание может пойти не так, и пропишите точные шаги возврата.

Кто должен выступать спонсором миграции?

Руководитель уровня топ-менеджмента. У этого человека должны быть полномочия требовать перехода на новую систему и отказывать в раздувании функциональности. Без этого руководители среднего звена смогут саботировать внедрение или требовать бесконечных доработок, и проект провалится.