Глобальные предприятия планируют потратить более триллиона долларов на публичные облачные сервисы в 2026 году. Экономическое обоснование этих расходов основано на прогнозах, варьирующихся от убедительных до экстраординарных: исследование IDC показывает 334% рентабельности инвестиций за три года и десятимесячный срок окупаемости для организаций, эффективно осуществляющих модернизацию. Бенчмарки AWS указывают на 43% рост выручки и 33% сокращение ИТ-затрат для полностью модернизированных рабочих нагрузок. Цифры реальны. Они представляют собой достижимые результаты. Проблема в том, что большинство организаций их не достигают.
Данные PwC показывают, что 54% предприятий сообщают о минимальной отдаче от инвестиций в облачные технологии, несмотря на растущее их внедрение. Flexera обнаружила, что 84% организаций считают прозрачность затрат одним из главных приоритетов, однако только 38% активно отслеживают рентабельность инвестиций в облачные технологии в различных бизнес-подразделениях. Gartner сообщает, что бюджеты на облачные технологии в среднем превышают прогнозы на 17%. Разрыв между тем, что обещает модернизация облачных технологий, и тем, что организации получают на самом деле, — это не технологический сбой. Это сбой в обеспечении прозрачности, и он начинается задолго до перемещения первой рабочей нагрузки.
Сначала определитесь, что именно вы перевозите.
SMART TS XL Перед началом миграции составляет карту всех зависимостей, неиспользуемых компонентов и структурных рисков.
ПодробнееНеприятная правда о провале модернизации облачных технологий
Организации тратят миллиарды на миграцию в облако, но многие не получают обещанной окупаемости инвестиций. Перенос рабочих нагрузок в облако без решения проблем с оперативной прозрачностью, непомерными затратами и разрозненными инструментами лишь усугубляет ситуацию. Стоит задуматься над фразой «усугубляет проблему». Миграция в облако не нейтрализует технический долг, технический долг не исчезает в облаке; он масштабируется.
Схема неудач одинакова во всех отраслях. Команды внедряют Kubernetes и сервисно-ориентированную архитектуру, не имея при этом необходимых средств мониторинга, зрелости CI/CD или согласованности действий команды для их поддержки. Результат: распределенный монолит со сложной операционной структурой, но без всех преимуществ. Организация, которая мигрирует устаревший монолит, не понимая его внутренней структуры, зависимостей и потоков данных, не получает гибкости облачных вычислений. Она получает дополнительные расходы на облачные услуги наряду с теми же архитектурными проблемами, от которых пыталась избавиться.
Самый важный вывод из неудачных программ заключается в том, что неудачи в основном носят организационный, а не технический характер. Технология работает. Организационные структуры, стимулы и процессы принятия решений часто не работают. Неясная ответственность, неправильные KPI и команды, не обладающие полномочиями или навыками для выполнения задач, — вот причины неудач, которые выявляются при анализе результатов. Но за каждой организационной неудачей стоит информационная ошибка: миграция была спланирована без точного понимания того, что именно мигрируется.
Что на самом деле представляет собой пробел в наблюдаемости
В контексте облачных вычислений наблюдаемость означает способность понимать внутреннее состояние системы на основе ее внешних выходных данных, отвечать на вопросы «что происходит и почему» на основе телеметрических данных. Наблюдаемость отличается от мониторинга. Мониторинг оповещает о доступности сервиса. Наблюдаемость же предоставляет информацию о причине сбоя, о первом вышестоящем сервисе и о цепочке зависимостей между отказавшими сервисами в момент сбоя.
Проблема отсутствия мониторинга в программах модернизации облачных вычислений заключается не столько в телеметрии, метриках, журналах и трассировках во время выполнения после развертывания приложения, сколько в более ранней и более значимой проблеме: отсутствии структурной видимости приложения до начала миграции.
Этот ранее существовавший пробел в наблюдаемости имеет три аспекта:
Что на самом деле содержит приложение. Документация описывает, для чего была разработана система. Фактический код отражает пятнадцать лет изменений, обходных путей и недокументированных решений, которые не отражены ни на одной архитектурной схеме. План миграции, построенный на документации, — это план миграции, построенный на неполной карте.
Как компоненты взаимодействуют друг с другом. Зависимости между модулями, сервисами и системами определяют последовательность миграции, риски и истинный масштаб любых предлагаемых изменений. Организации, которые определяют возможности облачных технологий посредством разрозненных инициатив, а не трансформации всего портфеля, видят, как любые выгоды от новых развертываний нивелируются текущими затратами на эксплуатацию неизмененных систем. Разрозненная оценка приводит к разрозненному пониманию, а миграции выявляют межкомпонентные зависимости в процессе выполнения, когда обнаружение наиболее затратно.
На что именно повлияет миграция. Без модели структурной зависимости оценка воздействия сводится к приблизительной оценке. Оценка воздействия приводит к планам миграции с неизвестным масштабом. Неизвестный масштаб — это то, где прогнозы рентабельности инвестиций в облачные технологии обречены на провал.
Где образуется разрыв: до, во время и после миграции
До миграции: Иллюзия оценки
Большинство программ миграции в облако начинаются с этапа оценки. Первые 90 дней посвящены оценке: инвентаризации данных, оценке готовности к внедрению ИИ, определению базового уровня FinOps и анализу пробелов в управлении. Звучит систематично. На практике же оценка почти всегда поверхностна и касается кода приложения.
Инструменты обнаружения инфраструктуры проводят инвентаризацию серверов. Инструменты сканирования портфеля языков программирования выдают оценки сложности. Однако фактический структурный анализ кода приложений — какие функции существуют, как они вызывают друг друга, какие компоненты обмениваются данными через файлы или базы данных, а не через явные API, какой код является устаревшим и может быть полностью исключен из области исследования — проводится редко, поскольку инструменты для его выполнения в рамках корпоративных портфелей языков программирования не входят в стандартный набор инструментов поставщика решений для миграции.
Отсутствие мониторинга с самого начала. Панели мониторинга состояния конвейера, качества данных и затрат, добавленные после запуска, обошлись в три раза дороже, чем их внедрение изначально. Тот же принцип применим и к структурному мониторингу портфеля приложений: стоимость обнаружения архитектурной сложности после начала миграции в несколько раз превышает стоимость ее обнаружения до начала миграции.
В процессе миграции: проблема обнаружения зависимостей
Самый дорогостоящий момент в программе миграции в облако — это когда в процессе выполнения обнаруживается неизвестная до миграции зависимость. Команда установила сроки. Инфраструктура подготовлена. Договоры с поставщиками услуг миграции заключены. И тут внезапно всплывает незапланированная сложность, связанная с общим COBOL-кодом, используемым в 300 программах, или общей схемой базы данных, из которой читают 12 сервисов, или пакетным заданием, которое передает данные шести конечным потребителям через файловый интерфейс.
Без унифицированной системы мониторинга и интеллектуальной автоматизации модернизация облачных вычислений часто переносит эти проблемы в более сложную распределенную среду, вместо того чтобы их решать. Монолитная система распадается на микросервисы. Неявные зависимости между ее компонентами превращаются в сетевые вызовы между распределенными сервисами. Проблема мониторинга не устраняется, она становится распределенной, что затрудняет ее выявление.
После миграции: обвал прозрачности затрат
84% организаций называют управление расходами на облачные технологии своей главной проблемой, при этом бюджеты превышают прогнозы на 17%. Между тем, 69% ИТ-руководителей сообщают о перерасходе средств на облачные технологии.
Перерасход средств на облачные сервисы напрямую связан с пробелом в мониторинге до миграции. Рабочие нагрузки, которые оценивались как простые кандидаты для переноса, в итоге потребовали рефакторинга. Приложения, которые считались небольшими, приводят к большим затратам на передачу данных, поскольку никто не сопоставил их восходящие и нисходящие потоки данных во время оценки. «Мертвый» код, перенесенный вместе с рабочим кодом, работает в контейнерах, оплата за которые производится по миллисекундам. Измерение времени безотказной работы системы вместо бизнес-результатов приводит к тому, что команды оптимизируют систему для получения неверных результатов.
Компания Flexera сообщает, что только 38% активно отслеживают рентабельность инвестиций в облачные технологии в различных бизнес-подразделениях. Организации не могут отслеживать рентабельность инвестиций, которую они не могут измерить, и они не могут измерить рентабельность инвестиций относительно базового уровня, который они не смогли точно установить до начала миграции.
Структурная наблюдаемость, необходимая для миграционных программ.
Для устранения пробела в наблюдаемости требуется анализ иного рода, чем тот, который обеспечивает обнаружение инфраструктуры. Он включает в себя разбор исходного кода каждого приложения, включенного в область миграции, и построение структурной модели, которая представляет собой:
Полная инвентаризация. Каждая программа, функция, модуль, копибук, схема, поток заданий и процедура, включая те, которые не описаны в документации, что в крупных корпоративных средах часто составляет 20–30% от фактического количества.
Сопоставление зависимостей между языками программирования. Как Java-сервис подключается к программе на COBOL, которая считывает данные из таблицы DB2, заполняемой пакетным заданием JCL. Зависимости, пересекающие языковые границы, — это те, которые не видны инструментам инфраструктуры и которые приводят к наиболее дорогостоящим неожиданностям при миграции.
Идентификация мертвого кода. Компоненты, не имеющие входящих ссылок ни на один из путей выполнения в производственной среде, могут быть полностью исключены из области миграции. Модернизация устаревших систем в 2026 году требует перехода от жестких, монолитных систем к современным, гибким и масштабируемым архитектурам, но миграция мертвого кода в облако приводит к дополнительным расходам на облачную инфраструктуру, которая не служит никакой производственной цели.
Классификация по сложности. Компоненты высокой сложности и высокой степени взаимосвязи являются наиболее дорогостоящими для миграции и с наибольшей вероятностью приводят к перерасходу средств. Выявление таких компонентов на этапе оценки, а не обнаружение их в процессе выполнения, отличает бюджет миграции с достаточным резервом средств от бюджета, основанного на оптимистичных предположениях.
Область влияния любого предлагаемого изменения. Прежде чем какой-либо компонент будет изменен, переработан или перемещен, структурная модель отвечает на вопрос: на что еще это повлияет? Этот ответ преобразует неизвестный риск в структурированный, перечислимый список компонентов, требующих проверки.
Почему разрыв в возможностях мониторинга больше в устаревших и мэйнфреймовых системах
Облачные среды, развивающиеся за счет быстрой, неконтролируемой миграции, накапливают риски из-за разрывов между инструментами, командами и ответственностью. Для организаций, мигрирующих современные портфели веб-приложений, этот разрыв имеет существенное значение. Для организаций, мигрирующих рабочие нагрузки мэйнфреймов, COBOL, JCL, PL/I, RPG, он часто оказывается решающим.
Приложения для мэйнфреймов накапливают сложность, которую не может выявить ни одно сканирование инфраструктуры. Бизнес-логика, встроенная в COBOL-коды, которые модифицировались десятками разработчиков за тридцать лет. Потоки заданий JCL с условными путями выполнения, которые запускаются только при определенных бизнес-условиях. Книги копирования (Copybooks), включаемые сотнями программ одновременно, где переименование одного поля влияет на каждую программу в цепочке. Наборы данных, которые служат неявными контрактами данных между программами, которые никогда явно не вызывают друг друга.
Перенос кода на новую платформу является основной причиной большинства неудач при модернизации. Перенос на другую платформу без изменения архитектуры лишь переносит технический долг. Это особенно актуально для рабочих нагрузок на мэйнфреймах. Преобразование программы на COBOL в Java без понимания её внутренней структуры, зависимостей и потоков данных приводит к созданию кода на Java с теми же структурными проблемами, что и в COBOL, но теперь работающего на облачной инфраструктуре, оплата за которую производится непрерывно.
Для устранения этого пробела в системах на мэйнфреймах и многоязычных системах требуется структурная наблюдаемость, включающая инструменты, способные одновременно понимать все языки среды и отслеживать зависимости между ними, создающие наиболее опасные «слепые зоны».
Связь с FinOps: вы не можете управлять тем, чего не видите.
FinOps — это дисциплина финансового управления, которая устанавливает ответственность за расходы на облачные ресурсы на уровне команды и рабочей нагрузки, заменяя непрозрачную систему выставления счетов детальным, действенным управлением затратами. Любая структура FinOps, будь то управление тегами, анализ и распределение затрат, оптимизация зарезервированных мощностей, зависит от понимания того, что вы используете и сколько это стоит.
Организации, терпящие неудачу в FinOps, — это те, которые не создали структурный реестр до миграции. Они не могут точно маркировать ресурсы, потому что не знают, к какой рабочей нагрузке относится тот или иной ресурс. Они не могут определить ответственность за затраты, потому что право собственности на мигрированные компоненты никогда не было определено в соответствии с фактической структурой компонентов. Они не могут оптимизировать зарезервированные мощности, потому что не знают, какие рабочие нагрузки являются стабильными, а какие — переменными, что требует понимания функции рабочей нагрузки, а не только ее потребления ресурсов.
Недостающим звеном является стратегия, которая связывает бюджетирование, мониторинг и мероприятия по миграции в облако с важными результатами, такими как рост бизнеса, пользовательский опыт и время выхода на рынок. Эта связь невозможна без структурной основы: точной модели того, что содержит портфель приложений, до составления плана миграции.
Как SMART TS XL Устраняет пробел в наблюдаемости, существовавший до миграции.
SMART TS XL Предоставляет уровень структурной наблюдаемости, необходимый для оценки миграции в облако, но недоступный для инструментов обнаружения инфраструктуры. Анализируя исходный код каждого приложения в портфеле, включая COBOL, JCL, Java, Python, RPG, PL/I, SQL и современные языки, он создает единую модель зависимостей, которая делает невидимое видимым до начала миграции.
Анализ модернизации устаревших систем начинается с полной инвентаризации: каждой программы, книги копирования, схемы и потока заданий в среде, включая компоненты, которые не были учтены в документации. Это и есть фактический объем миграции, определяемый на основе кода, а не на основе оценок.
Карта зависимостей приложения отслеживает все межкомпонентные связи, преодолевая языковые барьеры, от Java-сервиса, вызывающего COBOL-программу, считывающую данные из таблицы DB2, заполняемой пакетным заданием JCL. Этот граф межъязыковых зависимостей является основой для последовательности этапов миграции: компоненты, не имеющие зависимостей от вышестоящих платформ, мигрируют первыми; компоненты, от которых зависят многие другие, мигрируют последними, после того, как их зависимые компоненты будут готовы.
Функция анализа влияния преобразует граф зависимостей в действенный план миграции: прежде чем перемещать или рефакторизировать какой-либо компонент, необходимо перечислить все остальные компоненты, которые будут затронуты, определить объем работ по проверке и выявить компоненты, несущие наибольший риск миграции. Это превращает подход «мы разберемся в процессе выполнения» в структурированную, основанную на фактических данных программу с определенным объемом работ на каждом этапе.
Функция корпоративного поиска позволяет запрашивать полную структурную модель на протяжении всей программы миграции: за считанные секунды можно найти каждое использование конкретной функции, каждую программу, считывающую данные из определенного набора данных, каждый компонент, на который повлияет изменение схемы, в миллионах строк кода на любых языках программирования. Именно эта функция поиска обеспечивает полезность структурной модели на протяжении многолетней программы миграции, предотвращая ее превращение в одноразовый оценочный артефакт, который со временем устаревает.
Как сократить дефицит бюджета до его утверждения
Наиболее эффективными в этой среде являются не обязательно те, у кого самые большие бюджеты на модернизацию. Это те, кто может так же точно, как и оценить стоимость бездействия, оценить стоимость действий. Та же точность применима и к проблеме отсутствия мониторинга. Вопрос не в том, стоит ли структурный анализ перед миграцией времени и денег. Стоит. Вопрос в том, меньше ли эта стоимость, чем стоимость выявления структурной сложности в процессе миграции, которая неизменно оказывается ниже в каждой организации, проводившей этот эксперимент.
Предприятия, которые определят будущее следующего десятилетия, — это не те, кто внедрил больше всего технологий. Это те, кто понимал, что на самом деле делают их технологии. Вопрос о рентабельности инвестиций в облачную модернизацию — это не столько вопрос облачных технологий, сколько вопрос знаний. Знаете ли вы, что включает в себя ваш портфель приложений? Знаете ли вы, как связаны его компоненты? Знаете ли вы, как изменение любого компонента повлияет на ситуацию? Организации, которые могут ответить на эти вопросы до начала миграции, — это те, чьи программы облачной модернизации обеспечивают ожидаемую рентабельность инвестиций, предусмотренную бизнес-планом. Остальные обнаруживают разрыв в своих затратах на облачные услуги.
