B2B
Enterprise
Saas
Миграция IT инфраструктуры в облако
Enterprise-система для анализа IT-инфраструктуры и планирования миграции в облако. Помогает архитекторам разобраться в существующей среде, сформировать группы для переноса, проверить зависимости и сравнить стоимость размещения у разных cloud-провайдеров.
Роль
Senior Product Designer
Зоны моей ответственности
UX-архитектура · Сценарии · Интерфейсы · Прототипирование
Период
2020 — 2022
Задача
В основе модуля Migrate был технический прототип, который умел собирать Inventory инфраструктуры и рассчитывать зависимости между ресурсами. Результат анализа представлял собой набор разрозненных Excel-файлов и графиков в PNG. Работать с такими данными было сложно.
Нужно было превратить возможности прототипа в полноценный продукт для планирования облачной миграции.
Моей задачей было детально спроектировать основной путь пользователя: от анализа исходной инфраструктуры до формирования плана миграции.
Сложность
До начала миграции архитектору нужно было разобраться в существующей инфраструктуре: понять, какие ресурсы относятся к приложениям, как они взаимодействуют, кто ими владеет и какие ограничения нужно учитывать.
Часть данных система могла получить автоматически. Другую — например, бизнес-контекст — приходилось собирать у разных участников со стороны клиента.
Только после этого можно было решить:
- какие ресурсы переносить вместе
- в какой последовательности
- какие зависимости могут повлиять на миграцию
- где разместить инфраструктуру и сколько это будет стоить.
Главная сложность была в том, чтобы собрать большое количество технических данных, сущностей и решений в последовательный рабочий процесс.
Процесс
Вместе с Head of UX мы формировали структуру нового продукта. Она задавала верхнеуровневые концепции, а я детализировала пользовательские сценарии и проектировала интерфейсы.
На входе были требования PM, возможности технического прототипа и записи интервью с migration-архитекторами.
Из этого постепенно сложилась структура Migrate:
Инвернатизация → Анализ среды → Группы перемещения → Сравнение стоимости → План миграции
Главный UX челлендж
Для принятия решений архитектору одновременно нужны два уровня информации:
- Общая картина — из каких частей состоит инфраструктура, как они связаны, где находятся наиболее значимые зависимости
- Технические детали — какие конкретно сущности взаимодействуют, по каким IP и портам, какой объём данных передаётся между ними
Если сразу показать все данные, интерфейс превратится в огромные таблицы. Если слишком сильно их агрегировать, архитектор теряет информацию, необходимую для принятия решения. Поэтому я строила интерфейсы по принципу от общей картины к проверяемым деталям.
Визуализации позволяли увидеть структуру и отследить важные связи. Каждый элемент был интерактивным: пользователь мог выбрать объект и раскрыть детальные данные.
При необходимости любой график можно было переключить в табличное представление для работы с точными значениями.
От инфраструктуры к плану миграции
В Inventory архитектор исследовал исходную инфраструктуру и формировал Move Groups — группы ресурсов, которые планировалось переносить вместе. В группу можно было включать отдельные compute instances или работать с более высокоуровневыми сущностями, например, Applications или Zones. После формирования группы система рассчитывала зависимости.
На уровне всех Move Groups архитектор мог увидеть связи между группами, а внутри конкретной — исследовать её состав и проверить:
- внутренние зависимости
- связи с ресурсами за пределами группы
- сетевое взаимодействие
- IP и используемые порты
- объём передаваемых данных
Это позволяло переходить от логического представления миграции (Applications, Zones, Move Groups) к конкретным техническим объектам и проверять, действительно ли выбранную группу можно рассматривать как единое целое.
Анализ стоимости миграции
После формирования Move Group нужно было определить подходящий вариант размещения в облаке.
В Cost Analysis пользователь мог сравнить стоимость группы у разных cloud-провайдеров (AWS, Microsoft Azure, Google Cloud, IBM Cloud и других) и с разными параметрами расчёта (Provider, Region, Mapping Option, Uptime).
Сравнение работало на нескольких уровнях: от общей стоимости Move Group можно было перейти к конкретному варианту, а затем — к отдельным VM и посмотреть предложенную конфигурацию и стоимость каждой из них.
Так пользователь мог не только увидеть наиболее выгодный вариант, но и проверить, из чего складывается расчёт.
Дизайн-спринты как метод решения сложных задач
На проекте мы несколько раз проводили дизайн-спринты по методологии Google. Они помогали быстро разбирать неоднозначные части продукта, синхронизировать продуктовую, дизайн- и техническую экспертизу и проверять разные подходы до детальной проработки интерфейсов.
Результат
Migrate прошёл путь от технического прототипа с результатами в Excel и PNG до полноценного enterprise-продукта, выпущенного в production и использовавшегося реальными клиентами.
В рамках проекта я спроектировала основной путь migration-архитектора: от исследования исходной инфраструктуры и зависимостей до формирования Move Groups и сравнения вариантов размещения в облаке.
Сам процесс миграции оставался за пределами продукта, но статус Move Groups позволял отражать его прогресс и сохранять связь между подготовленным планом и дальнейшей работой.
Команда проекта во время дизайн-спринта
