7 октября 2026 г.

Ааканша Дешмух (Aakansha Deshmukh)

Менеджер по развитию, Цифровой фундамент, HCLTech

7 октября 2026 г.

Основной текст

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

Почему важна оценка готовности к облаку

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

Срыв миграции и непредвиденные доработки
Проблемы с соблюдением нормативных требований
Неправильный расчет совокупной стоимости владения (TCO)
Стратегическое несоответствие

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

Ключевые компоненты оценки готовности к облаку

Тщательная оценка готовности к облаку охватывает семь различных областей. Каждая требует собственной методологии и дает собственный набор результатов для принятия решений о готовности (go/no-go). Рассмотрение их как единого контрольного списка, а не как независимых измерений оценки, — это то, где большинство оценок теряют точность.

Готовность инфраструктуры
Готовность приложений и рабочих нагрузок
Готовность данных
Безопасность, соответствие требованиям и риски
Организационная готовность и навыки
Экономический анализ и расчет TCO
Соответствие модели развертывания облака

Каждая из этих областей подробно рассматривается в следующих разделах. Эта структура не является последовательной: все семь областей должны быть оценены до принятия решений о последовательности миграции, поскольку результаты в одной области регулярно влияют на пороги готовности (go/no-go) в других.

Оценка существующей IT-инфраструктуры

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

Оценка готовности инфраструктуры охватывает шесть названных аспектов:

Инвентаризация и обнаружение
Вычислительная мощность
Сетевая архитектура
Системы хранения данных
Картирование зависимостей
Базовые показатели производительности

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

Оценка готовности приложений и рабочих нагрузок

Оценка приложений — это область, где принимаются наиболее судьбоносные решения go/no-go и где неверная классификация создает самые дорогостоящие сбои после миграции.

Схема классификации рабочих нагрузок

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

Облачные (Cloud-native): Безостаночные (stateless), контейнеризированные рабочие нагрузки или нагрузки на базе микросервисов без жестких зависимостей от инфраструктуры, предназначенные для работы в облачных средах без модификации. Они перемещаются с минимальным риском миграции.
Готовые к облаку (Cloud-ready): Рабочие нагрузки с сохранением состояния (stateful), которые могут работать в облачных средах без архитектурных изменений, при условии, что требования к задержке находятся в пределах допусков облачной сети, а ограничения гравитации данных не создают непомерных затрат на передачу. Они требуют проверки зависимостей перед миграцией, но не рефакторинга.
Требующие рефакторинга (Refactor-required): Рабочие нагрузки с монолитной архитектурой, жестко закодированными ссылками на инфраструктуру или профилями производительности, превышающими допуски облачной сети. Миграция возможна, но требует архитектурного исправления до момента переключения. Сроки исправления должны быть учтены в последовательности миграции — эти рабочие нагрузки не могут быть мигрированы по тому же графику, что и приложения, готовые к облаку.
Оставить локально (Retain on-prem): Рабочие нагрузки с требованиями к задержке менее 100 мс между компонентами, которые не могут быть размещены в облаке вместе, приложения, чувствительные к соблюдению требований, в юрисдикциях с мандатами на локализацию данных, которые не удовлетворяются ни одним доступным облачным регионом, или устаревшие системы с аппаратными зависимостями, не имеющими облачных эквивалентов. Это не «готовые к облаку с рефакторингом» системы, это кандидаты на сохранение локально. Оценка должна формулировать этот вывод явно, а не откладывать его.

Назначение паттерна миграции

Классификация определяет, какой паттерн миграции является подходящим. Это разные решения, и их не следует смешивать:

Простой перенос (Rehost): Перенос методом lift-and-shift в облачную инфраструктуру без изменений в приложениях. Подходит для рабочих нагрузок, готовых к облаку, где скорость миграции перевешивает возможности оптимизации.
Перенос с адаптацией (Replatform): Миграция в управляемый облачный сервис (например, переход с самозаправляемой базы данных на управляемый сервис баз данных) с минимальными изменениями в приложении. Подходит для готовых к облаку рабочих нагрузок, где снижение операционных расходов оправдывает умеренную сложность миграции.
Рефакторинг (Refactor): Переработка архитектуры приложения для развертывания в облачной среде. Подходит для рабочих нагрузок, требующих рефакторинга, где долгосрочная операционная выгода оправдывает инвестиции в устранение недостатков.
Вывод из эксплуатации (Retire): Списание рабочих нагрузок без активных пользователей или с избыточным функционалом. Оценка часто выявляет кандидатов на вывод из эксплуатации, которые не были видны в существующих портфелях приложений.
Сохранение (Retain): Оставить локально без миграции. Правильный паттерн для рабочих нагрузок, классифицированных как сохраняемые локально — это не временное состояние удержания, а осознанный результат оценки.

Оценка безопасности, соответствия требованиям и рисков

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

Организационная готовность и навыки

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

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

Анализ пробелов в навыках по категориям ролей, включая облачных архитекторов, DevOps-инженеров, специалистов по FinOps и специалистов по безопасности
Измерения готовности операционной модели: внедрение CI/CD, инфраструктура как код и облачные практики
Культурная готовность и управление изменениями: у организации должны быть мандат руководства, структуры кросс-функционального взаимодействия и потенциал управления изменениями для поддержания операционных сдвигов, требуемых при миграции в облако

Выбор правильной модели развертывания в облаке

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

