Миграция в облако: наш опыт

Почти во всех компаниях ИТ-подразделение организационно делится на два блока: ответственные за эксплуатацию инфраструктуры и ответственные за сопровождение/развитие непосредственно информационных систем. Как правило, инициируют создание частного облака специалисты, отвечающие за инфраструктуру. Для них это долгожданный шанс построить отвечающую современным реалиям среду, в которой используются наиболее популярные и передовые на сегодняшний день технологии. И конечно, эти люди стремятся уйти от множества наболевших проблем, накопившихся при эксплуатации старой инфраструктуры. Но нередко специалисты, планирующие создание частного облака, уделяют недостаточно внимания этапу непосредственной миграции приложений — другими словами, не прорабатывают все технические нюансы этого этапа. И благие намерения приводят к неожиданным проблемам.

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

Что дает миграция в облако

Итак, после того как все заинтересованные стороны привлечены и у всех сложилось адекватное представление о работе частного облака, необходимо решить, какая архитектура должна быть у той или иной информационной или инфраструктурной системы после переезда. Можно переносить системы по принципу as is. Но если при начальном планировании уделить должное внимание наиболее критичным для компании ИС, то в процессе миграции можно повысить уровень их отказоустойчивости, т.е. совместить работы по переносу с действиями по улучшению текущей архитектуры. Планирование миграции приложений в частное облако — прекрасный повод пересмотреть свои RTO и RPO для информационных систем.

Технологии меняются стремительно, и то, что считалось передовым еще 4 года назад, сегодня зачастую не может удовлетворить новые запросы бизнеса. В ежедневной деятельности, когда требуется срочно решить какие-то бизнес-задачи, нередко приходится это делать очень быстро, но не совсем правильно с точки зрения ИТ-архитектуры — в надежде на то, что при следующей закупке оборудования что-то будет перенесено, а что-то когда-нибудь удастся переделать. Но нет ничего более постоянного, чем временное, и история повторяется из раза в раз. В результате в крупной компании образуется «зоопарк» технических решений и используемых технологий. Помимо того, что содержание всего этого обходится недешево, приходится удерживать людей с ключевыми знаниями, что увеличивает ФОТ. Поэтому построение облака и перенос в него приложений — долгожданный повод начать жизнь с чистого листа. При правильном подходе все архитектурные решения, которые используются для ваших приложений, должны быть типизированы и стандартизированы для соответствующих классов критичности, обеспечивающих необходимые RTO/RPO.

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

Сложности при миграции

Первое, что здесь нужно отметить: информационные системы, которые нужно перенести, появились задолго до частного облака (иногда сильно задолго) и эксплуатируются уже не один год. Рост и развитие данных ИС не всегда идут линейно, часто применяются временные решения, которые потом никто не переделывает, и в итоге к моменту миграции имеется архитектура ИС, использующая старые версии ОС, старые версии СУБД и т.п., которые не планируется использовать в облаке, да и сама существующая архитектура далека от идеала. Если вы хотите сразу навести порядок с такими системами, то для этих целей необходимо предусмотреть временны́е и трудовые ресурсы.

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

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

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

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

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

На наш взгляд, при осуществлении миграции наиболее оптимальной будет следующая последовательность действий:

