Как перенести инфраструктуру в облако без остановок и лишних расходов
На первый взгляд, миграция ИТ-инфраструктуры в облако кажется чисто техническим процессом: нужно переместить серверы, подключить пользователей и вернуться к обычной работе. Однако на деле компании сталкиваются с непредвиденными взаимосвязями, трудностями совместимости и даже утечками информации. В своем материале CNews разбирает, что на самом деле ожидает бизнес при переходе в облако и на какие риски стоит обратить внимание. В качестве иллюстрации CNews анализирует пример федеральной организации, которая перемещала свою ИТ-инфраструктуру в облако «МегаФона»: свыше 100 виртуальных машин. Своим опытом поделились Станислав Попов, директор департамента по развитию облачных и инфраструктурных продуктов «МегаФона», и Левон Дадаян, руководитель отдела эксплуатации облачных решений «МегаФона».
Зачем бизнесу переходить на облачные платформы
Еще несколько лет назад компании нередко воспринимали облако как резервную зону: туда отправляли тестовые среды или отдельные сервисы. Сегодня же переход на российские платформы стал стандартным инженерным проектом.
Бизнес выбирает облака по разным причинам. Оборудование становится дороже, и закупать технику «с запасом на пять лет» уже не так выгодно. Требования к надежности, безопасности и соблюдению законодательства становятся строже. А ИТ-инфраструктура должна быстрее реагировать на запросы бизнеса.
Главное преимущество облака для бизнеса — это гибкость. Компаниям больше не нужно приобретать оборудование для пиковых нагрузок. Например, чтобы справиться с наплывом клиентов дважды в год в период распродаж.
Теперь бизнес платит лишь за фактически использованные ресурсы и может оперативно расширять инфраструктуру при изменении нагрузки.
Трансформируется и функция ИТ-отдела. Если прежде ИТ-директор нес ответственность за всё — от приобретения оборудования до защиты данных, — то с переходом в облако часть этих обязанностей переходит к провайдеру. Для компании это означает смену приоритетов: вместо управления инфраструктурой теперь нужно управлять качеством услуг — следить за SLA, отказоустойчивостью, безопасностью, техподдержкой и оперативностью реагирования на сбои.
Почему миграция оказывается сложнее ожидаемой
Ключевое заблуждение бизнеса — считать миграцию простым техническим копированием: «Переместим серверы в облако — и всё продолжит работать как прежде». В реальности такой подход срабатывает редко. Всё потому, что инфраструктура компании — это не просто набор серверов, а целая система взаимосвязанных уровней:
- физическая инфраструктура — серверы, сети и системы хранения, на которых базируется вся ИТ-среда;
- среда виртуализации — программный слой, дающий возможность запускать на одном физическом сервере несколько независимых виртуальных машин и гибко распределять между ними ресурсы. Примеры: VMware, Microsoft Hyper-V;
- операционные системы — базовая среда, где работают приложения и сервисы компании. Примеры: Windows Server, Astra Linux;
- базы данных — системы для хранения и обработки информации. Примеры: Microsoft SQL Server, PostgreSQL;
- прикладное ПО — бизнес-инструменты, которые сотрудники используют ежедневно: 1С, CRM, ERP.
Кажется, что достаточно перенести лишь один из уровней. Иногда это действительно работает. Например, если компания переносит инфраструктуру с одной платформы VMware на другую VMware-среду, изменения обычно затрагивают только оборудование, сеть или площадку.
Однако сегодня большинство миграций проходят иначе. Импортозамещение, уход зарубежных вендоров и переход на новые платформы вынуждают компании менять сразу несколько инфраструктурных слоёв:
- VMware на Basis Dynamix;
- Windows Server на Astra Linux;
- Microsoft SQL Server на PostgresPro.
В таких случаях меняется весь технологический стек организации. Приходится заново проверять совместимость приложений, тестировать интеграции и адаптировать бизнес-логику.
Не менее важно, что инфраструктура компании — это система тесно связанных компонентов. Даже относительно небольшая среда из 10–20 виртуальных машин может включать базы данных, сервер приложений, файловые хранилища и десятки интеграций между ними. При этом каждый элемент зависит от других.
Просто перенести отдельный сервер или сервис недостаточно. Если мигрировать базу данных, но не обеспечить её связь с приложением, сервис перестанет функционировать. Если перенести фронтенд, но забыть про систему авторизации, сотрудники потеряют доступ. Если не учесть внутренние зависимости, инфраструктура может формально запуститься, но часть бизнес-процессов окажется нарушена.
В процессе переноса систем зачастую выясняется, что текущая инфраструктура давно нуждается в обновлении. За время её использования накопились неактивные серверы, перегруженные узлы и избыточные сервисы. В таких ситуациях архитекторы используют миграцию как шанс реорганизовать инфраструктуру: ликвидировать слабые места и оптимизировать нагрузку — чтобы система стала более надёжной и производительной.
Как проходит миграция на деле
Один из ярких примеров — перенос федеральной логистической и дистрибуционной компании.
Организация работает в 20 регионах России, в ней трудится почти 900 человек. Ранее вся инфраструктура базировалась у внешнего облачного провайдера и состояла из более чем 100 виртуальных машин. На них функционировали корпоративная почта, система управления заказами, внутренний портал, файловые хранилища, аналитические инструменты и базы данных.
Основу инфраструктуры составляли:
- платформа виртуализации VMware;
- виртуальные машины на базе Microsoft Windows Server;
- базы данных Microsoft SQL Server;
- сервер приложений, разработанный под стек Microsoft.
Поводом для миграции послужил целый ряд причин. Во-первых, компания запустила программу импортозамещения.
Во-вторых, руководство всё сильнее волновали вопросы отказоустойчивости. За год до начала проекта организация пережила серьёзный сбой у текущего провайдера. Из-за неполадок в системе хранения данных часть инфраструктуры была недоступна почти сутки. Перестали работать внутренняя CRM, система управления заказами и корпоративная почта. Региональные отделы не могли получить доступ к информации о клиентах и поставках, а финансовая служба потеряла часть отчётов.
Полное восстановление ключевых сервисов заняло 18 часов, а прямые убытки от простоя превысили 10 миллионов рублей. Клиент обратился в «МегаФон» за переносом ИТ-инфраструктуры в облако — чтобы уменьшить риск единичных сбоев, увеличить отказоустойчивость системы и подготовить её к расширению.
Этап 1: аудит инфраструктуры. Любая крупная миграция стартует с аудита. Архитекторы проанализировали инфраструктуру клиента, требования к доступности сервисов и нагрузку на системы. Одновременно команда «МегаФона» подбирала аналоги решений на импортозамещённом стеке и проверяла совместимость текущих систем с новой платформой.
В ходе проверки выяснилось, что за время работы инфраструктура стала значительно сложнее: некоторые ресурсы практически не задействовались, отдельные системы превратились в критические точки сбоя, а часть файловых хранилищ дублировалась между отделами. В связи с этим было решено изменить архитектуру.
Этап 2: проектирование. После анализа специалисты разработали целевую схему будущей системы. К процессу привлекли экспертов по кибербезопасности. Они создали новый защитный контур, включающий межсетевой экран (firewall), защиту от DDoS-атак, экран для веб-приложений (web application firewall) и правила разделения сети.
Затем архитекторы определили, какие сервисы должны выходить в интернет, какие функционируют через выделенные каналы связи, а какие требуется полностью изолировать.
Параллельно команда пересмотрела структуру приложений. Одной из задач было отказаться от крупных монолитных узлов и равномерно распределить нагрузку между несколькими элементами. Это помогло бы уменьшить вероятность единичных отказов и сделать инфраструктуру более устойчивой.
Этап 3: подготовка среды и сетевой связности. После проектирования команда развернула целевую инфраструктуру:
- новую среду виртуализации;
- российские операционные системы;
- новые экземпляры баз данных;
- сетевые сегменты;
- политики безопасности.
Затем между старой и новой инфраструктурами организовали сеть: проложили каналы передачи данных, настроили маршрутизацию и создали идентичные сетевые сегменты в исходной и целевой средах.
Если системы не смогут обнаружить друг друга, сервис формально запустится, но бизнес-процесс нарушится. Например, приложение потеряет доступ к базе данных, а сотрудники не смогут авторизоваться во внутренних системах.
Этап 4: разделение сервисов. После подготовки инфраструктуры команда разбила сервисы на две категории.
К статическим сервисам отнесли веб-серверы, сервер приложений и сетевые службы. К динамическим — базы данных, почтовые и файловые серверы.
Такое деление необходимо, так как сценарии миграции для этих групп различаются. Статические сервисы переносятся относительно быстро. Для динамических требуется более сложный подход: репликация, синхронизация данных, проверка целостности информации и т. д.
Этап 5: миграция прикладного ПО. Самым трудным этапом стал перенос прикладных систем, связанных с Microsoft-стеком. Для них подобрали версии, совместимые с российскими ОС. Таким образом, архитекторам удалось обойтись без изменения кода и корректировки бизнес-логики.
Специалисты развернули виртуальные машины, настроили серверы приложений на Astra Linux, перенесли конфигурацию систем и проверили совместимость с остальными сервисами.
Таким образом, организация обеспечила бесперебойную работу ключевых сервисов и успешно перешла на новую платформу без необходимости кардинально переписывать приложения.
Этап 6: миграция баз данных. На очередном этапе данные были перемещены из Microsoft SQL Server в PostgreSQL.
Специалисты перенесли свыше 30 ТБ информации, после чего выполнили нагрузочное тестирование с целевым значением около 150 запросов в секунду.
Испытания продемонстрировали, что новая система требует больше оперативной памяти по сравнению с предыдущей. После настройки конфигурации и оптимизации параметров PostgreSQL система вышла на нужный уровень производительности.
Отдельно была проведена оптимизация работы с запросами. В прежней среде короткие и ресурсоемкие операции выполнялись в одной очереди. Из-за этого один продолжительный запрос мог тормозить выполнение множества быстрых задач. К примеру, при формировании объемного аналитического отчета пользователи теряли возможность открыть карточку клиента.
После разделения потоков обработки и настройки параметров СУБД длинные и короткие запросы перестали соперничать за ресурсы. Система стала функционировать более стабильно, а пользователи больше не испытывали задержек при выполнении рутинных операций.
Этап 7: интеграционное тестирование. После завершения миграции была проверена работа всей инфраструктуры: взаимодействие между сервисами, аутентификация пользователей, передача данных, отказоустойчивость и поведение под нагрузкой.
Параллельно был подготовлен план возврата к исходной инфраструктуре на случай критических сбоев. Это обязательный шаг для крупных проектов.
Подготовка к миграции заняла около полугода. Перенос инфраструктуры — полтора месяца. Финальное переключение сервисов обошлось всего в два часа простоя.
В результате компания получила модернизированную инфраструктуру: на российском стеке, с высокой отказоустойчивостью и возможностью дальнейшего расширения.
Ошибки бизнеса при миграции в облако
Многие компании начинают проект миграции с одной и той же установки: «У нас есть ИТ-команда, значит, справимся сами». Формально это верно. Большинство задач по миграции можно решить собственными силами. Вопрос в том, сколько времени это займет и сколько ошибок будет допущено по пути.
Ниже разберем самые частые ошибки команд, которые впервые сталкиваются с миграцией.
Ошибка № 1. Недооценить сложность инфраструктуры. Типичная ситуация выглядит так: «У нас всего два десятка виртуальных машин. Ничего сложного». Но в процессе миграции внезапно выясняется, что инфраструктура содержит множество зависимостей, о которых не вспоминали годами.
В одном из проектов уже во время миграции обнаружилось, что клиент забыл о дополнительных каналах связи и нескольких внешних интеграциях. Команде «МегаФона» пришлось в срочном порядке перестраивать всю схему подключения.
Ошибка № 2. Не учитывать взаимосвязи между сервисами. Иногда к сбоям приводят не высокотехнологичные решения, а незначительные упущения. К примеру, одна организация при самостоятельном переходе изменила пул внешних IP-адресов, но не обновила DNS-записи. Сервисы были перемещены, и формально они даже функционировали, однако пользователи не могли установить с ними соединение.
Ещё одна типичная ситуация — конфликт IP-адресов. Когда двум виртуальным машинам присваивается один и тот же адрес, это может привести к одновременному отказу веб-сервисов, электронной почты и других критически важных систем.
Возьмём ещё один случай — корпоративную телефонию. После перехода в облако одна из компаний столкнулась с прерыванием звонков и задержками связи. Причина оказалась на удивление банальной: при планировании миграции не были учтены требования к каналу передачи данных между офисом и облачной средой. Как только пропускную способность канала увеличили, проблема исчезла.
Для опытного архитектора такие риски очевидны заранее. Но для неопытной команды они часто становятся неприятным сюрпризом.
Ошибка № 3. Недооценивать риски потери информации. Самый болезненный исход любой миграции — утрата данных. Причём зачастую проблема возникает не из-за отсутствия резервного копирования, а из-за ошибок в работе с ним.
Например, один из заказчиков самостоятельно настраивал репликацию виртуальных машин и случайно восстановил архивную копию поверх работающей системы. В итоге компания потеряла данные за несколько дней.
В другом случае сотрудник восстановил резервную копию не на тестовую среду, а на «боевую» виртуальную машину. Система фактически откатилась назад, и организация лишилась результатов работы за день. Среди утраченных данных оказались бухгалтерские документы и записи из «1С».
Поэтому профессиональные проекты миграции всегда включают сценарий возврата к предыдущей версии, тестирование резервных копий и контроль целостности информации.
Что нужно проверить перед началом миграции
Результат успешного перехода — это не просто переезд в облако, а создание более надёжной, безопасной и масштабируемой инфраструктуры, готовой к будущим изменениям бизнеса. Перед стартом проекта убедитесь, что:
- проведён аудит инфраструктуры — выявлены зависимости между сервисами, устаревшие компоненты и единые точки отказа;
- есть проект целевой архитектуры — компания не переносит старые проблемы в новую среду;
- продуманы сценарии восстановления — созданы резервные копии, протестирован план возврата и определены требования к отказоустойчивости;
- учтены бизнес-требования — допустимое время простоя, доступность критичных сервисов и планы дальнейшего развития;
- за проект отвечают специалисты с опытом подобных миграций — архитекторы, инженеры, эксперты по информационной безопасности и руководитель проекта.
Если вы задумываетесь о переходе в облачную среду, обсудите вашу задачу с экспертами «МегаФона».
■ Рекламаerid:2W5zFHkpSx1Рекламодатель: ПАО «МегаФон»ИНН/ОГРН: 7812014560/1027809169585Сайт: https://megafon.ru