Распространенные проблемы при оценке готовности к облаку

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

Неполное обнаружение
Неправильная классификация рабочих нагрузок
Непонимание разделения ответственности
Неверный расчет пробелов в навыках
Ошибки моделирования затрат

Лучшие практики оценки готовности к облаку

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

Контрольный список готовности к миграции

Готовность — это пороговая оценка, а не упражнение по завершению. Пункты ниже представляют собой пороговые утверждения типа «пройти/не пройти», организованные по областям оценки. Рабочая нагрузка или область, которая не может удовлетворить пороговое утверждение, не готова, и последовательность миграции должна отражать этот вывод.

Готовность инфраструктуры

Автоматизированное обнаружение (на базе агентов и безагентное) завершено для 100% инфраструктуры, входящей в область действия, без исключения активов из-за ограничений доступа.
Карты зависимостей составлены для всех рабочих нагрузок, входящих в область действия, с выявленными циклическими зависимостями и задокументированными планами их устранения.
Базовые показатели производительности (ЦП, память, дисковый ввод-вывод, пропускная способность сети) задокументированы как в условиях нормальной, так и пиковой нагрузки для всех рабочих нагрузок.
Проверка сетевой архитектуры завершена, профили задержки подтверждены для всех рабочих нагрузок с требованиями межкомпонентного взаимодействия.

Готовность приложений и рабочих нагрузок

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

Готовность к безопасности и соблюдению нормативных требований

Границы модели разделения ответственности сопоставлены для каждой целевой модели развертывания с задокументированными требованиями к элементам управления, управляемым клиентом.
Анализ пробелов в соблюдении нормативных требований завершен для всех применимых нормативных баз (GDPR, HIPAA, SOC 2, ISO 27001), а пробелы распределены между ответственными за их устранение.
Требования к размещению данных проверены в отношении доступных облачных регионов для всех регулируемых рабочих нагрузок, не осталось неразрешенных конфликтов размещения.
Устранение пробелов в управлении идентификацией, шифрованием и сегментацией сети завершено или имеет задокументированный график, предшествующий моменту перехода на миграцию.

Организационная готовность и готовность навыков

Анализ пробелов в навыках завершен по названным категориям ролей (облачные архитекторы, DevOps-инженеры, практики FinOps, специалисты по безопасности), а пробелы количественно оценены.
Оценены возможности конвейера CI/CD и инфраструктуры как кода, выявлены и устранены пробелы, влияющие на выполнение миграции.
План управления изменениями задокументирован, подтверждена поддержка со стороны руководства и создана кросс-функциональная структура команды.

Экономическая готовность и готовность к совокупной стоимости владения (TCO)

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

Соответствие модели развертывания

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

Как HCLTech помогает организациям оценивать готовность к облаку

Диагностическая оценка должна давать рекомендации по сохранению инфраструктуры на собственной площадке (retain-on-premises) и требования по устранению проблем до миграции, а не только дорожные карты миграции. Оценка, которая выдает исключительно зеленый свет, — это не диагностика, а квалификационный этап продаж.

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

Наша услуга по оценке готовности к облаку включает в себя:

Методология оценки: Структурированная методология оценки из семи областей, последовательно применяемая ко всему портфелю рабочих нагрузок в рамках проекта, с документированными критериями классификации и пороговыми значениями «можно/нельзя» для каждой области.
Инструменты автоматизированного обнаружения: Сканирование на основе агентов и без использования агентов, развернутое на всей инфраструктуре в рамках проекта для создания карт зависимостей, базовых показателей производительности и описей конфигураций.
Классификация рабочих нагрузок и назначение паттернов миграции: Классификация для каждой рабочей нагрузки (облачно-нативная, готовая к облаку, требующая рефакторинга, с сохранением на собственной площадке) с назначением паттернов миграции и задокументированными требованиями по устранению проблем для рабочих нагрузок, требующих рефакторинга.
Анализ пробелов в соответствии требованиям: Анализ пробелов применительно к конкретным нормативным требованиям, с сопоставлением пробелов в средствах контроля с ответственными за их устранение лицами и графиками.
Модель совокупной стоимости владения (TCO): Полная финансовая модель, охватывающая текущие, миграционные и прогнозируемые операционные расходы на облако, рассмотренная с финансовыми заинтересованными сторонами.
Результаты оценки: Оценки готовности по доменам и рабочим нагрузкам, список задач по устранению проблем с приоритезацией, список компонентов для сохранения на собственной площадке с обоснованием и рекомендации по последовательности миграции, отражающие результаты оценки.

Часто задаваемые вопросы об оценке готовности к облаку

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

В чем разница между оценкой готовности к облаку и оценкой зрелости облака?

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

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

Сколько времени занимает оценка готовности к облаку и что она дает?

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

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

Каковы риски отказа от оценки готовности к облаку?

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

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

Можно ли мигрировать в облако все рабочие нагрузки?

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

Об авторе

Ааканша Дешмух

Заместитель менеджера по цифровым фундаментам, HCLTech

Описание

Она руководит маркетингом гибридных облаков в HCLTech, объединяя дизайн-мышление и бизнес-стратегию для создания материалов об искусственном интеллекте, генеративном ИИ, облаках и цифровой трансформации в масштабе предприятия, основанных на глубоком анализе.

Облака и экосистема Библиотека знаний по облакам Оценка готовности к облаку: руководство по трансформации предприятия