Всем привет! Меня зовут Макаров Иван, я руководитель программы Tech for Tech проектов в Magnit Tech. Последние 1,5 года мы реализуем масштабный технологический проект по выносу наиболее критичных информационных систем (далее — ИС) из единой платформы‑монолита на выделенную инфраструктуру. Проект интересен своим масштабом и сложностью, и сегодня я расскажу, как мы справились с высоким уровнем неопределенности, скрытыми зависимостями, требованиями бизнеса и другими трудностями.
Сразу предупрежу: будет практика и честные выводы. И я был бы безгранично рад, если бы перед стартом проекта нашел и прочитал подобную статью.
Зачем мы это делаем
Платформа поддерживает ключевые бизнес-процессы компании и уже много лет фактически выполняет роль ERP-системы. Сама платформа реализована на технологиях Oracle (Сервера Spark m7, Oracle DB) и требует модернизации, так как за годы существования обросла различным функционалом и достигла своего ресурсного предела. Причина такого роста — ускорение time-to-market и простота размещения. В 2023 году суточная генерация изменений в БД (REDO-генерация) на пике достигала 14 тб/сутки, что приводило к отставанию standby до 300+ мин, а среднесуточная генерация за год была 10,5 тб/сутки, что в случае сбоя, не всегда гарантировало выполнения требований RTO и RPO (целевое время восстановления и целевая точка восстановления) для Mission Critical-систем. На основании исторических данных об органическом росте БД и развитию сети мы составили прогноз роста и увидели, что пик REDO-генерации, когда standby перестанет успевать переваривать обновления и станет просто «холодным резервом», наступит в Q4 2025. Следовательно, времени на полноценный предпроектный анализ попросту не было, и мы погнали.
Контекст проекта
Перед стартом проекта необходимо было понять какие ИС мы будем выносить в первом приоритете. Так как в БД на тот момент насчитывалось 246 сервисов, необходимо было актуализировать реестр ИС нашей платформы. Здесь пошли следующим образом:
От каждого домена были выделены Лидеры, которые курировали сбор и актуализацию информации о принадлежности сервисов к их ИС и планам по этим ИС.
Реестр мы сформировали довольно оперативно, выделили ТОП-20 сервисов по REDO-генерации, определили техническую возможность выноса этих ИС из платформы на выделенную инфраструктуру и сформировали перечень из 11 «счастливчиков», готовых к выносу в рамках первого этапа. В первую волну попали критичные ИС направлений блока коммерции, логистики и ГИСы. Вынос предполагал практически полное переписывание приложения на новый стек и перенос логики с уровня БД на средний слой. Важно понимать, что это были «живые» системы, со своим бэклогом развития, и это добавляло сложностей.
Масштаб проекта
32 сервиса БД к отключению в платформе
11 ИС к выносу на выделенную инфраструктуру и отдельными БД, с новым интеграционным ландшафтом и целевой архитектурой
6 Стримов проекта
около 50 человек к найму с привлечением около 60 действующих сотрудников
Как мы делали хаос управляемым
1. Итеративность вместо каскада
Стартовали мы с каскадными календарными планами, но по мере проведения работ неуклонно смещались вправо. Мы взяли фокус на снижение уровня неопределенности и решили пойти итеративно — квартальными циклами. За этот период Стримы совершали до 6 спринтов, после чего мы фиксировали прогресс, переоценивали сроки, оценивали влияние на финальные сроки и формировали меры по удержанию в границах изначально заявленных сроков.
2. Вовлечение заказчика вместо ультиматумов
По мере снижения уровня неопределенности вставал вопрос, как не только информировать Заказчика об изменениях, но и вовлечь его в процесс принятия решения, тем самым сделав его не критиком, а союзником для реализации этих изменений?
Ответом стала ежеквартальная встреча по управлению изменениями с ключевыми стейкхолдерами проекта, на которой мы анализировали текущую ситуацию, причины изменений и оценивали их влияние на проект. Главное — после оценки мы предлагали три варианта решения:
Базовый: оставить все как есть, выполнить объем работ с ранее согласованным ресурсом и сдвинуть сроки.
Умеренный: частично усилиться ресурсами и частично смягчить влияние изменений.
Оптимальный: дополнительно усилить операционные и проектные ресурсы для соблюдения заявленных сроков, пересмотреть бэклог или договориться с бизнесом о фича-фризе.
Заказчик и ключевые стейкхолдеры выбирали оптимальный сценарий. Включение их в процесс разработки плана действий помогало находить дополнительных драйверов этого сценария.
3. Создание центров экспертизы вместо перегруза Лидеров Стримов
Третьей проблемой на старте был потенциальный перегруз действующих экспертов, т.к. единовременно нам нужно было набрать приличное количество людей. Мы задокументировали все ключевые процессы и создали базы знаний по архитектуре и зависимостям. Да, такой подход в моменте замедлил системный анализ и темп на старте, но на дистанции дал результат — время на онбординг сократилось и новые сотрудники быстрее приступали к боевым задачам. При настроенном knowladge transfer уход или переключение экспертов не был бы для нас критичным.
4. Управление рисками вместо сюрпризов
Мы выстроили работу с рисками, понимая, что их материализация будет иметь критическое влияние на сроки завершения проекта. Так, на еженедельной основе мы проводили мониторинг рисков, синхронизировались с бизнесом и смежными командами, всегда имея в запасе план митигации и реагирования.
5. Карта внешних коммуникаций вместо неожиданностей
На старте проекты мы составили карту внешних зависимостей — график с планами со всеми сервисами и ИС, чье участие потребуется нам для выноса наших Стримов. Это позволило запланировать коммуникации и договориться о внесении наших задач в бэклог заранее.
Результаты
Прозрачный процесс принятия решений для всех участников проекта
Повышение доверия между командой и руководителями
Горизонт планирования вырос с 3 до 12 месяцев
Мы достигли ключевых задач проекта в 2024 году без существенных отклонений.
Что вынес для себя, и чем хочу поделиться?
-
Гибридные подходы — отличные решения в сложных проектах.
Но в нашем случае замечу: итеративность работает, только если есть жесткие контрольные точки.
Открытость и доверие помогает превратить риски в управляемые факторы.
Документируйте все. Даже то, что «и так все знают».
Адаптивность важнее слепого следования готовым паттернам.
Главный лайфхак: Превращайте стейкхолдеров в союзников, особенно если проект сложный. Недостаточно просто информировать об отклонениях — дайте им рычаги влияния и возможность выбора. Когда стейкхолдер принимает участие в выборе решения (как в нашем случае с тремя сценариями), он разделяет с вами ответственность и становится драйвером этого решения.