Представьте, что расчёт вашей пенсии или миллионы банковских транзакций обрабатываются кодом, написанным до полёта человека в космос. COBOL живёт в мэйнфреймах банков, страховых и госслужб, и отказаться от него рискованно: один баг — и вся финансовая система может остановиться.
Как старейший «серверный» язык справляется с XXI веком, где безопасность и гибкость важнее вечной стабильности?
Почему COBOL так живуч
Уже более 60 лет помогает бухгалтерии и финансам. Настроен на надёжность, читаемость и лёгкость (по меркам того времени), это и позволило стать стандартом в отрасли. Речь об одном из давних ЯП, которым пользуются по сей день.
COBOL по-прежнему играет ключевую роль в банковской и государственной сферах, и этому есть несколько объективных объяснений.
Во-первых, объём «живого» COBOL-кода впечатляет: только в банковском секторе в 2024 году задействовано свыше 200 млрд строк, а через эти системы ежедневно прокатываются транзакции на сумму до $3 трлн. Фактически, около 70% всех мировых бизнес-операций осуществляется с помощью COBOL-программ, от расчёта процентов по депозитам до массовых выплат заработных плат и социальных пособий.
Во-вторых, COBOL-модули глубоко вплетены в инфраструктуру мэйнфреймов и специализированных платформ — CICS для транзакционной обработки, DB2 для хранения данных, MQ для обмена сообщениями. За десятилетия каждая строка кода отточена под жёсткие регуляторные требования и содержит уникальную бизнес-логику. Переписывать это «с нуля» означает рисковать остановкой критичных сервисов, миллиардами штрафов и коллапсом доверия клиентов. Опыт европейских банков показывает: даже сокращение объёма COBOL-программ с 57 000 до 27 000 штук заняло несколько лет, и полностью отказаться от языка так и не удалось.
И, наконец, кадровый дефицит. Сегодня больше двух третей инженеров, которые поддерживают эти системы, находятся на пороге выхода на пенсию. А значит, институциональная память утекает с каждым годом, а учебные программы по COBOL давно сокращены до минимума. Поэтому большинство организаций выбирает не революцию, а эволюцию: автоматизируют рутинные задачи, оборачивают старые транзакции в современные API, интегрируют фрагменты мэйнфрейма с облачными сервисами и прибегают к ИИ-решениям для анализа и рефакторинга существующего кода.
Архитектура в действии: мэйнфрейм как сердце транзакций
В современной архитектуре банковских и государственных ИТ-систем мэйнфрейм с COBOL-приложениями выступает не просто вычислительным бэкендом, а сердцем всей транзакционной инфраструктуры. Рассмотрим четыре ключевых компонента, без которых невозможна ни одна серьёзная финансовая операция:
CICS (Customer Information Control System)
Это «транзакционный контролёр» мэйнфрейма. CICS гарантирует атомарность операций: либо весь набор действий выполняется целиком, либо при сбое система откатывает всё к исходному состоянию. Благодаря этому даже миллионы параллельных платежей и переводов обрабатываются без ошибок, потери данных или «двойных списаний».
DB2
Промышленная СУБД IBM, на которой лежат все главные фонды данных: банковские счета, история транзакций, профили клиентов и нормативные реестры. DB2 умеет масштабироваться на десятки узлов в кластере, обеспечивать онлайн-обработку гига- и терабайт данных с минимальными задержками (OLTP) и мгновенно восстанавливаться после любых «откатов».
IBM MQ (Message Queue)
Надёжный мост между «наследственными» COBOL-сервисами и современными микросервисами, мобильными и веб-приложениями. MQ обеспечивает гарантированную, асинхронную доставку сообщений, сохраняя порядок и целостность данных даже при пиковых нагрузках.
WebSphere / Liberty / API Gateway
На стыке мэйнфрейма и облака часто располагаются легковесные Java- или Node.js-слои (CSR, API-шлюзы), которые «обёртывают» старый функционал в современные REST- и gRPC-интерфейсы. Так фронтенд или внешние партнёрские системы получают доступ к транзакциям мэйнфрейма через знакомые JSON/XML-схемы, а COBOL остаётся неподвластным изменениям.
Эта связка незаметна для клиентов, но именно она обеспечивает безукоризненную работу всех массовых выплат, начислений и переводов. По данным BMC Mainframe Survey 2024, 42% финансовых организаций наращивают инвестиции в мэйнфреймы, а 46% прогнозируют рост нагрузки в следующем году — доказательство того, что такие «старички» по-прежнему незаменимы для критически важных сервисов.
Уязвимости унаследованного кода
Унаследованный COBOL-код, несмотря на свою репутацию «железобетонного» решения в вопросах транзакционной целостности, изначально не закладывал механизмы защиты от современных атак: в классических программах нет встроенной проверки границ буфера, фильтрации входных данных или жёсткой защиты динамического SQL и JCL‑скриптов. В результате даже банковские модули, написанные когда-то «один раз и навсегда», сегодня подвержены переполнению буфера, SQL‑инъекциям и другим давно известных векторов атаки, которые обманывают устаревшие проверки.
В 2023 году появились и свежие уязвимости: CVE‑2023‑4501 в составе Micro Focus Visual COBOL и Enterprise Server допускала обход аутентификации и давала злоумышленнику путь к критичным функциям. Банки и госструктуры вынуждены экстренно выпускать ночные патч‑релизы, чтобы не допустить простоев и утечек данных.
Дополнительный вызов создаёт то, что большая часть «боевого» COBOL‑кода была написана в эпоху до современных требований к безопасности, а документация к нему зачастую утеряна или устарела. Интеграция SAST/DAST‑сканеров и автоматизированных средств поиска уязвимостей необходима, но далеко не всегда возможна без серьёзной рефакторинг‑работы и перестройки инфраструктуры. Без регулярного аудита кода и внедрения внешних средств контроля такие системы рискуют превратиться из «железобетонных» в «да я тебе зуб даю».
Мягкая модернизация: стратегии без «большого взрыва»
Современная эволюция COBOL‑ландшафта идёт по пути точечного обновления вместо рискованного «взрыва». В основу лёг один трюк: все старые транзакции оборачиваются в лёгкие REST‑ или gRPC‑API. Теперь фронтенд и микросервисы общаются с мэйнфреймом по привычному HTTP, а не копаются в суровом COBOL‑монолите. Такой API-фасад не только упрощает интеграцию, но и сужает зону безопасности до понятных контрактов, а не до сотен тысяч строчек «наследного» кода.
Другой популярный путь — использование transpiler-решений, которые автоматически переводят критичные фрагменты COBOL-кода в современные языки, такие как Java или C#. После чего их поведение в тестах сравнивают с оригиналом, чтобы ничего не слетело. Так постепенно и безопасно «отодвигают» отдельные модули из мэйнфрейма, не потрясая весь фундамент.
Наконец, растущий тренд — гибридное размещение: «горячие» онлайн‑транзакции продолжают своё дело на доказанном z/OS, а тяжёлые batch‑задачи переселяются в облако. Баланс выдерживается легко: экономятся ресурсы мэйнфрейма, новые сервисы запускаются быстрее, а проверенная бизнес‑логика остаётся под надёжной защитой.
Кейс: страховая компания
В качестве образцового примера «мягкой» модернизации COBOL‑систем стоит привести проект NN Group — одного из крупнейших европейских страховщиков. Вместе с Deloitte за 23 месяца они поэтапно перенесли свои ключевые страховые приложения с мэйнфрейма на современную Java‑платформу, не прерывая при этом работу сервисов. Сначала провели глубокий аудит существующего COBOL‑кода и составили карту зависимостей, затем автоматизировали рефакторинг и внедрили CI/CD‑конвейер для «плавающего» запуска новых модулей параллельно со старой системой.
Каждый перенесённый компонент проходил строгую многоуровневую валидацию: сравнивали результаты расчётов, прогоны регуляторных сценариев и нагрузочное тестирование. Благодаря этому удалось добиться 100% совпадения бизнес‑логики и одновременно исключить простой — новые и старые сервисы работали бок о бок до полной выкатки.
Финальный эффект превзошёл ожидания: затраты на ИТ‑инфраструктуру сократились на 80%, а зависимость от узкоспециализированных COBOL‑разработчиков оказалась полностью устранена. Перенос на Java дал NN Group свободу быстрого старта новых продуктов и интеграции с цифровыми каналами: то, что раньше занимало месяцы, теперь делается за несколько недель. Этот кейс по праву считают отраслевым эталоном прозрачной, безопасной и автоматизированной миграции критичных систем.
Итоги
По моему мнению, COBOL не умирает во многом потому, что переписывать на новый язык слишком дорого и никто не хочет трогать то, что отлично работает и прошло проверку десятилетиями.
Он остаётся незаменимым каркасом для критичных бизнес‑систем, по‑прежнему обрабатывает триллионы транзакций и расчёты социальных выплат.
Современные компании выбирают не полный переписок, а «мягкую» эволюцию: оборачивают старые процедуры в REST‑ или gRPC‑API, выносят пакетные задачи в облачные функции, а живой COBOL‑код постепенно рефакторят с помощью автоматизированных инструментов.
Так удаётся сохранить отлаженную бизнес‑логику и отказоустойчивость, не ставя под удар весь ИТ‑ландшафт.
Слышали что-то про COBOL‑код в последнее время? Делитесь мнением в комментариях!
© 2025 ООО «МТ ФИНАНС»
Комментарии (28)
Octagon77
09.07.2025 09:44Я правильно понимаю, что это задача для ИИ которую он пока не тянет?
needsomedata
09.07.2025 09:44Потянет еще как, переезд на новый язык с сохранением логики это хорошее применение llm
Newbilius
09.07.2025 09:44Видел трансляторы из одного языка в другой без всяких LLM, по итогам работы которых код может был некрасивый, но надёжно рабочий. С LLM будет наоборот скорее всего, красивей, но менее предсказуемо.
SpiderEkb
09.07.2025 09:44Скорее всего нет. Потому что его придется не только двум языкам обучить, но еще и особенностям платформы с которой идет перенос. А там все может быть ну очень специфично.
Мне было интересно посмотреть как оно справится с ситуацией, когда один и тот же модуль в рамках одного задания вызывается (из другого модуля) несколько раз. И для экономии времени с прошлого вызова кешируются какие-то данные. Да-да-да. На AS/400 есть понятие "группы активации" как подмножества задания и все статические и глобальные данные сохраняются пока жива группа активации (пока живет задание или пока ГА принудительно не закрыли).
Тут с переходом на "современные языки" на другой платформе можно немало веселья отхватить пока придумаешь как все это обойти.
Ну или работа со специфическими системными объектами типа USER SPACE/USER QUEUE/USER INDEX...
Не говорю уже про тонкости реализации, связанные с производительностью. Или с точностью промежуточных вычислений для типов данных с фиксированной точкой... На таких "мелочах" тоже можно неслабо огрести. Даже если он заработает, но раза в полтора-два медленнее исходного...
SpiderEkb
09.07.2025 09:44в классических программах нет встроенной проверки границ буфера
Потому что они есть на уровне самой ОС. А еще там есть проверка на переполнение. Из соседней ветки
Так и случилось в один прекрасный момент несколько лет назад, когда путешествия на Бали (смотри курс индонезийской рупии IDR) стали внезапно стоить сущие центы из-за переполнения.
РаспродажуЛавочку прикрыли только к утру, когда заметили невероятную популярность клиента Agoda и отелей на Бали, и до исправления просто прекратили (на полгода) принимать платежи в валюте IDR. Убытки, как водится, просто списали, никого не наказали.Тогда как в нормальной системе в такой ситуации переполнение вызывает системное исключение "Receiver value too small to hold result"
Теперь фронтенд и микросервисы общаются с мэйнфреймом по привычному HTTP, а не копаются в суровом COBOL‑монолите.
Вообще-то центральный сервер в банке изолирован от внешнего мира достаточно серьезно. Получить какие-то данные от него можно лишь оправив запрос через MQ или вызвав вебсервис на ESB шине. Причем, сам вебсервис тоже внутрь не полезет - он вызовет связанный с ним сервис-модуль, передав ему набор параметров. А потом получит ответ (например, в виде resultset'а). Через MQ примерно также - послылается сообщение с определенным типом и набором данных. Это сообщение будет подхвачено на сервере, далее вызван соответствующий этому типу сообщений обработчик, который выполнит нужные действия и при необходимости отправит в MQ ответное сообщение.
Никакого http там и близко не лежало. И слабо себе представляю как можно реализовать SQL инъекцию в таком раскладе (SQL там может вообще не быть - есть и другие способы работы с БД, в т.ч. и в COBOL). Да и голый SQL там не используется. Он весь спрятан внутри COBOL кода.
А если говорить о защите, то та же IBM i (AS/400) имеет несколько уровней защиты самой системы. В том числе и "50" уровень, сертифицированный в США для государственных и военных организаций. И даже на более низком, "40"-м уровне, уже достаточно много ограничений для разработчика (например, запрет низкоуровневой работы через MI инструкции c объектами в домене *SYSTEM - даже если получишь системный указатель на объект, что-то сделать с ним уже не сможешь - только через системные API и никак иначе).
использование transpiler-решений, которые автоматически переводят критичные фрагменты COBOL-кода в современные языки, такие как Java или C#
А что там с поддержкой в "современных языках" типов данных, которые лежат в БД? Те же форматы с фиксированной точкой? Читаем запись, потом создаем из ее полей нужные объекты с которыми можно работать? Но, извините, это лишнее время и лишние ресурсы процессора...
А что там с работой с БД? Только SQL, причем только динамический? Без возможности подготовки запроса на этапе компиляции? И даже по одной таблице по индексированным полям доступ к БД все равно только скулем? Задач, где нужно из одной таблицы прочитать десяток записей по известному значению ключа в реальной жизни достаточно много. И гонять ради этого динамический скуль очень расточительно.
COBOL (или тот же RPG) создавались специально для максимально эффективного решения конкретного класса задач. И имеют для этого все встроенные средства, являясь по сути специализированными языками.
Kuklachev
09.07.2025 09:44Безопасность лежит не только в области самой системы. Можно иметь сколько угодно безопасную систему, а потом поставить пароль для qsecofr - qwerty, и толку от этой безопасности? Или все через mq, но только никто не подумал, что надо проверять источники сообщений. И все, кто угодно могут отправлять в это mq любые пакеты
SpiderEkb
09.07.2025 09:44А вы уверены, что "любой" пакет будет обработан? :-)
Вот пример реального сообщения
// Формат сообщения для HMQ-обработчика dcl-ds t_HMQFINNRSP template qualified; messageType char(10); requestUID char(32); INN char(12); end-ds;messageType - тип сообщения. Он должен быть прописан в таблице настроек движка, который эти сообщения читает из очереди, находит в таблице обработчик и вызывает его, передавая ему сообщение для обработки
requestUID - это ID запроса в ответ на который получено это сообщение (из внешней системы). На этот ID должна быть запись в таблице отправленных запросов. Если ее нет - сразу на выход.
Ну и дальше данные.
И практически все сообщения выглядят примерно так - структура с данными. И все данные на входе обработчика будут валидироваться. Если что-то не так - ошибка и на выход.
Просунуть туда что-то левое крайне сложно, если вообще возможно.
С вебсервисами примерно аналогичная история. Т.е. там нет RPC. Каждый вебсервис (связанный с ним сервис-модуль) или обработчик сообщения выполняет строго определенную функцию и ничего более. И им передаются только параметры. Которые валидируются.
Физический доступ к серверу - только из внутреннего контура (даже к тестовому) и для очень ограниченного круга лиц. Пароль - не менее 12-ти символов, "3 группы из 4-х", смена не реже чем раз в три месяца.
Kuklachev
09.07.2025 09:44Знание requestid - защита такая себе. Вряд ли это что-то секретное. Ну смысл моей мысли в том, что защита определяется самым слабым компонентом системы. Нет атак на операционку iseries- не значит, что система в целом безопасна
DarthVictor
09.07.2025 09:44Без возможности подготовки запроса на этапе компиляции?
Компиляции на каком из стендов? То есть я скомпилировал продакшен версию сборки, она с каким из стендов должна компилироваться?
Только SQL, причем только динамический?
Есть Prepared Statement есть Stored Functions.
COBOL (или тот же RPG) создавались специально для максимально эффективного решения конкретного класса задач.
Эффективного для кого? А то вариант с использованием нормального серверного железа общего назначения видится мне сильно эффективнее. И пофиг что оно будет вдвое менее эффективны из-за необходимости нескольких конвертаций. Зато процессоры будут вдесятеро быстрее из-за больших масштабов производства, а за одно колличество ОЗУ, IOPS-ы на системах хранения данных. И горизонтальное масштабирование проще. И виртуализация при разработке. И поиск разработчиков.
checkpoint
09.07.2025 09:44Помоему это такой способ конкурентной борьбы. IBM вырастила себе поляну и сама её топчет. Как только они переведут свои сервисы на что-то более человечное (Java, Scala) и стандартное x86 железо, их тут же потеснят с этого сочного рынка. Все эти IBM i/z и прочие однобуквенные платформы - типичный пример дичайшего переусложнения. Есть мнение, что эти машины тратят более половины своих вычислительных ресурсов только на организацию многоуровневой виртуализации, трансляцию форматов данных и протоколов между ними.
salnicoff
09.07.2025 09:44Есть мнение, что эти машины тратят более половины своих вычислительных ресурсов только на организацию многоуровневой виртуализации, трансляцию форматов данных и протоколов между ними.
Это плата за безопасность. Как только все переедет на x86 железо, следом переедет «многоуровневая виртуализация», «трансляция форматов данных и протоколов между ними». Или появятся новые варианты оных. Это как с клавиатурой в банкомате — вроде 12 кнопок, должна стоить копейки, но нет — внутри криптопроцессоры, батарейки для хранения ключей и все залито эпоксидкой с проводками.
checkpoint
09.07.2025 09:44Это не безопасность, это "security through obscurity".
salnicoff
09.07.2025 09:44Никаких «obscurity». Все задокументировано и объяснено, почему именно так сделано.
checkpoint
09.07.2025 09:44Там количество документации умопомрачительное. Прочитать и проанализировать её не сможет ни одна нейросеть в мире. Это ли не "obscurity" ?
В 90-х года мне доводилось администрировать цифровые телефонны станции Nortel Meridian-1, чем-то они похожи на IBM-овских динозавров. Так вот, документации к Meridian-1 было около 80-ти жирных томов. Что либо найти в них можно было если только ты абсолютно точно уверен в каком именно томе искать. При этом нужно быть хорошо знакомым с используемой терминологией, а она там очень специфическая. IBM это вообще отдельный мир.
PerroSalchicha
09.07.2025 09:44Это как с клавиатурой в банкомате — вроде 12 кнопок, должна стоить копейки, но нет — внутри криптопроцессоры, батарейки для хранения ключей и все залито эпоксидкой с проводками.
...при этом в недрах мейфрейма лежит плоский файлик с зарегистрированными в системе PAN (собственно, карточки), а в нём есть поле PIN offset, это произвольное значение, которое перед валидацией прибавляется к сгенерированному по криптографическому алгоритму PINу, и которое позволяет изменить его на любое другое значение. И это обычное числовое поле, открытое и доступное любому, кхм, кобол-программисту с соответствующими правами.
Kuklachev
09.07.2025 09:44Вот именно. Просто исторически на i и z делали много бизнес-приложений. И приходится тянуть это легаси до бесконечности. Я с трудом себе представляю, чтобы сейчас кто-то в здравом уме решил новое приложение с нуля писать именно для IBM
DarthVictor
09.07.2025 09:44В качестве образцового примера «мягкой» модернизации COBOL‑систем стоит привести проект NN Group — одного из крупнейших европейских страховщиков. Вместе с Deloitte за 23 месяца они поэтапно перенесли свои ключевые страховые приложения с мэйнфрейма на современную Java‑платформу, не прерывая при этом работу сервисов. Сначала провели глубокий аудит существующего COBOL‑кода и составили карту зависимостей, затем автоматизировали рефакторинг и внедрили CI/CD‑конвейер для «плавающего» запуска новых модулей параллельно со старой системой.
История даёт хороший ответ, почему старые продукты живут десятилетиями, а современные по сто раз переписывают. Потому что МОГУТ. Во-первых, на новые ещё не потеряна вся документация, во-вторых, они изначально писались так, что в них проще вносить изменения.
olku
09.07.2025 09:44Про COBOL ходит много легенд. Не смотря на то что в статье чувствуется GPT, она их хотя бы не повторяет. Со стека съехали давно кто мог, ничего в COBOL такого уникального нет кроме вендор лока. Это примитивный ЯП, все фишки в библиотеках, которые совсем не опенсорс, и завязаны на конкретный компилятор конкретной ОС.
Kahelman
09.07.2025 09:44Что-то у вас не едет я. Если COBOL это примитивный язык программирования , который был популярен в60-70 годы, то на нем активно писали от силы 20 лет. О его Смерти говорят уже дано, однако за прошедшие 40 лет, избавиться от него не смогли. Похоже это ЯП сделанный как надо для своего класса задач.
И вопрос на каком языке вы бы переписывали код в 90-х из тех что поддерживаются сейчас?По поводу gRPC - сколько лет технологии как с неё мигрировать через 30 лет?
Там основной вопрос не в языке и нехватке программистов, а в том кто будет следующие 20 лет предоставлять поддержку
A1WEB
11 лет проработал с банковской сфере со страшным легаси. Cobol встречал только в статьях по истории языков программирования...
dv0ich
Это про западные банки, которые начали компьютеризироваться в 50-60-х годах.
Vytian
Страшное легаси -- это ПП/БЭСМ. А не эти ваши новомодные фортраны и паскали.
PerroSalchicha
Паскаль - современник БЭСМ-6, а Фортран постарше на десятилетие будет :)