молодой человек удивляется, что в таких системах почти все — пакетная обработка и говорит о postgre и mysql и миллисекундах на запрос. Он просто еще не в курсе, что на действительно больших объемах в независимости от СУБД обработка будет по прежнему пакетной. и более того, ни PG. ни тем более mySQL не пустят в ближайшие 10 лет ни в один банк в качестве ядра данных. Имею право так говорить, имя опыт работы в небольшом банке. Как можно себе представить систему с моментальной интерактивной обработкой всех операций, если операций миллиарды в день (для всей мировой банковской системы), размазанные по всей земле? Добавьте сюда все формальные требования к банковском делу по учету…
А по поводу жуткого легаси — это было и будет проклятьем банков (ну ок, может быть это проклятье снимет блокчейн). Потому что невозможно изменять систему на ходу. Зачем и во имя чего переписывать на новые технологии уже оттестированный код в условиях, когда нужно писать и писать свежие формы, отчеты, обработки и тому подобное? Время и ресурсы есть только на то, чтобы позаботиться о стабильности текущего состояния и проверить, что в перспективе стабильность не пропадет.
Да, системы со временем таки обновляются. Но на эти изменения уходят года. Год на планирование, год на выбор новых систем, год на проверку и пару лет на полную замену. Когда новая система вступила в бой — она уже устарела на 2-4 года, а ей еще теперь работать 10 лет.
Маме автора действительно нужен памятник — редкая порода инженеров, способных десятками лет поддерживать систему не забывая о развитии этой системы
Напрашивается идея приделать microSD. Делать софт, который правит пароли через тот же интерфейс, через который они выводятся — несекьюрная идея. А так — на доверенной машине сформировали файл с паролями, залили на носитель и вставили в железку. Для защиты SD можно использовать избыточное шифрование с ключом, зашитым в контроллер
из vnc можно собрать аналог. обертка с интерфейсом типа ammyy пишется за день. ну и разместить промежуточный сервер где-то для обхода NAT. решение абсолютно рабочее. К сожалению, исходниками поделиться не могу, ибо NDA
пункт 14. Я бы написал так: «чем серьезнее авария, тем медленнее стоит опускать кружку с кофе на стол». Все-таки, когда навернулась база с тысячей, другой активных пользователей, немного не до чаепития. Но разум должен быть холодным, когда руки коснутся клавиш.
Вы сейчас как раз в состоянии вздрагивания от каждого телефонного звонка. Либо меняйте характер, либо меняйте компанию, в которой работаете. Ответ на этот вопрос искать вам, поскольку из вашего комментария непонятно, кто же больше виноват в ситуации. Возможно, вам просто стоит успокоиться, написать план работы на год и следовать ему, возможно стоит махнуть на работодателя рукой
А по поводу жуткого легаси — это было и будет проклятьем банков (ну ок, может быть это проклятье снимет блокчейн). Потому что невозможно изменять систему на ходу. Зачем и во имя чего переписывать на новые технологии уже оттестированный код в условиях, когда нужно писать и писать свежие формы, отчеты, обработки и тому подобное? Время и ресурсы есть только на то, чтобы позаботиться о стабильности текущего состояния и проверить, что в перспективе стабильность не пропадет.
Да, системы со временем таки обновляются. Но на эти изменения уходят года. Год на планирование, год на выбор новых систем, год на проверку и пару лет на полную замену. Когда новая система вступила в бой — она уже устарела на 2-4 года, а ей еще теперь работать 10 лет.
Маме автора действительно нужен памятник — редкая порода инженеров, способных десятками лет поддерживать систему не забывая о развитии этой системы