РТК-ЦОД реализовал миграцию ключевых ИТ-систем группы компаний «Локотех» в облако

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

Облако как инфраструктурный проект, а не разовая замена серверов

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

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

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

Что проверить до запуска похожего сценария

Опыт «Локотеха» полезен как повод выстроить собственный порядок действий. На первом этапе руководителю стоит разделить приложения по критичности и зависимости от других систем. Переносить все одновременно рискованно: даже технически готовая система может оказаться связана с процессами, документацией или доступами, которые не были учтены в первоначальном плане.

Далее необходимо заранее определить критерии приемки:

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

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

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

Как не потерять управляемость после переноса

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

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

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