
Недавно я наткнулся на историю столь же удивительную, сколь и ужасную:
Один из моих клиентов занимался поддержкой нескольких пенсионных фондов, входящих в сотню лучших по миру. У него была еженочная пакетная задача, которая начала вылетать. Поначалу никто не мог понять, в чём дело. Насколько все помнили, эта пакетная задача никогда раньше не вылетала.
Написавший её человек умер уже 15 лет назад, да и ушёл из компании много десятков лет назад. Программа была не такой большой, однако оказалась непостижимой. Её писали в стиле, отдававшем приоритет вычислительной эффективности, а не простоте чтения. И, разумеется, у неё не было никаких тестов.
Как назло, днём ранее запушили изменение порядка выполнения скриптов, работающих в этом окружении. Все решили, что виновато это изменение. Инженеры откатили всё к предыдущему релизу. К сожалению, это только усугубило проблему.
…
Ещё одна программа, занимающаяся переводом прибыли, должна была уведомлять пользователей, что их вкладов недостаточно для прогнозирования дохода. Заметив, что из первой программы из-за её вылета нет выходных данных, она восприняла эту ситуацию как «все вклады равны 0». Разумеется, она должна была вести себя совершенно иначе. Но никто не знал, что она будет действовать так, поскольку первая программа никогда не вылетала.
…
Я получил от ИТ-директора неожиданное текстовое сообщение. «Простите за беспокойство, у нас огромная проблема. s1X. Можете прилететь сегодня во второй половине дня?» В их терминологии S1X обозначает «хуже, чем уровень серьёзности 1, потому что проблема распространилась на несвязанные с ней части бизнеса».
К счастью, все пенсии были спасены и история окончилась хэппи-эндом. Но нам вряд ли покажется нормальным, что критически важные финансовые системы зависят от древнего ПО, в котором не разбирается никто из ныне живущих людей.
Читать полностью »