Как добиться успешной миграции приложений

Для предприятий возможность переноса тысяч приложений является неотъемлемой частью сохранения конкурентоспособности. Выяснение того, как добиться успешной миграции, пугает, поэтому давайте углубимся в ловушки, которых следует избегать.

Текущий мировой кризис привел как к нехватке технических специалистов, так и к увеличению спроса на ускоренные технические сроки. Многие компании начинают сталкиваться с эффектом «красной королевы», когда компаниям приходится заново определять, как и где они конкурируют на рынке, чтобы оставаться актуальными.

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

Согласно исследованию, проведенному Boston Consulting Group, в котором приняли участие 825 руководителей высшего звена в 70 компаниях, проводивших 895 цифровых преобразований, только 30% преобразований достигли своих целей.

Это не цифры, которые внушают доверие. К счастью, такие компании, как Stark & Wayne, поработали над тем, чтобы обеспечить множественную миграцию предприятия, чтобы другие могли ее избежать. Stark & Wayne является экспертом в области миграции корпоративных инфраструктур. Прошлые проекты включали развертывания Cloud Foundry Foundation, которые управляют 45 000 экземпляров приложений.

Задокументируйте базовый уровень производительности

Это мандат! Каждая компания требует повышения производительности, но многим не хватает базовых показателей производительности или способов измерения того, что означает более высокая производительность. Связана ли производительность с опытом конечного пользователя? Основана ли производительность на увеличении и уменьшении рабочих нагрузок для снижения потребления? Измеряется ли производительность сокращением времени развертывания или обновления? Как только вы определите, как вы будете измерять производительность, вы сможете связать ее со своими приложениями, клиентами и бизнесом.

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

То, что вы измеряете, зависит от бизнес-требований, но некоторые общие все-же есть.

Список стандартных поинтов проверки

• Время работы компонентов
• Время отклика приложения
• Общее время выполнения приложения
• Тестовые приложения для проверки подключения компонентов и доступности сервисов
• Показатели API (загрузка страницы, использование памяти, ЦП, производительность сервера)
• Выходная нагрузка журнала
• Загрузка отчетов о заболеваемости с течением времени
• Автоматизация (и относитесь к автоматизации как к первоклассному гражданину, потому что она улучшит общую производительность)
• Изменения операционных расходов в связи с миграцией и автоматизацией задач
• Протестируйте типы приложений, которые моделируют вашу среду.
• Хорошие информационные панели: вы не можете перенести то, что не можете найти

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

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

Последнее, что вы хотите сделать, — это перенести нефункциональное приложение (мы видели, как это происходит), когда приложение необходимо удалить или исправить перед миграцией. Удивительно часто вы обнаружите, что главного сопоставления владельцев приложений не существует, что вызывает проблемы во время и после миграции.

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

Когда начать? Сначала ответьте на общие вопросы:

• В каких регионах вы работаете и почему?
• Какие приложения работают в каждом регионе?
• Какие услуги использует каждое приложение в каждом регионе?
• Какая версия Linux используется?
• Какие приложения взаимодействуют с другими приложениями в регионе?
• Какие приложения клиентские, а какие внутренние?

Сбор этих начальных точек данных не ответит на все неизвестные, но они начнут давать необходимую вам информацию.

Проверяйте то, что можете: и принимайте непознаваемое

Независимо от того, насколько хорошо вы проверяете или документируете каждую деталь, будут неизвестные переменные, влияющие на время простоя, клиентов, сотрудничество.