Миграция на мэйнфреймы терпит неудачу по предсказуемой причине. Не потому, что целевая облачная архитектура неправильна. Не потому, что инструменты преобразования COBOL в Java недостаточны. Не потому, что у команды нет намерений или бюджета. Они терпят неудачу, потому что команда начинает переносить данные, не зная, что это за данные, не зная, на основе каких доказательств, а не предположений, что делает каждая программа, какие программы зависят от других, как данные проходят через систему и что сломается при изменении. Режим отказа почти всегда один и тот же: зависимость, обнаруженная в середине миграции, о существовании которой никто не знал, бизнес-правило, скрытое в шаблоне, используемом 400 программами, пакетное задание, которое передает данные в двенадцать нижестоящих систем через файл, который никто не подумал задокументировать.
Процесс миграции на мэйнфрейм требует тщательного планирования и выполнения для минимизации рисков и обеспечения непрерывности бизнеса. Это утверждение верно, но неполно. Важно не столько составление дорожной карты, выбор поставщика или поэтапный график, сколько структурный анализ, который проводится до принятия каких-либо из этих решений. Именно этот анализ показывает, что система фактически содержит и как она работает, в отличие от того, что указано в документации и как она изначально была спроектирована. В каждой крупной среде мэйнфреймов эти два описания расходятся, часто на величину, определяющую успех миграции или ее задержку.
Составьте карту всего вашего мэйнфрейма.
SMART TS XL Анализирует каждую программу COBOL, задание JCL, копибук и схему SQL в вашей среде мэйнфрейма.
Узнать большеПочему миграция на мэйнфреймы терпит неудачу: пробел в анализе
Миграция на мейнфреймы терпит неудачу не из-за устарелости кода, а потому что никто толком не знает, что он делает, пока не становится слишком поздно. Скрытая логика. Недокументированные крайние случаи. Забытые процессы. Это не теоретические риски, а практические препятствия, которые тормозят проекты, вызывают проблемы в производственной среде и незаметно подрывают доверие к плану миграции.
Пробел в анализе имеет специфическую структуру. Организации, которые использовали мэйнфрейм-системы в течение двадцати или тридцати лет, накопили изменения, которые никогда не отражались в документации, зависимости, сформировавшиеся органически, поскольку программы были связаны через общие файлы, а не через явные интерфейсы, и бизнес-логику, которая существует только в умах разработчиков, которые уже вышли на пенсию. Команды, обрабатывающие данные мэйнфрейма как стандартные файлы, обнаруживают неприятные сюрпризы во время миграции, когда понимают, что «данные» включают в себя десятилетия бизнес-логики, разбросанной по условным операторам и именам условий 88-го уровня.
Существует четыре конкретных пробела в знаниях, которые срывают миграцию. Для каждого из них существует метод анализа, позволяющий его устранить. Ни один из них нельзя устранить только путем изучения документации или интервью с разработчиками.
Проблема 1: Неизвестный список программ. Организации часто обнаруживают, что фактическое количество программ значительно превышает задокументированное. Программы, написанные для конкретных бизнес-задач, тестовые программы, ставшие производственными, служебные программы, о создании которых никто не помнит, — все они находятся в библиотеке загрузки и могут быть вызваны заданиями JCL, которые фигурируют в производственных графиках.
Проблема 2: Недокументированные зависимости. Мейнфреймы передают данные десяткам систем через сложные сети промежуточного программного обеспечения, такого как WebSphere, CICS Transaction Gateway, Enterprise Service Bus, а также общие утилиты, планировщики и бизнес-процессы. Ошибка заключается в том, что слишком долго откладывается составление карты всех этих связей, особенно потоков данных и моделей их потребления.
Пробел 3: Встроенная бизнес-логика. В программах COBOL бизнес-правила накапливаются на протяжении десятилетий. Вычисление, которое было простым в 1985 году, с тех пор было изменено двенадцатью разработчиками, каждый из которых добавил условную логику, отражающую изменение бизнес-правила, которое нигде больше не было задокументировано. Перенос программы без понимания логики приводит к созданию мигрированной системы, которая вычисляет результаты, отличные от исходных, — правильно с точки зрения кода, но неправильно с точки зрения бизнеса.
Проблема 4: Связность формата данных и схемы. Программы, которые обмениваются данными через файлы, а не через API, связаны контрактами формата данных, которые существуют только в их операторах FD и COPY. Изменение структуры записи в общем файле приводит к сбою во всех программах, которые его читают, включая программы, находящиеся в процессе миграции, и программы, которые останутся на мейнфрейме, что создает скрытый сбой интеграции.
Восемь анализов, которые должны быть проведены перед миграцией
Следующие анализы следует провести до принятия окончательного решения о миграции и до внесения каких-либо изменений в код. Это не предварительные шаги, которые нужно быстро выполнить, а основа, на которой зиждется каждое последующее решение.
1. Заполните инвентаризацию программы.
Первый этап анализа — это перепись: какие программы, потоки заданий, книги правил, процедуры и определения данных фактически существуют в среде. Это не обзор документации. Это анализ фактических библиотек загрузки, исходных библиотек и библиотек процедур для создания авторитетного перечня.
Инвентаризация должна включать: каждую исходную программу с указанием языка и приблизительного размера; каждую книгу правил (copybook) и программы, которые ее включают; каждую каталогизированную процедуру и задания, которые ее вызывают; каждый набор данных, который встречается в операторах DD, и программы, которые его создают или используют; каждую таблицу, представление и хранимую процедуру DB2, на которые ссылается встроенный SQL.
В большинстве крупных мэйнфреймовых сред этот перечень выявляет программы, которые были неизвестны команде планирования миграции, иногда с погрешностью в 20-30% от общего количества. Планы миграции, разработанные на основе неполных перечней, приводят к перерасходу средств, когда недостающие программы обнаруживаются в середине проекта.
2. Отображение зависимостей во всех языках программирования
После составления инвентаризации, карта зависимостей отслеживает, как каждый компонент связан с каждым другим компонентом. Карта зависимостей является наиболее важным этапом анализа перед миграцией, поскольку она определяет масштабы каждого последующего изменения.
Полная карта зависимостей включает в себя:
- Звонки между программами: Вызовы, выполнение, связь, прикрепление и динамические вызовы, разрешающиеся во время выполнения.
- Вызовы JCL для программ: каждое оператор EXEC PGM= в каждом потоке заданий JCL, включая вызовы PROC с подстановкой символических параметров, разрешено.
- Цепочки включения копибукаКакие программы включают какие книги копирования, в том числе вложенные книги копирования, включенные другими книгами копирования?
- Взаимоотношения производитель-потребитель в наборе данных: какие программы записывают данные в какие наборы данных, какие программы считывают данные из этих наборов данных, и какие зависимости в цепочке последовательных заданий это создает.
- Ссылки на схемы DB2: какие программы читают или записывают данные в какие таблицы, какие таблицы используют общую схему с какими другими таблицами
В результате получается ориентированный граф. Любое предлагаемое изменение любого узла в этом графе может быть проанализировано с точки зрения его влияния путем обхода ребер для перечисления всех остальных узлов, зависящих от него. Без этого графа анализ влияния — это всего лишь догадки.
Прежде чем вносить какие-либо изменения в код, крайне важно обеспечить полную прозрачность. Опора на устаревшую документацию — роковая ошибка; автоматизированные инструменты должны автоматически определять текущее состояние, сканируя JCL, COBOL и PL/I, отображая все приложения, потоки данных, зависимости и скрытые задачи.
3. Извлечение и документирование бизнес-логики
Программы на COBOL содержат бизнес-логику, которой нет больше нигде в организации. Это наиболее часто игнорируемый аспект анализа при планировании миграции, и именно он приводит к наиболее дорогостоящим сбоям после миграции.
Извлечение бизнес-логики позволяет получить документацию, содержащую: правила принятия решений, закодированные в структурах IF/THEN/ELSE и EVALUATE; формулы вычислений в операторах COMPUTE; правила проверки данных в разделах PROCEDURE DIVISION; пути обработки ошибок и их бизнес-значение; а также логику, зависящую от последовательности, где порядок операций имеет значение для корректности результата.
Этот анализ не требует ручного прочтения каждой строки каждой программы. Инструменты статического анализа, понимающие COBOL, могут идентифицировать структуры принятия решений, извлекать условную логику и создавать структурированную документацию правил, которые они кодируют. Этот результат служит двум целям: он предоставляет команде миграции спецификацию, необходимую для проверки корректности результатов миграции системы, и дает бизнесу первую систематическую документацию бизнес-правил, которые десятилетиями могли существовать только в коде.
4. Идентификация мертвого кода
Не всё в мейнфрейме нужно переносить. Программы, которые никогда не вызываются ни одним потоком заданий, абзацы, которые никогда не выполняются ни одним путем вызова, элементы копибука, на которые никогда не ссылаются, — всё это представляет собой усилия по миграции, не приносящие никакой пользы бизнесу.
Идентификация мертвого кода анализирует граф зависимостей для обнаружения компонентов, не имеющих входящих ссылок ни в одном потоке производственных заданий. Эти компоненты могут быть исключены из области миграции, что снижает затраты без ущерба для функциональности. В крупных устаревших средах мертвый код обычно составляет 10-25% от общего объема кода, что представляет собой значительное сокращение объема работ при систематическом выявлении, а не при случайном обнаружении.
Анализ должен различать действительно мертвый код (недоступный ни по одному пути выполнения в производственной среде) и редко выполняемый код (доступный, но редко запускаемый). Редко выполняемый код, такой как процедуры обработки данных в конце года, программы подготовки нормативной отчетности или процедуры аварийного восстановления, может быть критически важным, несмотря на нечастое выполнение. Исключение его из миграции приводит к созданию системы, которая работает корректно в 99% случаев и выходит из строя именно тогда, когда это наиболее необходимо.
5. Классификация сложности и риска
После составления перечня программ и карты зависимостей каждую программу можно классифицировать по сложности и риску миграции. Классификация определяет последовательность миграции: программы с низкой сложностью и низкой степенью зависимости мигрируются первыми; программы с высокой сложностью и высокой степенью зависимости мигрируются последними, с наиболее полным охватом тестирования.
Метрики сложности для оценки риска миграции на COBOL:
| Коэффициент сложности | Что измерять | Высокий порог риска |
|---|---|---|
| Цикломатическая сложность | Количество ветвей принятия решений на программу | Более 50 человек на программу |
| Количество зависимостей копибука | Количество включенных тетрадей | Более 20 копировальных книг |
| Вызвано по количеству | Количество программ, которые вызывают эту программу | Более 15 звонков |
| Ссылки на наборы данных | Количество прочитанных или записанных наборов данных | Более 30 наборов данных |
| Встроенный SQL | Количество SQL-запросов | Более 100 утверждений |
| Вызовы EXEC CICS | Взаимосвязь между серверами транзакций | Любая зависимость CICS |
| Динамические вызовы | Вызовы обрабатываются во время выполнения. | Любой динамический вызов |
| Вызовы ассемблера | Встроенная логика, не использующая COBOL | Любой вызов ассемблера |
Программы, получившие высокие оценки по нескольким факторам, представляют собой компоненты миграции с самым высоким риском. Они требуют наиболее тщательного анализа, самых опытных инженеров по миграции и наиболее полного охвата тестирования.
6. Анализ зависимости между окном пакетной обработки и планированием.
Пакетные задания на мэйнфрейме выполняются в запланированные временные окна со сложными цепочками зависимостей: задание B не может начаться, пока задание A не завершится успешно; задание C выполняется только в последний рабочий день месяца; задание D имеет ограничение по максимальному времени выполнения, которое влияет на время запуска задания E. Эти зависимости планирования являются частью операционного поведения системы и должны быть воспроизведены в целевой среде.
Документы анализа пакетной обработки данных содержат: полную цепочку выполнения для каждого запуска производственной партии; временные ограничения на каждом шаге; логику условного выполнения (что происходит, когда шаг завершается с ошибкой или выдает ненулевой код возврата); наборы данных, передаваемые между шагами; а также внешние триггеры и уведомления, генерируемые пакетной системой.
В облачных средах это выражается в следующем: эквивалентная конфигурация конвейера CI/CD или оркестрации рабочих процессов; настройка обработки ошибок и оповещений; настройка мониторинга и SLA; и интеграция с нижестоящими системами, получающими пакетные выходные данные.
7. Оценка качества и формата данных
Устаревшие системы часто содержат тысячи строк кода, написанного на COBOL, PL/I или ассемблере, большая часть которого может быть плохо документирована или тесно связана между собой. Используйте инструменты статического анализа для выявления технического долга, избыточного кода и модулей, которые можно разделить на модули или вывести из эксплуатации.
Оценка качества данных проверяет фактические данные в производственных наборах данных на соответствие определениям формата в определении дескриптора файла COBOL и определениям копибука. Расхождения встречаются часто: упакованные десятичные поля, содержащие недопустимые битовые шаблоны для определенных типов записей, поля переменной длины, где индикатор длины выходит за пределы допустимого диапазона для подмножества записей, символьные поля EBCDIC, содержащие неотображаемые значения в определенных позициях.
Эти несоответствия необходимо выявлять и устранять до миграции, а не обнаруживать во время тестирования миграции. Миграция данных, в ходе которой перемещается 500 миллионов записей, а затем обнаруживается, что 0.1% из них имеют недопустимые форматы, указывает на дефект, влияющий на производственный процесс, который присутствовал в исходных данных и был неизвестен до этапа проверки.
8. Интеграция и отображение внешних систем
Необходимо отслеживать происхождение данных в каждой системе, использующей данные с мэйнфрейма, от инструментов отчетности до интеграций с партнерами, поскольку проекты модернизации не могут быть запущены в эксплуатацию, если на поздних этапах разработки команды обнаружат, что сохранение этих потоков данных было необходимым, но незапланированным.
Интеграционная карта определяет все системы за пределами мэйнфрейма, которые получают от него данные или отправляют данные в него: нижестоящие приложения, которые обрабатывают пакетные выходные данные посредством передачи файлов; интерфейсы реального времени через MQ, CICS или вызовы API; партнерские интеграции, которые используют определенные форматы файлов и графики передачи; системы отчетности, которые напрямую запрашивают таблицы DB2; и потоки данных из хранилищ данных, которые принимают преобразованные данные с мэйнфрейма.
Каждая точка интеграции представляет собой потенциальный риск перехода: мигрированная система, которая генерирует данные в формате, не ожидаемом нижестоящей системой, может привести к скрытому сбою, который может остаться незамеченным до тех пор, пока нижестоящий потребитель не сообщит об аномалии. Составление карты интеграции — это анализ, который делает планирование перехода всесторонним, а не оптимистичным.
Выбор стратегии миграции на основе результатов анализа.
Предварительный анализ миграции не только снижает риски, но и определяет, какая стратегия миграции подходит для каждого компонента. Команды мигрируют рабочие нагрузки мэйнфреймов по-разному, в зависимости от того, насколько масштабные изменения они могут контролировать. Результаты анализа напрямую влияют на это решение.
| Результаты анализа | Рекомендуемая стратегия | обоснование |
|---|---|---|
| Низкая сложность, мало зависимостей, отсутствие динамических вызовов. | Перенос на другую платформу (lift-and-shift) | Минимальный риск; поведенческая эквивалентность достижима в короткие сроки. |
| Умеренная сложность, хорошо документированная бизнес-логика. | Реплатформинг | Допускаются некоторые изменения; логика понятна. |
| Высокая сложность, плотный граф зависимостей | Фазированный душитель-фига | Постепенное расширение; сохранение мэйнфрейма в качестве ядра при модернизации его окружения. |
| Критически важная совместная программа, более 100 звонков. | Обертывание API | Предоставлять как услугу; переводить пользователей без изменения программы. |
| Программы с некорректными данными или проблемами форматирования. | Сначала исправление данных. | Миграция не может быть успешной, пока данные не будут чистыми. |
| Анализ подтвердил наличие неработающего кода. | Уход на пенсию | Миграция не требуется; исключить из области применения. |
| Недокументированная бизнес-логика, эксперт по предметной области отсутствует. | Требуется глубокий анализ. | Безопасная миграция невозможна до тех пор, пока не будет извлечена и задокументирована логика процесса. |
Построение последовательности миграции на основе графа зависимостей
Граф зависимостей, после его завершения, напрямую определяет последовательность миграции. Компоненты, не зависящие от других компонентов мейнфрейма, могут быть мигрированы независимо и на ранних этапах. Компоненты, от которых зависит множество других компонентов, должны быть мигрированы в последнюю очередь, после того, как все зависимые от них компоненты будут готовы.
Практический подход к секвенированию:
Этап 1: Вспомогательные программы и автономные пакетные задания. Программы без вызывающих процессов и общих наборов данных. Их можно перенести изолированно, без необходимости координации.
Этап 2: Конечные программы в дереве зависимостей. Программы, которые вызывают другие программы, но не вызываются многими из них. Миграция этих программ удаляет их из области зависимостей для остальных программ.
Этап 3: Программы, связанные данными. Группы программ, использующие общие наборы данных, могут быть перенесены вместе как единое целое, при этом контракт на формат данных будет решен внутри перенесенной группы.
Этап 4: Программы с общим доступом. Программы с большим количеством вызывающих сторон, узлы с высокой входящей связью в графе зависимостей, мигрировали только после того, как все вызывающие стороны были проверены на соответствие мигрированной реализации.
Этап 5: Основные транзакционные программы. Компоненты с самым высоким риском, мигрируемые последними, с наиболее полным тестированием и наиболее контролируемым процессом перехода.
Эта последовательность не является общей эвристикой, она выводится из конкретного графа зависимостей конкретной мигрируемой системы. Две среды мэйнфреймов с одинаковым количеством программ будут иметь совершенно разные оптимальные последовательности миграции, поскольку их структуры зависимостей различаются.
Как SMART TS XL Проводит предмиграционный анализ.
SMART TS XL Программа автоматически выполняет все восемь анализов, описанных в этой статье, путем анализа исходного кода каждого компонента в среде. Она не полагается на документацию, интервью с разработчиками или существующие схемы, а выводит структурную модель из самого кода, поэтому модель является точной даже для программ, которые никогда не были задокументированы, и зависимостей, которые сформировались без чьего-либо намерения.
Анализ модернизации устаревших систем начинается с создания полного перечня: каждая программа COBOL, поток заданий JCL, копибук, PROC и схема SQL каталогизируются с указанием местоположения исходного кода, размера, версии языка и предварительной оценки сложности. Сопоставление зависимостей приложений строит полный граф зависимостей, разрешая символические параметры JCL с помощью возможности расширения JCL , чтобы показать фактически вызываемые программы, а не неразрешенные ссылки на шаблоны.
Функция анализа влияния делает граф зависимостей доступным для запросов: перед миграцией любого компонента команда может узнать, что будет затронуто его удалением с мейнфрейма, и получить перечислимую, структурированную информацию обо всех зависимых компонентах, требующих проверки или координации. Функция корпоративного поиска позволяет одновременно осуществлять поиск по всему каталогу на всех языках программирования, находить каждую программу, которая считывает определенный набор данных, каждый копибук, определяющий определенное поле, каждый SQL-запрос, ссылающийся на определенный столбец, за считанные секунды в кодовой базе, содержащей миллионы строк.
Результатом предварительного анализа перед миграцией является не план проекта, а структурные данные: граф зависимостей, классификация сложности, перечень неиспользуемого кода, документация по бизнес-логике и карта интеграции, которые в совокупности точно показывают команде миграции, с чем они работают. Именно эти данные отличают миграцию, которая выявляет неожиданности в производственной среде, от миграции, которая обнаруживает их в процессе анализа, когда затраты на их обнаружение и устранение составляют недели, а не месяцы.
Анализ – это не дополнительные затраты, это миграция.
Наиболее распространенное возражение против всестороннего анализа перед миграцией касается сроков: организация определила дату начала миграции, давление со стороны руководства велико, и тратить шесть-восемь недель на анализ, прежде чем вносить какие-либо изменения в код, кажется задержкой. Такой подход переворачивает расчет рисков. Как только правила становятся видимыми, а потоки данных отображаются, проект переходит от предположений к разработке. Инструменты автоматизации делают невидимое видимым, и именно это имеет значение.
Миграция, начинающаяся без полного анализа, не ускоряется, она начинается с неизвестного масштаба. Неизвестный масштаб приводит к неожиданностям в графике, перерасходу бюджета и производственным инцидентам, когда обнаруживаются невыявленные зависимости. Этап анализа не задерживает миграцию; он и есть миграция. Каждая зависимость, обнаруженная во время анализа, а не во время перехода, — это производственный инцидент, которого не было. Каждая программа, идентифицированная как мертвый код до миграции, — это не затраченные усилия. Каждое бизнес-правило, задокументированное до преобразования, является критерием проверки, который можно проверить, а не угадывать.
Успешными оказываются те организации, которые заблаговременно решают сложные задачи, выявляют зависимости на ранних этапах, демократизируют знания, сосредотачиваются на ценности для бизнеса и с самого начала объединяются вокруг четких целей. Это не просто лучшие практики, это разница между проектами трансформации, которые приносят измеримую отдачу от инвестиций, и теми, которые становятся поучительными примерами.