1. Проведение BIA (business impact analysis) и составление полного списка ИС, которые будут целевыми в компании на горизонте ближайших 5 лет, с их ранжированием по классам критичности. Кроме того, каждую ИС надо обследовать, чтобы оценить текущую архитектуру, объемы данных и связи/интеграцию с другими ИС. Не следует забывать и об аудите инфраструктуры для определения возможности повторно использовать какие-либо ее компоненты или обеспечивать необходимую связность с облаком в процессе миграции.
   
   
2. Эскизное проектирование и разработка типовых архитектурных решений. Это, пожалуй, один из ключевых этапов, который к тому же является одним из самых дискуссионных, т.к. сколько людей, столько и мнений. Итогом всех обсуждений должен стать альбом типовых архитектурных решений, которые будут применяться для ИС, развернутых в частном облаке, и обеспечивать необходимые уровни RTO и RPO.
   
   
3. Сайзинг. Результаты аудита позволят определить, какое количество ресурсов требуется для работы той или иной ИС на текущий момент. По итогам эскизного проектирования можно будет оценить объем ресурсов, необходимый для ее работы в облаке. Он будет определяться типом архитектурного решения и показателями RTO/RPO (например, если какая-либо ИС использовала N ресурсов, то в облаке для нее уже может потребоваться 2N). В таких оценках всегда стоит учитывать средний годовой прирост ИС, рассчитываемый на основе исторической информации. Очень важным фактором является учет планов развития инфраструктуры на ближайшие несколько лет и общих планов компании, особенно если известны стратегические инициативы: поглощение других компаний, интенсивный рост определенных направлений бизнеса и т.п.
   
   
4. Создание системы автоматизации предоставления ресурсов и настройка системы биллинга и аллокации затрат. Данная тематика очень обширна и заслуживает отдельной статьи. Здесь лишь отметим, что завершить этот шаг следует до начала миграции ИС.
   
   
5. Создание отдельных рабочих групп для миграции каждой конкретной ИС. В состав рабочей группы должны быть включены: исполнитель, инфраструктурные администраторы, прикладные администраторы, специалисты по безопасности, представители бизнеса (иногда). Здесь ключевая роль должна быть у менеджера/координатора данного проекта, т.к. сложнее всего будет управлять коммуникациями и координировать всех участников процесса миграции. Специально отметим, что потребуется отдельный комитет с участием руководителей, который должен с определенной периодичностью рассматривать проблемы, разногласия и затруднения, которые могут возникать у каждой из таких рабочих групп.
   
   
6. Разработка общего плана миграции. Процесс миграции сильно влияет на бизнес. Данный план должен учитывать весь объем работ и быть достаточно детализирован, чтобы всегда можно было узнать, в каком состоянии находится процесс миграции той или иной системы. При разработке плана следует учитывать моратории на проведение работ в период высоких сезонов для бизнеса. Для финансовых систем нужно принимать во внимание ограничения, вызванные окончанием кварталов. Как уже отмечалось выше, необходимо помнить о графике релизов и доработок, которые могут проводиться для информационной системы параллельно с ее подготовкой к миграции.
   
   
7. Определение успешного критерия переноса ИС в частное облако и его проверка. Как определить, что ИС после изменений работает нормально? Что такое нормально и как это проверить? Можно предложить подход, когда до миграции согласовывается ряд ключевых метрик, которые замеряются до и после изменения системы (например, с использованием мониторинга). Кто-то будет считать, что успешность — это обеспечение заявленных RTP/RPO, тогда надо сразу при миграции планировать испытания данной ИС по ранее согласованной методике.
   
   
8. Детальная проработка непосредственно плана переноса. Обычно вся миграция конкретной ИС делится на этапы с учетом максимально возможного окна простоя и необходимого времени на откат изменений, если что-то пошло не так. Для каждого этапа нужно разработать почасовой план с четким описанием последовательности шагов и назначить ответственного исполнителя по каждому пункту плана. Хорошей практикой будет выделение отдельных людей для координации работ в период простоя, определение модели эскалации в случае проблем и четких критериев принятия решения по активации плана отката с указанием лиц, которые такое решение могут принять.
   
   
9. Главное — не навредить. Все проводимые изменения и их последствия не должны негативно влиять на бизнес. Есть ряд простых шагов, о которых никогда не стоит забывать: резервное копирование до выполнения работ, настройка резервного копирования системы, которая уже перенесена в облако, постановка на мониторинг новых компонентов, выведение из мониторинга уже неактивных узлов. Необходимо информировать сотрудников, осуществляющих эксплуатацию и доработку ИС, а также дежурную смену о том, что ИС теперь имеет новую архитектуру. Следует скорректировать регламенты и документацию. Казалось бы, очевидные вещи, но, на наш взгляд, они заслуживают отдельного внимания, т.к. если о них забыть, то проблемы, которые могут возникнуть, способны дискредитировать в глазах бизнес-пользователей весь проект.

Вывод

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