20 Июля 2026 10:00 20 Июл 2026 10:00 |

Поделиться

Как мигрировать в облако без простоев и лишних затрат

Почему бизнес переходит в облака

Еще несколько лет назад компании часто рассматривали облако как резервную площадку: туда выносили тестовые среды или отдельные сервисы. Сейчас переход на отечественные платформы стал плановым инженерным проектом.

Бизнес идет в облака по нескольким причинам. Железо дорожает, закупать оборудование «с запасом на пять лет» становится все менее рационально. Требования к надежности, безопасности и соответствию законодательству усложняются. А ИТ-инфраструктура должна быстрее адаптироваться к задачам бизнеса.

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

Теперь бизнес платит только за то, что использует, и может быстро масштабировать инфраструктуру при изменении нагрузки.

Меняется и роль ИТ-команды. Если раньше ИТ-директор отвечал за все — от закупки оборудования до обеспечения безопасности, — то при миграции в облако часть таких задач на себя берет провайдер. Для бизнеса это переход от управления инфраструктурой к управлению качеством сервиса: контролю 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С».

Потому профессиональные проекты миграции всегда предусматривают сценарий возврата к предыдущей версии, тестирование резервных копий и контроль целостности данных.

Что проверить до начала миграции

Результат успешной миграции — не переезд в облако, а более надежная, безопасная и масштабируемая инфраструктура, готовая к будущим изменениям бизнеса. Перед стартом проекта убедитесь, что:

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

Если вы планируете миграцию в облако, обсудите свой проект со специалистами «МегаФона».

Поделиться

Подписаться на новости Короткая ссылка