Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 18
Еще момент - перенесенная система на оборудовании той же мощности (или стоимости) должна показывать как минимум не худшую производительность и устойчивость к большим нагрузкам. Т.е. затраты на переход должны быть обоснованы экономически.
Ну и совпадение результатов должно быть не 97-98%, а 100. И не в одном тесте, а в параллельной работе в течении длительного времени. Только после этого может быть принято решение и выводе из эксплуатации старой системы.
А я верно понимаю что в статье речь не про наши банки? Покрайней мере не из топ10.
Ну общий принцип везде одинаковый. Банки - это про деньги. Большие деньги. Чужие деньги. И большие нагрузки.
Ошибки там могут стоить очень дорого. Как репутационно, так и финансово.
Кажется в большинстве банков нагрузки не сильно большие на корневые системы. Сколько там платежей в секунду. Подозреваю даже в Сбере это маленькие сотни в секунду дай бог, а то и меньше
У нас оценочное (на слишком свежее) - более сотни миллионов платежей в сутки. Система расчетов - самая нагруженная система.
Это в нормальных условиях, когда утилизация серверов на уровне 40-50%. В период пиковых нагрузок (например, предновогодний период) утилизация может достигать 80-90%. Т.е. почти вдвое подскакивает.
Провести платеж - тоже не такая простая операция. Всех подробностей не скажу т.к. не моя тема (я в команде клиентских данных и автоматизации комплаенса). Но как-то была задача по комплексу комплаенс проверок для системы расчетов. Там каждый платеж классифицируется
входящий/исходящий/внутренний
плательщик ФЛ/ЮЛ/ИП
получатель ФЛ/ЮЛ/ИП
Для каждой комбинации параметров выбирается свой набор и порядок проверок (всего их около десятка) со своими настройками.
Цель - определить пропускать платеж безусловно или отправлять на ручной контроль.
Т.е. платежи идут "стремительным домкратом" и на обработку каждого требуется определенное время и ресурсы.
И тут речь не только про платежи по картам в магазине, но и всяких переводах по СБП и всевозможных переводах между ЮЛ.
Так что нагрузка весьма немаленькая. И это только по платежам. А еще есть всякие открытия счетов, заведения новых клиентов и еще бог знает что. Там до черта всякой автоматизации. Заводим клиента - надо проверить его по БД террористов... Открываем счет - надо послать отбивку в ФНС... Каждый день проверить у кого из клиентов истекает срок действия ДУЛ и разослать уведомления... И еще очень много чего всего...
OpenAI в своем посте ссылается на оценки IBM: на COBOL держится больше 40% систем онлайн-банкинга, 80% оплат картой в магазинах и 95% операций в банкоматах. Оценка не очень прозрачная, так что цифры лучше считать порядком величины, но масштаб понятен.
Могу предположить, что в России эти проценты существенно меньше, если вообще не исчезающе малы, по понятным причинам.
Отдельные железки IBM в закрытых контурах крупных банков крутились еще в десятых годах, но их активно вычищали. Основной объем транзакций давно переложили на современные реляционные СУБД
Это где? Там, где крутились PowerS, они до сих пор крутятся исправно.
Но кобола там нет :-)
Есть, есть такие банки, в которых действительно в 10-х уходили с IBM-ов на не менее крупную технику других производителей. И таки да, COBOL-а там не было.
Честно говоря, этот уход малоцелесообразен. Тот же IBM i специально ориентирован и оптимизирован для банковской сферы. Там много такого, чего нет в других платформах.
Та же фиксированная поддержка на уровне языка всех типов используемых в БД - дата, время, фиксированная точка. Прочитал запись и работай с полями. Не надо никаких дополнительных преобразований.
Два способа работы с БД - можно SQL непосредственно в код, можно без SQL по индексам. Причем без SQL во многих случаях работает стабильнее и быстрее в условиях высоких нагрузок.
А если работает со скулем, то можно работать со статикой, когда корректность запроса и его подготовка происходит на этапе компиляции, а не в рантайме (на практике разница в эффективности может достигать 30% на одном и том же запросе)
То же переполнение вызывает системное исключение - Reciever too small to hold result. А это значит что у вас гарантировано отсутствие некорректного поведения при переполнении. Сразу получите ошибку и дальше не пойдете, а не будут задним число гадать почему "баланс не сходится".
Ну и все это работает реально быстро и очень хорошо держит высокие нагрузки.
В общем, все это достаточно узкая и достаточно специфическая ниша и специализированные платформы в ней показывают себя лучше универсальных. Если попробовать сделать одно и то же специализированным средством и универсальным (я пробовал), то смотришь на результат универсального и думаешь "зачем так жить если так мучаться?". Куча зависимостей, куча "лишних" преобразований... А что там "под капотом" даже подумать страшно.
За счет чего выросли результаты, OpenAI не объясняет
Видимо у OpenAI откуда-то появилось много обучающих данных на COBOL. Интересно, откуда 🤔?
Почему ИИ плохо писал на COBOL и что изменилось?
За счет чего выросли результаты, OpenAI не объясняет.
хе-хе
Интересно, а как обстоят дела с ерп системами.
Abap (sap)
X++ (axapta)
1c
переписывало программы с COBOL на современные языки
Ну раньше этим занимались потому, что не хватало джунов, знающих COBOL, а сейчас-то это к чему?
Видел попытку переписать древний биллинг на современный стек - тесты вроде проходили зелеными, а под реальной нагрузкой транзакции начали блокировать друг друга намертво, в итоге проект тихо свернули и вернули старый сервер на место
Классический пример - Банк Содружества Австралии и Океании. Он тоже переписывали на новый стек.
Заняло это 5 лет (2012-2017), по деньгам обошлось в $750млн. Так еще и проблем огребли по дороге. Самое эпичное когда вдруг по всем клиентам обнулилась кредиторская задолженность... А это откат с ленты и ручной накат всего за прошлый день с выявлением момента когда где и что пошло не так...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему ИИ плохо писал на COBOL и что изменилось: разбираем новый бенчмарк OpenAI