COBOL в XXI веке: почему банки и госслужбы не могут отказаться от языка 1959 года

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

Как старейший «серверный» язык справляется с XXI веком, где безопасность и гибкость важнее вечной стабильности?

Почему COBOL так живуч

Уже более 60 лет помогает бухгалтерии и финансам. Настроен на надёжность, читаемость и лёгкость (по меркам того времени), это и позволило стать стандартом в отрасли. Речь об одном из давних ЯП, которым пользуются по сей день.

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

Во-первых, объём «живого» COBOL-кода впечатляет: только в банковском секторе в 2024 году задействовано свыше 200 млрд строк, а через эти системы ежедневно прокатываются транзакции на сумму до $3 трлн. Фактически, около 70% ^[1] всех мировых бизнес-операций осуществляется с помощью COBOL-программ, от расчёта процентов по депозитам до массовых выплат заработных плат и социальных пособий.

Во-вторых, COBOL-модули глубоко вплетены в инфраструктуру мэйнфреймов и специализированных платформ — CICS для транзакционной обработки, DB2 для хранения данных, MQ для обмена сообщениями. За десятилетия каждая строка кода отточена под жёсткие регуляторные требования и содержит уникальную бизнес-логику. Переписывать это «с нуля» означает рисковать остановкой критичных сервисов, миллиардами штрафов и коллапсом доверия клиентов. Опыт ^[2] европейских банков показывает: даже сокращение объёма COBOL-программ с 57 000 до 27 000 штук заняло несколько лет, и полностью отказаться от языка так и не удалось.

И, наконец, кадровый дефицит. Сегодня больше двух третей инженеров, которые поддерживают эти системы, находятся на пороге выхода на пенсию. А значит, институциональная память ^[3] утекает с каждым годом, а учебные программы по COBOL давно сокращены до минимума. Поэтому большинство организаций выбирает не революцию, а эволюцию ^[4]: автоматизируют рутинные задачи, оборачивают старые транзакции в современные 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 остаётся неподвластным изменениям.

Эта связка незаметна для клиентов, но именно она обеспечивает безукоризненную работу всех массовых выплат, начислений и переводов. По данным ^[9] 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#. После чего их поведение ^[10] в тестах сравнивают с оригиналом, чтобы ничего не слетело. Так постепенно и безопасно «отодвигают» отдельные модули из мэйнфрейма, не потрясая весь фундамент. 2 ^[11].

Наконец, растущий тренд — гибридное размещение: «горячие» онлайн‑транзакции продолжают своё дело на доказанном z/OS, а тяжёлые batch‑задачи переселяются в облако. Баланс выдерживается легко: экономятся ресурсы мэйнфрейма, новые сервисы запускаются быстрее, а проверенная бизнес‑логика остаётся под надёжной защитой.

Кейс: страховая компания 

В качестве образцового примера «мягкой» модернизации COBOL‑систем стоит привести проект NN Group ^[13] — одного из крупнейших европейских страховщиков. Вместе с Deloitte за 23 месяца они поэтапно перенесли свои ключевые страховые приложения с мэйнфрейма на современную Java‑платформу, не прерывая при этом работу сервисов. Сначала провели глубокий аудит существующего COBOL‑кода и составили карту зависимостей, затем автоматизировали рефакторинг и внедрили CI/CD‑конвейер для «плавающего» запуска новых модулей параллельно со старой системой.

Каждый перенесённый компонент проходил строгую многоуровневую валидацию: сравнивали результаты расчётов, прогоны регуляторных сценариев и нагрузочное тестирование. Благодаря этому удалось добиться 100% совпадения бизнес‑логики и одновременно исключить простой — новые и старые сервисы работали бок о бок до полной выкатки.

Финальный эффект превзошёл ожидания: затраты на ИТ‑инфраструктуру сократились на 80%, а зависимость от узкоспециализированных COBOL‑разработчиков оказалась полностью устранена. Перенос на Java дал NN Group свободу быстрого старта новых продуктов и интеграции с цифровыми каналами: то, что раньше занимало месяцы, теперь делается за несколько недель. Этот кейс по праву считают отраслевым эталоном прозрачной, безопасной и автоматизированной миграции критичных систем.

Итоги

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

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

Современные компании выбирают не полный переписок, а «мягкую» эволюцию: оборачивают старые процедуры в REST‑ или gRPC‑API, выносят пакетные задачи в облачные функции, а живой COBOL‑код постепенно рефакторят с помощью автоматизированных инструментов. 

Так удаётся сохранить отлаженную бизнес‑логику и отказоустойчивость, не ставя под удар весь ИТ‑ландшафт.

Слышали что-то про COBOL‑код в последнее время? Делитесь мнением в комментариях!

© 2025 ООО «МТ ФИНАНС»