Шеркало 07.04 Клиент-банк: бета-тесты, проблемы с почтой, троянский конь, ABSA

Список глав рассказа:

Шеркало 07.01 Клиент-банк: Преамбула, военная кафедра, бухгалтерия

Шеркало 07.02 Клиент-банк: Банк, задачи, источники информации

Шеркало 07.03 Клиент-банк: Модульная архитектура, фронтенд

======== Эта глава номер 07.04 ========

- Привет, Ёж! Давай продолжай про свой Клиент-банк. Мне в прошлый раз даже понравилось!

- Ага, Шеркало, тебе так понравилось, что ты аж храпело на всю квартиру... Дочь даже вечером спрашивала, почему это мой ноутбук рычит кулером и бьётся ножками об столешницу, мешает ей готовиться к занятиям?

- Ёж, не завидуй! Вот когда ты храпишь целыми неделями и месяцам, и ничего при том в блог не пишешь, я должно терпеть, значит? Вот и ты немного мой храп потерпи.

- Допустим потерплю. Только и ты постарайся в этой главе побольше молчать. Мне так проще будет. Тема и без тебя сумбурная слегка (да ещё и древняя, на самой границе памяти и уже далеко за гранью сохранившихся деталей). На чём мы в прошлый раз остановились? На банковской части системы?

Первые бета-тесты

В разработке прототипа (помнишь, "нулевая версия"?) системы Клиент-банк я дошёл до момента, когда нужно было начинать тестирование. Причём, тестировать нужно было на реальных клиентах в боевой обстановке. Мои "внутриофисные" тесты не дали бы ни малейшего полезного результата по причине того, что ни я, и никто вокруг, собственно и не понимал, а КАК этот результат должен выглядеть? На этом месте я бы сам, в силу своего характера, мог бы застесняться и тормознуть. Но тут выручил шеф. Он сам, по собственной инициативе и собственному разумению, подобрал для меня около десятка "дружественных" клиентов из числа либо его собственных закадычных приятелей (кстати, как это ни смешно, в этой группе у меня с шефом обнаружились и некоторые ОБЩИЕ для нас обоих знакомые-приятели!), либо из числа очень вменяемых современных менеджеров. Все они прекрасно понимали, что на них будут ТЕСТИРОВАТЬ совершенно новую технологию, и сознательно соглашались на такую роль. Негласно, но внятно, шеф дал мне понять, что даёт нечто вроде карт-бланш на период начального внедрения системы (как там было в "Трёх мушкетёрах"? "Всё, что делает этот человек, делается на благо Франции и по моему приказу! Кардинал Ришелье (с))- если что-то вдруг пойдёт не так, никаких жёстких мер ко мне сразу применять не будут, дадут шанс исправиться. 

Ещё очень важный момент, помимо лояльности и дружественности, все предложенные мне шефом "тестовые" клиенты первого десятка, обладали очень важным качеством. Они все (в первую очередь в лице их руководителей) были безусловными АКТИВИСТАМИ. Они все стремились задействовать систему электронных платежей с самого начала по самому максимуму её возможностей. Они давали мне (добровольно, по своей инициативе) максимально возможную диагностику, что по их мнению срабатывает неправильно или недостаточно эффективно в действующей реализации. Тут же с энтузиазмом выдавали предложения, как можно было бы улучшить документооборот. Разумеется, далеко не всё, что ими предлагалось, на практике могло быть успешно реализовано, кроме того, не всё, что называлось с их точки зрения "недостатками" системы происходило по моей вине. Во многих случаях мы просто вынуждены были разводить руками и следовать в фарватере жёсткой политики ЦБ и ГО. Но сам объём тестирования разнообразных вариантов и сопутствующее количество предложений по улучшению - это было для меня КОЛОССАЛЬНОЙ помощью. 

Проблема с электронной почтой

Итак, мы по очереди, поштучно, начали подключать клиентов первого "тестируемого" десятка к системе Клиент-банк, попутно совершенствуя систему. Изначально не было готово почти никакой автоматизации. Все настройки и на клиентской, и на банковской стороне, выполнялись большей частью лично мной вручную. Некоторые чисто технические действия, которые в штатном режиме разумеется должны были делаться полностью автоматически, на самом первом этапе тоже иногда выполнялись вручную. Очень медленно накапливалась статистика реальной работы. Как я уже ранее говорил, криптография на базе программы PGP ни малейших нареканий практически ни разу ни у кого не вызывала. Мы работу с PGP  позже тоже немного совершенствовали, но только лишь чтобы слегка оптимизировать ход проверок в криптосистеме. PGP проехали. 

А вот максимальные нарекания вызвало использование электронной почты Sprint. Нет, ВРУ! ;)) На самом деле в самых ранних вариантах системы вызывала массовые нарекания и почта Sprint, и в то же время моя собственная "основная" программа на FoxPro. Но, во-первых о проблемах с моим личным кодом я намного подробнее расскажу несколько ниже по тексту. Во-вторых, нарекания на мой код FoxPro я по мере возможностей максимально оперативно устранял. И клиенты эту мою скорую реакцию очень положительно оценивали. По прошествии небольшого времени, количество нареканий на мой код очень быстро сошло почти к нулю. А вот количество нареканий на почту Sprint непрерывно росло с каждым днём (а этих дней-то ещё и пары месяцев с начала работы не прошло!), и с каждым новым подключаемым клиентом, и с этим я ничего не мог сделать - программа чужая (да ещё и иностранная).

Началось всё с резкого недовольства ВСЕХ без исключения клиентов чрезмерными ценами Sprint. Я сам, если честно, сначала не обратил на это особого внимания - всё равно а) нам в любом случае до зарезу в первый год работы филиала был нужен их виртуальный Телекс; б) платит-то банк, а не я, и отнюдь не из моей зарплаты платит; в) а чёрт его знает, какие цены в этих банках вообще сейчас считаются "нормальными", я сам здесь первый раз оказался. Но когда в один голос взвыли от расценок Sprint опытные коммерсанты - руководители предприятий-клиентов, я начал анализировать их тарифы. И обнаружил, что они фактически не только очень сильно завышают цены, но ещё и берут по несколько раз разные платежи, за одну и ту же оказанную услугу. Например, берут за некоторую услугу фиксированную абонентскую плату один раз в месяц, плюс за эту же услугу берут поминутную плату за каждую минуту фактического соединения модемов, плюс за ту же услугу берут оплату за каждый отдельный килобайт передаваемых файлов. И все эти тарифы срабатывают одновременно! Ниже приведу примерный типовой списочек платежей. Предупреждаю, все цены в этом списке даны мной "по памяти", можно сказать "от фонаря". Я сейчас уже не помню точных цен, только приблизительный порядок. Но могу уверить, что цены на услуги Sprint тогда превышали типовые цены местных провайдеров в несколько ДЕСЯТКОВ раз.

- За подключение к сети Sprint и регистрацию в сети личного почтового ящика (без которого работать нельзя) нужно было разово заплатить что-то около $ 300.

- Ежемесячно за обслуживание этого п/я нужно было платить примерно по $ 50, независимо от фактов пользования этим п/я (хоть целый год туда не заглядывай); кроме того, там вроде требовались разовые + месячные доплаты за увеличение объёма п/я свыше совсем ничтожного минимума - это как раз мера против хитрых, которые целый год в п/я не заглядывают, но точно цены не помню.

- За каждую попытку соединения с местным модемным пулом провайдера - $ 10.

- За каждую минуту соединения с местным модемным пулом провайдера - $ 5.

- За каждый принятый из Sprint кБайт данных - $ 3.5.

- За каждый переданный в Sprint кБайт данных - $ 2.5.

Вполне вероятно, что цены здесь неточны (да и список обязательных к оплате услуг неполон), но точно помню, что после некоторого анализа, эти цены можно было определить только одним термином: "конские"! К тому же, не стоит забывать, что в те времена в организациях, подобных Sprint, в обязательном порядке применялись хитрости округления. Например, если сеанс связи с сервером фактически длился 5 секунд, а потом обрывался из-за некачественной линии связи (модемы не смогли согласовать соединение при помехах), то с клиента за эти 5 секунд неудачной попытки соединения, брали оплату как за полноценную минуту связи (плюс отдельную оплату за сам факт попытки соединения). Аналогично, если между клиентом и сервером был фактически передан какой-то небольшой технический пакет размером в десяток байт, то с клиента взималась оплата "за трафик" как будто за полноценный КИЛО байт. Я, разумеется в вежливой форме, пытался задавать местным сотрудникам Sprint вопросы: "А что это у вас за такая странная фигня с тарифами?!" На это всегда получал типовые ответы:

- Ну, мы же солидная американская компания, оказываем солидные услуги связи на высшем международном уровне качества. Вот и цены у нас тоже солидные. К тому же, на внутреннем рынке услуг связи в США подобные цены особо высокими вовсе не считаются. Там это так, средненький уровень.

На первых порах мне приходилось выслушивать подобную аргументацию молча, без возражений. Ну да, солидная компания, ну да, высокое качество услуг, куда деваться? Но постепенно, по мере роста количества подключенных к Sprint наших клиентов, начала быстро накапливаться крайне неприятная статистика. То у одного клиента, то у другого, внезапно куда-то пропадали отправленные в наш банк платежи. Я, разумеется, при малейшей жалобе организовывал расследование на доступном мне уровне. 

Картина выглядела странно, неприятно и непонятно. Письмо с очередным платежом в банк на стороне клиента судя по всем имеющимся логам всех подсистем абсолютно успешно формировалось. Далее, клиент запускал сеанс связи с сервером Sprint. По логам клиентской части почтовой программы было видно, что сеанс связи завершался успешно и без каких-либо видимых ошибок, в том числе письмо с впоследствии потерявшимся платежом успешно отправлялось на сервер. Тут я начинал разгребать логи почтовой программы у себя на стороне филиала. И по ним, как правило наблюдал, что с нашей стороны в это время все сеансы связи с сервером тоже выполнялись регулярно и успешно, некоторые письма успешно отправлялись, некоторые успешно принимались. Вот только того письма с потерявшимся платежом среди них вообще НЕ БЫЛО!

Я брал распечатки логов связи клиента и филиала, из которых следовало, что письмо затерялось где-то в недрах их сети, тащил эти распечатки с вопросами в местную тех.поддержку Sprint. Там мне вежливо отвечали, что да, таки письмо где-то затерялось в недрах сложной глобальной сети, бывает, что таких случаев у них каждый день по десятку штук, что это, как у Карлсона с известной Крыши, "пустяки, дело-то житейское!" А куда именно затерялось письмо с платежом и почему затерялось, этого никто выяснить не может, и даже специально обученная пограничная собака из службы Береговой Охраны США след не берёт!

Транспортная программа UUPC

Количество нареканий на работу электронной почты нарастало лавинообразно с каждым днём. Мы успели принудить подключиться к сети Sprint не то 6, не то 7 ранних клиентов, готовых поработать тестеровщиками. Прошла едва пара месяцев с начала разработки моей системы Клиент-банк, когда стало окончательно ясно, что такое решение с транспортом платежей через эту электронную почту абсолютно неприемлемо!!! Требовалась немедленная смена транспортной технологии. Но на что? За прошедшее краткое время, собственно ничего на рынке технологий местной связи не поменялось. Другие локальные системы электронной почты по-прежнему не выглядели резко более предпочтительными, никто не гарантировал, что их провайдеры окажутся по всем параметрам успешнее и надёжнее владельцев Sprint. Вариант с собственным полноценным почтовым сервером по-прежнему выходил неоправданно дорогим в организации и обслуживании. Многообещающие в будущем глобальные технологии обмена данными в сети Интернет, всё ещё не достигли приемлемого для нашего коммерческого использования уровня развития. Так что же выбрать?

Ответ рисовался единственно возможный: клиент должен был для сеанса связи дозваниваться своим модемом непосредственно на модем(ы) банка и обмениваться файлами в режиме "точка-точка". Ну и программное обеспечение для подобного дозвона/обмена требовалось по возможности бесплатное. И такое готовое решение в тот момент существовало, было известно. Туда я и обратил своё первоочередное внимание. Я уже упомянул в предыдущей части, что в 90-е годы получала развитие некоммерческая сеть компьютерных энтузиастов ФИДО. К этой сети мог подключиться каждый желающий, имеющий компьютер с модемом и периодический доступ к городской/междугородней телефонной линии. Функционал сети ФИДО был достаточно разнообразен, сама сеть строилась по иерархическому принципу подчинённого взаимодействия нескольких более-менее связанных древовидных структур, состоящих из своих добровольных членов. На практике, многие участники сети работали в ней исключительно с домашних компьютеров и строго по ночам (домашний телефон ночью обычно свободен, а тариф на городскую и междугороднюю связь ночью бывает дешевле). 

Хотя иерархия компьютеров в ФИДО была намного более развитой, чем требовалось для системы Клиент-банк, и структура программного обеспечения чрезмерно сложная, тем не менее, требуемый мне функционал обмена файлами в режиме "точка-точка" при прямом дозвоне с модема на модем, там был вполне реализован, в качестве одной из важных функций. Плюс - бесплатность программ вроде бы заявлена. Другой вопрос, что я сам лично к сети ФИДО никогда не подключался, никакого опыта настроек софта в ней не имел, даже о самих принципах организации ФИДО имел крайне смутное представление. Ну ничего же страшного, да? Дайте немного времени, я же разберусь, так? А вот ВРЕМЕНИ на изучение этого ранее незнакомого мне вопроса не было не то что ни единого дня. Времени не было ни единой минуты! Транспорт Клиент-банка на базе сети Sprint показал свою полную и абсолютную неадекватность. В том направлении - больше ни шагу! А с меня шеф требовал непрерывного подключения новых клиентов. У него там целый план в ежедневнике был составлен. А подключать их было ФИЗИЧЕСКИ НЕКУДА!!! 

Пришлось просить помощь, благо было у кого. У меня был приятель, однокурсник по Университету. В тот момент он, кстати, работал в нашем ЦБ, но не в той группе, которая занималась с нами электронными платежами. Совсем в другом отделе. Этот однокурсник достаточно давно участвовал в работе ФИДО, имел собственную ноду. Слыл опытным ФИДОшником. К нему я и рискнул обратиться за помощью в экстренном получении и настройке урезанной по функционалу версии ФИДОшного программного обеспечения. Он ответил. А от его ответа на меня внезапно (неожиданно для меня, мы всё-таки с ним были в довольно неплохих отношениях) пахнуло очень знакомым запахом гнили! Ровно тот же самый запах гнили я почувствовал, когда первый и последний раз посещал обанкротившийся бывший банк своего шефа, пытаясь узнать, как у них был организован Клиент-банк (ага, "сначала заплати нам XXXX баксов, а потом мы может быть начнём с тобой разговаривать"). Вот, в первом же ответе моего приятеля однокурсника ФИДОшника зазвучал ровно тот же самый гнилостный запах: 

- Легко помогу тебе! Сначала купи мне полный ящик хорошего импортного пива и оплати такси до твоего дома и обратно. Как получу ящик пива, я к тебе приеду (и тебя стаканчиком твоего пивка тоже угощу, не боись), сам настрою тебе минимальный софт на твоём компе, чтобы ты стал моим поинтом. Потом я подскажу тебе пять-шесть адресочков, которых ты должен будешь окучить и убедить их тоже стать моими поинтами в ФИДО. А вот потом - приходи, заплатишь мне YYYY баксов, и тогда мы с тобой поговорим, как тебе в твоём банке свою личную сетевую ноду поднять! Чего-нибудь подскажу.

Нечего и упоминать, что этот разговор поверг меня тогда в глубокий шок. Сначала, Шеркало, я хотел написать здесь целый абзац, как впоследствии неоднократно вспоминал эту беседу, как мысленно подбирал разумные оправдания для слов моего однокурсника. Потом решил, что всё это будет лишнее.

На самом деле, ситуация неожиданно "почти сама" разрешилась буквально на следующий день. Мы с совсем другим сотрудником ЦБ (который в том числе занимался поддержкой их электронных платежей в ком.банках) в ходе очередной плановой беседы, обсуждали некоторые технические особенности реализации их ЦБшной системы платежей и возможности её усовершенствования. И в ходе беседы тот сотрудник упомянул, в числе прочего, что они в ЦБ для определённых нужд файлового обмена используют в том числе бесплатную программу UUPC российской разработки, позволяющую передавать произвольные файлы через модемные соединения с одного компьютера на другой. Сюжет вышел почти смешной: вроде бы как "зверь сам бежит, да прямо на ловца!" Я конечно же высказал свою крайнюю заинтересованность в информации об этой программе. Тот ЦБшник охотно согласился передать мне дискетку с дистрибутивом, благо программа распространялась совершенно бесплатно, и дать свои консультации по минимальной настройке начальных конфигураций. Я откликнулся на эти предложения с благодарностью.

Дорвавшись в тот же день до дискетки с программой, немедленно стал раскапывать, что это такое. Выяснилась примерно такая картина: ещё в 1970-е, в OS UNIX в числе прочих, типичных для этой системы, маленьких специализированных утилит, выполнявших конкретные типовые задачи, была включена утилита UUCP (Unix to Unix CoPy), которая умела передавать файлы через телефонные/модемные соединения от одной системы Unix к другой. Их было несколько версий, для разных версий Unix. Позже, уже в наше время персоналок, нашим российским разработчиком (Чернов Андрей) по мотивам этих утилит обмена файлами была разработана своя похожая по смыслу утилита UUPC уже для MS-DOS. Заточена она изначально была прежде всего под сеть "Релком", но и в иных случаях иногда использовалась. Ну и внутренности, и интерфейс у UUPC тоже свои оригинальные были. Как и в случае с софтом ФИДО, UUPC была целым комплексом взаимосвязанных программ, с довольно сложным продвинутым функционалом. Но и в случае UUPC также можно было для простого обмена файлами ограничиться упрощённой конфигурацией, с минимальными настройками. За один-два дня мне успешно удалось при помощи и с подсказками упомянутого коллеги из ЦБ, поделившегося дискеткой, довести свою конфигурацию UUPC до работоспособного состояния, и успешно протестировать её в условиях собственного банковского офмса на паре модемов и паре телефонных линий. Выглядело это на экране примерно так:

Картинка конечна вышла ужасной, ну так года мои уже не те, чтобы ради одной красивой картинки организовывать реальный сеанс связи двух модемов в среде MS-DOS из программы 30-летней давности. Пусть будет хоть такая. Во-первых, на ней хорошо видно, что в моём демонстрационном случае программа с первой же попытки завершилась с ошибкой. Она просто не нашла у меня ни одного работающего модема. Во-вторых, эта картинка не отражает самого красивого момента работы UUPC - собственно сеанса связи. Во время сеанса, если связь устанавливалась нормально, то в нижней части экрана (где сейчас видна красно-жёлтая ошибка) начинали шустренько бежать слева-направо наперегонки две строки ярких разноцветных буковок. Каждая буква означала выполнение какой-то операции над очередным пакетом данных. Цвет буковок, если не ошибаюсь, как-то зависел от порядка операций над пакетами данных, и от успешности выполнения этих операций. Одна строка демонстрировала движение исходящих пакетов, другая - движение входящих пакетов. В норме эти две строки должны были бежать без длительных задержек и почти синхронно друг с другом, временами вырываясь одна чуть вперёд другой на несколько букв. Разумеется, ни от пользователей, ни даже от меня, вовсе не требовалось понимать значение ни самих бегущих букв, ни скрытый смысл их расцвечивания. Тем не менее, интерфейс UUPC во время связи, получился у разработчика весьма оригинальным, вызывал приятные эмоции, автоматически приковывал к себе взгляд пользователей. Тем более, что долго на бегущих буквах сосредотачивать внимание не требовалось - типичный обмен данными в нашей системе Клиент-банк на самом деле длился не более двух минут, часто в пределах одной минуты.

В итоге получилась вполне удобная, надёжная, и даже в некотором смысле красивая, транспортная часть, работающая под MS-DOS (или в окне DOS под Windows). И в банке, и у клиентов, использовалась ровно одна и та же программа UUPC, но с несколько разыми настройками. У себя в филиале мы на первых порах выделили ОДИН единственный модем для связи с клиентами. На работу с этим модемом настраивался один банковский экземпляр UUPC, который запускался (мной, вручную), подключался к своему выделенному модему и переходил в бесконечный (циклический) режим ожидания входящего звонка. На входящие звонки банковская UUPC снимала трубку своего модема, соединялась с очередным клиентом (если конечно тот нужный протокол соединения и действующие логин/пароль мог правильно указать), обменивалась накопившимися для/от этого конкретного клиента файлами, потом отключалась и снова переходила в режим ожидания очередного входящего звонка. 

Да, разумеется, в таком режиме работы нужно было и постоянную "личную" городскую телефонную линию этому модему предоставить, которой бы не пользовались никакие другие сотрудники филиала. Но к этому руководство уже и морально и планово-финансово было готово - линию планировали отдать специально под частые связи в сети Sprint. А тут от сети Sprint стали постепенно отказываться. Так почему бы и не передать освободившийся телефон для Клиент-банка? Правда, от Sprint не сразу отказались полностью - там ещё некоторое время оставался обязательный обмен телексами с ГО, но он занимал не более 5-7 минут в сутки. Никто не мешал на это короткое время отключить наш Клиент-банк, обменяться данными с США, а потом вернуть Клиент-банк на место. Паузу в единицы минут "занятости" линии клиенты особо и не замечали, от них же никто не требовал каждый раз набирать номер банка вручную, UUPC всё на автомате делала. Там ещё был мой личный маааленький прикольчик. Как раз в это время один мой одноклассник, с которым поддерживались регулярные приятельские отношения, проходил стажировку в США, в нескольких известных ВУЗах по очереди. И у него там в США был фактически единственный бесплатный способ связи с нами - сеть Интернет, к которой в Америке доступ (в научной среде) уже был, а вот у нас практически ещё совсем не было. Но вот у нашего "любимого" Sprint был работающий шлюз в сеть Интернет. Ну... Как работающий? Как обычно, во-первых очень странно работающий, с чудовищно-странной системой конвертации адресов и форматов писем из сети в сеть, во-вторых ИНОГДА работающий, а иногда и совсем НЕ работающий, но к этому я уже привык. Главное - у меня была лазейка бесплатно обменяться письмами с одноклассником в США. ;) Впрочем - это тоже мелочи и копейки. На работоспособность нового транспорта Клиент-банк моё пользование своим служебным положением никак не влияло (несколько личных писем - не в счёт).

Упомянул, что изначально в филиале на связь с клиентами через UUPC выделили только один модем с одной телефонной линией. Кажется - это ОЧЕНЬ МАЛО? Я тоже так думал. Готовился отстаивать перед начальством свою позицию, что дескать, другие варианты выходят ещё дороже. Но на практике всё оказалось совсем не так страшно! В нашей новой транспортной части предполагались краткие и быстрые сеансы обмена файлами, несколько десятков секунд, в худшем случае - единицы минут, после чего линия немедленно освобождалась. Фактически этой единственной телефонной линии с лихвой хватало на обслуживание нескольких десятков клиентов без заметных задержек. Первые жалобы клиентов на неприятную занятость нашего модемного "пула" (пула, ага, да, это я ещё им всем правду направо и налево не рассказывал, из скольки именно модемов наш "пул" на самом деле тогда состоял!) пошли, примерно на сороковом или пятидесятом подключенном клиенте. Но это уже было совсем другое время, другая финансовая ситуация. Мы уже были прибыльным филиалом, а система Клиент-банк реально доказала свою полезность и работоспособность. На этом этапе деньги на подключение дополнительной телефонной линии и покупку нового модема (это уже вообще копейки к тому моменту) были выделены немедленно и без малейших возражений. На двух входящих телефонных линиях мы успешно обслуживали около 90-120 активно работающих клиентов. Когда снова пошли жалобы на занятость модемного "пула", аналогично без вопросов докупили в филиал третью телефонную линию. Немного смешная ситуация вышла с тем, куда подключить третий модем - в стандартном офисном компьютере обычно только два COM-порта, куда втыкаются внешние модемы. Рассматривались разные варианты. Можно было вместо очередного внешнего модема подключить внутренний модем, который вроде как позволял бы разойтись со внешними по номерам портов. Можно было попробовать докупить недорогую плату расширение количества COM-портов (никто не пробовал, но в импортных журналах писали, вроде работает). Мне не понравилось ни то, ни другое. Я просто взял отдельный офисный компьютер, из числа самых первых филиальских машинок, уже частично разукомплектованный и готовый к списанию, немного довёл до ума, и подключил третий модем к этому почти "неучтённому", почти "бесплатному", и к почти дохлому компьютеру. Заработало. На трёх независимых входящих телефонах, мы без заметных нареканий могли обслуживать где-то 150-180 активных клиентов. Дальнейшее развитие той транспортной подсистемы в этом первом моём банке на этом прекратилось. Изменились и политическая и экономическая ситуации в стране. Технологии менялись стремительно и неузнаваемо. В 1999 году эта моя первая в жизни система Клиент-банк фактически плавно и мирно прекратила своё существование. Причём уже без моего участия, я уволился оттуда ещё в 1998. Но почти четыре года система полноценно отработала, в том числе достойно пережила сложные модернизации.

- Грустно, Ёж?

- Нет, Шеркало. Ну, то есть да, грустно, но в данном случае всё шло своим правильным порядком. Поэтому ты тут сильно активно не шерчи, а я продолжаю.

Про банковскую часть настройки почтовой программы UUPC в основном рассказал. Клиентам выдавалась ровно та же самая программа в той же самой комплектации (не забывал и авторскую документацию приложить, какая у меня была). Отличалась клиентская часть настройками в файлах конфигурации и способом вызова. Клиентская часть не запускалась в постоянном режиме, не ожидала входящих звонков. Нет, она запускалась вручную по инициативе клиента, фактически нажатием одной кнопочки в основной клиентской программе, после запуска пыталась дозвониться до телефонов банковской части, если получалось обменивалась с банком файлами туда и сюда, и радостно отключалась, не забыв запротоколировать сеанс работы в логах. Настройки системы записывались нами в текстовые конфигурационные файлы системы, выполненные разработчиком в стиле конфигураций UNIX. Изначально конфигурационные файлы настраивались нами руками при установке системы. Впоследствии могли нами же редактироваться, в том числе дистанционно, не выходя из банка (ниже будет подробнее). Выполняли тщательную настройку модема клиента с учётом всех его местных условий. Чаще всего настройка заканчивалась выбором правильного COM-порта и подстановкой типовой командной строки заранее оптимизированной для уже известного типа модема. Но иногда настройка модема могла вылиться в целый детективный роман продолжительностью несколько недель, впрочем, это тема для отдельного рассказа. 

Телефоны банка, куда клиентская часть дозванивалась для связи, указывались в том же текстовом файле конфигурации. Мог быть указан как минимум один телефон для дозвона, но можно было указать и несколько разных. В случае нескольких телефонов UUPC перебирала весь доступный список по очереди: если один телефон занят или не отвечает, программа автоматически звонила на следующий. Сигнал "занято" от сигнала "нет ответа" UUPC отличала очень чётко. При "занято" программа мгновенно сбрасывала соединение и сразу переходила к следующему доступному номеру, а при не ответе ждала результата попытки 20-30 секунд. Количество попыток дозвона тоже легко настраивалось произвольным образом. Можно было настроить дозвон "до победного конца", обычно мы так и делали (разумеется, с возможностью ручного прерывания попыток по хорошо заметной кнопочке), а можно было и автоматически выключать дозвон, если после N попыток связь не удалась. Опять же очевидно, что все попытки дозвона грамотно логировались, и моя основная программа эти логи после завершения сеанса связи просматривала, чтобы определить успешность соединения. А при необходимости, я мог и получить связные логи целиком себе для внимательного анализа.

Для соединения с банком клиентская часть UUPC предъявляла логин/пароль, которые мы опять же записывали в её конфигурационные файлы при настройке открытым текстом (кстати, в предыдущем варианте Sprint было точно то же самое). Здесь у меня опять работала та логика, которую я ранее описывал в главе про PGP. Ну нет смысла мне лично на ровном месте изобретать велосипед и мучительно придумывать способ, как бы прямо на собственной коленке скрыть пароль, который изначально был записан в открытом текстовом файле. Да любая попытка доморощенным способом скрыть пароль, только лишний раз привлечёт толпу старательных злоумышленников, как запах капелек крови из пореза привлекает стаю голодных акул! Да пусть этот несчастный пароль валяется себе в текстовом файле простым открытым текстом! Что с ним дальше-то злоумышленник сможет сделать??? Ну допустим, подсмотрел страшный злоумышленник пароль некоторого клиента. Допустим дозвонился до модема банка, успешно предъявил там чужой логин/пароль. Допустим, это сработало. И? И дальше ЧТО???! А дальше от злоумышленника ожидают на вход файлы, подписанные правильной ЭЦП (публичный ключ для проверки ЭЦП уже жёстко выбран исходя из ранее предъявленного логина клиента). Причём с криптостойкой ЭЦП, которая с почтовым паролем никаким образом принципиально не связана. И как только от злоумышленника будут получены на вход в банк файлы БЕЗ правильной ЭЦП, так тут же все сторожевые точки безопасности банка забьют тревогу во все возможные колокола! А оно злоумышленнику надо? Он этого хотел?

Ладно. Допустим злоумышленник не хотел отправлять фальшивые платежи. Допустим он всего лишь хотел получить себе файлы с конфиденциальной информацией о клиенте? С какой там информацией? Ах, ну да, он хотел получить текст выписки с банковского счёта клиента, ничего более интересного там и не было. Ну допустим. Но есть проблема - полученный злоумышленным путём текст выписки шифрован на публичном ключе клиента, а дешифровать его можно только получив доступ к секретному ключу стойкой криптографии! Хи-хи. Что ещё остаётся злоумышленнику? Ну, зная связной пароль, он сможет регулярно "очищать" почтовый ящик клиента в банке - принимать чужую шифрованную почту на себя, а потом выбрасывать её в мусорную корзину, поскольку дешифровать всё равно не получается. Только опять же: зачем?! Ну раз сможет. Ну два раза сможет, просто ради мелкой заподлянки. А на третий раз уже начнётся целенаправленное расследование: куда это регулярно бесследно пропадают файлы конкретного клиента? И тут потенциальному злоумышленнику придётся плохо! И здесь ничего не светит! Получается, что секретить пароль связи - не очень существенная мера. Скорее полезно так, для порядка, для защиты от полного идиота, чем для защиты от настоящего хакера. Ну и пусть себе скромно лежит почти бесполезный пароль в настроечном файле открытым текстом. На практике, эти мои соображения оказались верны. Я уже раньше говорил, что у нас были зафиксированы единичные случаи попыток взлома криптографической части (100% из них - злоумышленные инсайдеры со стороны клиента, получившие несанкционированный доступ к ключевым файлам). Но вот явных попыток взлома транспортной подсистемы UUPC мы в нашем банке не фиксировали ни разу за всю историю работы. Хотя пароли там и лежали свободно в текстовых файлах, просто никто этого не афишировал. Тут примерно такая аналогия: нет смысла вешать сложный банковский сейфовый замок на обычный ивовый плетень вокруг огородика с грядкой репы.

Подвожу итог: транспортная часть системы Клиент-банк на базе программы UUPC оказалась (пусть и со второй попытки, кто, бывает, не ошибается?) очень удачной. Опять же можно говорить о попадании, если и не точно в "десятку", то уж в "девятку", как минимум! Всех уже подключенных к Sprint клиентов, мы немедленно перевели на почту UUPC. Новые организации подключали только по этой технологии. Поток жалоб на качество связи сократился на порядок. О чудовищных тарифах в десятки и даже сотни долларов в месяц забыли как о страшном сне (за исключением кажется единственного клиента, который, как и наш филиал, по собственной воле некоторое время арендовал у Sprint виртуальный телекс для участия в валютных торгах, но тут уж я не виноват)! Жалобы конечно прекратились не совсем полностью - технические проблемы со связью иногда всё же возникали, как же без этого. Но теперь они возникали на порядок реже, и больше не выглядели мистически-загадочным пропаданием файлов в "чёрную дыру" или в "Бермудский треугольник". UUPC работала в нормальных условиях безупречно надёжно, а при возникающих сбоях выдавала на экран и в лог-файлы вполне грамотную, понятную и достаточно полезную диагностику. Даже такие сравнительно малоопытные сотрудники тех.поддержки, как я, по этой диагностике быстро могли определить причину возникшей проблемы и предложить работающие варианты решения. Связь с клиентами перестала быть для нас глухо-немым "чёрным ящиком", стала прозрачной и управляемой.

Последнюю пару абзацев хочу посвятить дальнейшему использованию UUPC. Несмотря на бесплатность, надёжность, удобство настроек, у этой программы был и один заметный недостаток - она работала под чистым MS-DOS и обращалась к модему, как к внешнему устройству, в реальном режиме работы процессора i8086/88. Для второй половины 1990-х годов, когда мы её и внедряли (напомню, фактически это был период примерно декабрь 1995 - январь 1996), прямое аппаратное обращение программы DOS к внешнему устройству было ещё совершенно нормальным, и в 99% случаев отлично срабатывало. Как в чистой MS-DOS, так и в оконных сеансах DOS в ранних системах Windows 3.x/Windows 9x срабатывало. Но вот дальше постепенно начинались технические проблемы - большинство более современных операционных систем, получавших всё большее распространение, в том числе WindowsNT/Windows2000/WindowsXP, всё сильнее и сильнее ограничивали прямой доступ сторонних программ к аппаратуре компьютера. Нормальный запуск старой UUPC под WinNT всё чаще вызывал серьёзнейшие проблемы, требовались очень длительные и индивидуальные "шаманские танцы с бубном". А количество новых ОС постепенно возрастало. Разработчики UUPC, насколько мне известно, пытались обновить свою почтовую программу, в том числе выпускали какие-то версии под систему IBM OS/2, но для нас эти факты были уже не такими интересными. Становилось понятно, что с началом 2000-х годов UUPC теряет для нас свою изначальную простоту и универсальность, а следовательно и актуальность.

При организации в конце1999, начале 2000 нового филиала уже совсем другого московского банка, в новой системе Клиент-банк (подробностей в этом рассказе о ней НЕ будет), я изначально принял решение от транспорта на базе UUPC отказаться, из-за отсутствия перспективы. В то же время транспорт, который предлагал нам ГО нашего нового банка (да у них уже был свой новенький и даже ПОЧТИ работающий Клиент-банк ("почти работающий" - крайне мягко сказано!), всё-таки почти 5 лет с моих первых изысканий прототипа уже минуло, москвичи вдруг прозрели!), вновь оказался явно неудовлетворительным. Проблем там была масса, включая засунутую псу под хвост безопасность, при абсолютном непонимании происходящего со стороны команды якобы-разработчиков, но я сейчас не об этом. Повторилась ситуация 1995 года с сетью Sprint. После подключения первых 5-6 клиентов по предлагаемой из Москвы технологии, я плюнул на весь творящийся вокруг дебилизм, и сотрудник нашего филиала Синчилин Дмитрий получил задачу бросить все дела и написать собственную транспортную программу. С этой задачей Дмитрий как обычно справился очень быстро и идеально качественно. Он написал собственную "звонилку" с модема на модем, которая позволяла спокойно обмениваться файлами, по сути повторяла ранее востребованные нами технологии UUPC (ничуть не хуже и не менее надёжно), но при этом была полностью написана на Win32-API и не имела никаких проблем совместимости с современными операционными системами. Ещё несколько лет мы успешно проработали на этой собственной транспортной программе, а ко второй половине 2000-х сама технология прямого дозвона с модема на модем стала мало актуальной. Получила, наконец, широкую популярность и повсеместное распространение сеть Интернет, и встроенные в ОС готовые "бесплатные" средства доступа к ней. На этом мой обзор транспортной части UUPC, надеюсь, пора заканчивать!

- Всё ???!

- Шеркалы, молчать! Что, забыло, что я ещё основную часть программы вообще не затрагивал?!

Программа на FoxPro, для начала клиентская часть

Я уже некоторое время, написав приличный объём текста о системе Клиент-банк, всё-таки до сих пор не придумал, как правильно называть именно этот модуль системы? Основная часть? Основная программа, написанная мной на FoxPro? Интерфейсный и интегрирующий модуль? Это некий центральный модуль программы, который запускался первым, а уже из-под себя, по командам пользователя, запускал другие модули, включая транспорт и криптографию, и анализировал результаты их выполнения. Назову условно этот модуль "основной программой". Писал этот модуль я сам. В качестве инструмента использовал распространённую среду разработки FoxPro 2.x for DOS. Среда разработки позволяла очень быстро и эффективно делать программы под MS-DOS (прекрасно запускающиеся и в оконном режиме под ранними Windows), с быстрой разработкой оконного (в режиме текстовой псевдографики) интерфейса пользователя - с окошками, менюшками, кнопочками и т.п., с управлением и мышкой и клавиатурой. Плюс база данных (файлы *.dbf), плюс мощные инструменты доступа к внешним файлам и ресурсам, плюс запуск внешних приложений и анализ их результатов. В общем - чего душа ни пожелает, всё уже есть (только в текстовом режиме экрана). Была некоторая проблема с лицензионностью программы, но, во-первых, в те времена это было ещё не очень критично, таких "шустрых программистов", как я, пишущих на dBase, Clipper, FoxPro, Clarion тогда половина страны была. Никто не собирался ловить за руку и сажать каждого первого. А во-вторых, нелицинзионность в самом крайнем случае, касалась только лично меня, все остальные люди, запускавшие написанные мной программы, были с точки зрения лицензионного соглашения Fox Software абсолютно беленькие и чистенькие. Ах да, в третьих, в последние дни 1997 года я имел случай оказать своему банку некоторую услугу. Я в ГО, в Москве, отработал потрясающую по интенсивности программу в несколько дней экстренной технической помощи сотрудникам других филиалов нашего банка. В том числе с круглосуточными, включая бессонные ночёвки в офисе, дежурствами. Я просто делал то, что считал дОлжным делать на тот момент. Но кажется, кто-то из москвичей, работавших тогда по ночам бок-о-бок рядом со мной, посчитал моё выступление достойным. Мне неофициально (была сказана единственная скупая фраза: "заслужил, держи!") преподнесли в подарок дистрибутивный комплект дискет FoxPro 2.6, с лицензией Microsoft, зарегистрированный на наш банк. Как обычно, ценный подарок у меня не сохранился, канул в бурлящие воды жизненного потока.

Ладно, пусть будет "основная программа". На самом деле, я не знал, какой именно она должна быть. Как я уже говорил сильно раньше, все мои попытки посмотреть на готовые образцы проваливались. В других банках готовых образцов не было - они сами понимали в том, как должен выглядеть Клиент-банк на пару порядков хуже меня. Если я просто совсем ничего не понимал, то "специалисты" из других банков были уверенны, что всё очень хорошо понимают и делают всё как надо. А когда я начинал спрашивать, а почему интерфейс реализован через задницу, а не традиционным путём, а почему не предусмотрено того или другого полезного справочника, а почему формат документов не соответствует требованиям ЦБ и т.д., мне тут же отвечали, что это потому что я сам идиот, а нормальные клиенты, если их долго пинать, то они через годик-другой ко всему привыкают, вопросов больше никогда не задают, а кто продолжает задавать, тех отправляют на длительное обслуживание в банки Чукотки, что ЦБ выпускает столько вариантов требований, что всем на них всегда пофигу, что справочники замучаешься обновлять, что эти электронные платежи никому и никогда не были нужны, кроме чеченских хакеров, но те чаще телексы используют для своих преступлений, так им проще и дешевле... Уфффф... Никого случайно не утомил?

Был образец от местного ЦБ, о нём я уже тоже говорил. Некоторые технические моменты были реализованы вполне грамотно, но вот как раз центральная интерфейсно-интегрирующая часть... Хмммм... Ну вот ЭТА штуковина, в которой явно двух-пудовые чугунные кувалды применяли для тонкой шлифовки и стрижки коготочков у нежных собачек чиа-хуа-хуа, вот это точно не есть образец для подражания!!! Никогда и ни за что!!! Вопросы к первым клиентам мне тоже здесь мало помогали - они тоже никогда толком нормальной системы Клиент-банк не видели, плюс имели весьма смутное, нечёткое представление о собственных пожеланиях. Мне оставалась импровизация с итерационным подходом: попробовал так, поругали, принял к сведению, исправил, попробовал этак. Снова поругали, но уже мягче и в иных выражениях. Ну и дальше в том же цикле, аналогично.

Изначально, как уже говорил, изменения в программе требовались очень-очень часто, чуть не по несколько штук в день. Сначала это были большей частью исправления моих собственных недоработок, точнее "недодумок" - когда я что-то существенное заранее не предусмотрел или неверно оценил. Очень быстро относительное количество моих ошибок и недоработок сокращалось по мере исправления и улучшения понимания требований, но вот общее количество необходимых обязательных немедленных исправлений сохранялось на почти постоянном уровне. В первые же месяцы существенных исправлений в основной программе потребовала замена почтового транспорта со Sprint на UUPC. Там ведь чуть ли не половина логики программы поменялась! Полностью формирование/разбор/проверку входящих и исходящих писем (это же делала основная программа, почта лишь за сам обмен по телефону отвечала) требовалось осуществлять абсолютно иным образом. Использовалась совершенно другая структура почтовых каталогов. Иначе вызывалась транспортная программа и диагностировались итоги её работы.

В начале 1996 года мы более-менее стабилизировали работу нашей основной программы с UUPC, с этой стороны поток необходимых доработок тоже сошёл почти к нулю. Но никогда не позволял расслабляться ЦБ. Для начала, наш местный ЦБ продолжал постоянно активно совершенствовать (имели право, ведь не я же один такой настырный активист, да?) свою уникально-местную систему электронных платежей, которая внедрялась с середины 1995 года, о чём я ранее неоднократно уже писал. И многие их усовершенствования активно влияли то на форматы обмена документами, то на регламент обмена, то на регламент контроля различных реквизитов электронных документов. Все эти регулярные изменения доводились до нас, коммерческих банков, в приказной форме. Мы обязаны были их соблюдать. Обычно это требовало соответствующих доработок в нашей основной программе.

А потом местный ЦБ решил, что та их начальная версия системы от середины 1995 года была слишком сырой и неудачной, и они начали с частотой примерно раз в 1-2 года полностью переделывать свою местную систему электронных платежей под абсолютно новые технологии, с новыми особенностями документооборота и новыми требованиями. Здравствуйте, очередные доработки! А тут и московский ЦБ тоже начал просыпаться. В продолжении 1996 года они в своей далёкой столице, наконец, сообразили, что электронные платежи в России всё-таки придётся когда-нибудь массово внедрять. Готовой системы платежей у них пока не было даже в аванпроекте, но законодательную базу под будущую Федеральную систему платежей начали заранее готовить как раз в то самое время. И эти всё учащающиеся централизованные изменения в федеральном законодательстве опять же стали регулярно требовать от нас вносить доработки в наши программы.

Я внедряю своего троянского коня

Итак, на практике быстро выяснилось, что вносить изменения в работающую на клиентской стороне часть системы Клиент-банк требуется очень часто и у всех (или у многих) клиентов сразу одновременно. И ведь "вносить изменения" - это не значит просто взять и поменять исполняемый файл основной программы с устаревшей версии на более свежую, нет! Там всё построено на локальной базе данных с кучей взаимосвязанных таблиц *.dbf, плюс структура подкаталогов, плюс сторонние arj, PGP, UUPC со своими настройками, подкаталогами и конфигурациями. В ту же таблицу базы данных не добавишь простым копированием новые поля, индексы или проверки целостности. В том же текстовом файле настроек UUPC не поменяешь просто так вызываемый телефон банка с одного номера на другой, без целого разбора/парсинга этого довольно большого файла. А если ещё вспомнить о необходимости адекватно отследить корректность попытки апгрейда, то вообще жутковато становится. Ни о каком простом копировании новых файлов поверх старых речь и близко не идёт! "Внести изменения" в клиентскую часть программы, это достаточно комплексная задача, требующая в общем случае весьма индивидуальной (а бывает что и уникальной) работы со многими файлами данных различными индивидуальными способами! 

Понятно, что для самых первых клиентов я все обновления программ действительно выполнял самостоятельно вручную. Да обновлений получалось много, на первых порах даже очень много. Но во-первых, клиентов ещё было очень мало, меньше пальцев одной руки. Во-вторых, выезды, при таком небольшом количестве мест, удавалось организовывать на служебной машине (иногда банковской, иногда клиентской, не важно). В-третьих, первые клиенты подбирались из числа сознательных тестеров, в простых случаях им действительно можно было элементарно вручить дискетку с новой версией исполняемого файла программы, и быть уверенным, что ни правильно этот файл скопируют.

Но где-то на пятом-шестом-седьмом клиенте стало отчётливо ясно, что дальше такая схема "ручного" обновления работать не сможет НИКАК! И я подготовил своего личного, прирученного, троянского коня. Упомянутый ранее переход с почты Sprint на транспорт UUPC был последним обновлением, которое я выполнял вручную, с обязательным выездом к клиенту. И во время этого ручного перехода на UUPC, я одновременно устанавливал обновляемому клиенту своего троянского коня. Как и другим, вновь подключаемым клиентам. На этом мои регулярные выезды к уже работающим клиентам оказались сведены к минимуму. Дальше вместо затратных по времени выездов в 95% случаев успешно работала троянская лошадка. 

Вообще, "троянский конь" в компьютерной терминологии - один из вариантов зловредных (как правило) компьютерных программ, вариант компьютерных вирусов. Основная особенность троянского коня, отличающие его от других вирусов: он не умеет распространяться с одного компьютера на другой самостоятельно. Вместо этого троянский конь ("троянец") маскируется (при помощи своего автора, разумеется) под нужную и полезную программу. Потенциальная жертва самостоятельно, добровольно, скачивает себе программу с троянским конём, сама устанавливает и запускает её на собственном компьютере, рассчитывая на выполнение некоторых ожидаемых от программы функций. А вот уж дальше троянец исполняет заложенную в него программу по воле его автора - может делать что-то полезное, а может и зловредное, это уж что там автор заранее предусмотрел. Главное, что вся дальнейшая работа троянца происходит уже помимо воли потенциальной жертвы. В общем, прямая аналогия со скульптурой Троянского коня, которую по легенде жители города Троя добровольно притащили к себе на центральную площадь в качестве "подарка". А ночью из статуи коня выбрались заранее засевшие в ней диверсанты, и открыли ворота города врагам. Жертва может даже и не догадываться, что оказалась жертвой.

Так вот, я уже в самом начале 1996 года встроил в стартовую часть основной программы моей системы Клиент-банк типичного "троянца". Нет, разумеется, никаким злоумышленником я не был. Ничего плохого своим клиентам не желал и не делал. Более того, я своего троянского коня даже особо и не скрывал. Всё изначально запускалось из обычных командных файлов *.bat, *.cmd совершенно открытым текстом, "анализируй - не хочу!", просто мечта ленивого безопасника. Но мне позарез нужно было получить полный дистанционный (не выходя из банковского офиса) контроль над всеми файлами, настройками и поведением клиентской части нашей системы Клиент-банк на компьютере клиента. И я этот контроль получил. Каждый раз, при очередном старте программы, запускалась изначально не основная программа, а специальный "троянский" командный файл. Этот командник проверял структуру входящей почты клиентской части на предмет наличия там файлов со специальными, заранее известными именами, оставшимися от последнего предыдущего сеанса связи. Если такие файлы находились, они откладывались отдельно в специальную папку для одноразово исполняемых файлов, и оттуда в порядке очереди запускались. Там могло быть всё что угодно. Могли быть заранее подготовленные мной командные файлы, которые исполняли произвольные команды MS-DOS на клиентском компьютере. Могли быть исполняемые программы на FoxPro, имеющие в том числе полный доступ к базе данных клиентской основной программы, и способные модифицировать её любым нужным образом. Могли быть (хотя это крайне редко требовалось) и вообще любые исполняемые программы любой разработки, в том числе сторонней, плюс любые файлы с требуемыми для всего этого зоопарка дополнительными данными. Запускаемые при обновлении команды и программы могли собрать какую угодно информацию и статистику с клиентского компьютера, затем упаковать её в отправляемый для банка пакет (опять же со специальным именем файла) и самостоятельно вызвать внеочередной сеанс связи с банком. Т.е. я мог не только отправить что угодно на клиентскую сторону и исполнить там, но и тут же получить ответные файлы с результатами и статистикой для анализа проблем.

В момент работы "троянской" подсистемы обновлений, основная программа была ещё не запущена, никто не мешал в этот момент поменять её исполняемый файл, а её основная база данных ещё не задействована, соответственно можно было её по желанию модифицировать и даже полностью реструктуризировать. Никто в этот момент не мешал и редактировать в автоматическом режиме конфигурационные файлы. На разных этапах работы системы обновлений была предусмотрена также выдача клиенту на экран ярких сообщений-allert'ов с инструкцией, что требуется делать и чего нужно ожидать, опять же управляемых из банка. После того, как "троянец" полностью завершал все пришедшие обновления, временная папка исполняемых файлов очищалась, и основная программа клиентской части запускалась в своём обычном режиме. Теперь, как обычно в этой части текста, будет ещё пара сопровождающих замечаний.

Троянец 1: А что, никто из грамотных клиентских админов или безопасников, ни разу не ВОЗМУТИЛСЯ явным нарушением безопасности? Нет! Представляете себе, никто за несколько лет НИ РАЗУ не возмутился!!! Ни единой жалобы на нарушение безопасности с нашей стороны не было, ни мне лично, ни в адрес начальства. Хотя, повторюсь вся троянская программа там свободно лежала в командных файлах совершенно открытым текстом. По моим ощущениям, примерно 90% с хвостиком клиентов о встроенном троянце либо совсем не догадывались, либо вообще о подобных материях никогда не задумывались. Из оставшихся "догадывающихся" 10%, примерно девять десятых частей была пофигистами - они считали, что "жираф большой - ему видней", что если банк встраивает в свою программу троянец, то значит так и надо (кстати, если честно, то я сам отношусь именно к этой категории). Пусть уж лучше добрый и честный банк себе вирусы-трояны пишет, чем глупый, но злой, хакер-грабитель. Ну и наконец, оставшиеся чуть менее 1% всех клиентов о трояне тоже догадывались, но были как бы себе на уме. Дескать, раз банк встраивает в свою программу откровенный троян, то и флаг тому банку в руки! Мы возмущаться не будем, просто запустим его вирусную программу в песочнице, пусть их троян сколько угодно в песочнице резвится. У этих "грамотных" админов мой открытый троян действительно не мог сработать. Кому получилось с того хуже - второй вопрос. Он всплывёт в следующем абзаце. Впрочем, я этих админов отнюдь не виню, они нормально выполняли свою работу.

Троянец 2: И что, помог тот троянец? Игра с не совсем законным огнём стоила свеч? ДА!!! Стоила! Затея с троянцем окупила себя многократно десятикратной экономией на выездах! Да и штат отдела тех.поддержки без этой фишечки пришлось бы раздувать ещё минимум на пару человек, что тогда уже выглядело не совсем реалистичным. Напомню тут начальную ситуацию: шеф предлагал всемерно развивать систему Клиент-банк, чтобы перевести основной документооборот в электронные платежи. Электронная связь позволяла и клиентам быть довольными (не нужно в офис на окраину города мотаться лишний раз), и на операционистках, обслуживающих клиентов лично в банке, экономить - можно было нанимать в бухгалтерию банка на 2-4 операционистки меньше, экономия заметная. А лишняя телефонная линия с модемом стоит сильно дешевле, чем зарплата даже одной самой юной операционистки-стажёра. Но это всё при условии, что ездить по сотне-другой клиентов, чтобы регулярно чинить-обновлять у них ежедневно ломающиеся программы, не требуется. А если требуется? Тогда придётся нанимать ещё 2-3 ИТ-специалистов на выезды тех.поддержки. Но они обойдутся дороже, чем 2-4 дополнительные операционистки! Так что же делать? Получается, что при интенсивной необходимости выездной тех.поддержки электронный документооборот может стать невыгодным? Да! Это именно так! И во многих других филиалах нашего же банка (да и не только у нас) именно к этому и пришли. Решили, что дешевле будет нанять в офис лишнюю пару-тройку девочек-операционисток (которых можно после испытательного срока и уволить, без объяснений, заменить на новых), а к электронным платежам пусть подключается десяток совсем отмороженных идиотов-энтузиастов. Им дорогая тех.поддержка в товарном количестве и не понадобится.

Ну вот, а мы, с подачи моего шефа и с моего единоличного решения, пошли по пути внедрения в программу троянского коня для тех.поддержки. и это реально помогло! объём необходимой работы и требуемых выездов сократился минимум на порядок. Если помните, в части рассказа про UUPC я упоминал, что мы в ходе развития системы расширили свой модемный пул банка с единственного телефона до трёх штук, а все эти номера телефонов прописывались у клиентов в настроечных файлах? Так вот, все обновления настроек клиентов на новые телефоны мы выполняли на 100% дистанционно, практически без выездов. Но самый потрясающий пример случился на рубеже 1997-98 годов. С первого января 1998 года ЦБ внедрял во всех банках по всей России абсолютно новую систему банковского бухгалтерского учёта, практически НИКАК не связанную с предыдущей! То что работало до конца 1997, и то, что должно было начать работать с 01.01.1998, походило друг на друга примерно как дятел на медузу. Менялся план счетов (даже сама размерность и нумерация счетов), менялись абсолютно все формы документов, менялись формы и состав реквизитов платежей, менялись все формы отчётности и требования к ней! От старых технологий, времён 1997 года не должно было остаться вообще ничего, кроме, пожалуй, основополагающего средневекового принципа двойной бухгалтерской записи имени Луки Пачоли.

Изменения были ГЛОБАЛЬНЫМИ. Это было страшно, это был ещё и жесточайший цейтнот! Все специалисты всех банков, включая ЦБ, бегали в жутком мыле, невзвидев света. Клиенты тоже волновались страшно. Все бухгалтерские программы всех уровней по всей стране где полностью переделывались на новые версии, а где просто менялись на совсем другие (только в части банковской деятельности, разумеется, бухгалтерия предприятий в тот момент существенно не менялась)! Но наших клиентов Клиент-банка я успокаивал: "Всё будет хорошо, просто не забудьте в начале января, на каникулах, один-два сеанса соединения с банком провести по телефону. Всё должно у вас само заработать". 1997 год доработали на старом софте. В первые дни 1998 года разложил клиентам в почтовые ящики подготовленное обновление с полностью новой версией программы. Его должен был грамотно, по шажочкам, установить тот самый встроенный троянец. Потом удалось на паре клиентов это обновление оперативно проверить. Выявилось несколько незначительных ошибок. Я их быстренько исправил, выложил чуть изменённое обновление. А потом, в первый рабочий день 1998 года на наш отдел с утра посыпался вполне ожидаемый шквал панических телефонных звонков клиентов:

- Но что?! ЧТО нам теперь делать???!!! КАК нам теперь работать с банком???!!!

А мы, всем отделом, по очереди, спокойно брали паникующие телефонные трубки, и медленно отвечали специально выдержанно-ленивым тоном:

- Что делать? Да ничего особенного не надо делать! Делайте всё как всегда: сначала выполните сеанс связи с банком, для получения входящей почты, потом полюбуйтесь, как программа перезапустится, а потом продолжайте работать как и раньше, как обычно работали, чего волноваться-то?

И ведь сработало! СРАБОТАЛО!!! Шеркало, ты не поверишь, какое это было невероятное, просто фантастическое наслаждение для меня, вот так, немного наиграно, но вполне честно, заслужено спокойным ответом "а что, разве у вас что-то не работает сегодня с утра?" гасить всеобщую панику бухгалтеров!

На начало 1998 года у нас было примерно 130 работающих клиентов. И у подавляющего числа из них сложнейшее обновление программы на более новую версию, в которой полностью поменялись все внутренности, прошло успешно в автоматическом дистанционном режиме!!! Просто фантастический результат! С таким не стыдно было бы и в программах космических полётов поучаствовать! ;) Разумеется, были и единичные клиенты, примерно штук семь, у которых автоматическое обновление всё-таки не сработало. К таким пришлось выезжать на место, разбираться. Но ведь 7 выездов вместо 130 выездов - гигантская разница, согласитесь! Результат выездов показал почти у всех "несработавших" клиентов одну и ту же картину. Это были те самые, упомянутые чуть выше, "хитрые" системные администраторы локальной сети клиента, которые самостоятельно обнаруживали в составе нашей программы троянского коня, и молча блокировали его работу тем или иным способом. В этих случаях, после ручного исправления конфигурации, расставались с "хитрым" админом корректно, но с ехидным взглядом в глаза. В самом деле, ситуация получалась несколько двойственная. Вроде бы человек всё правильно сделал - обнаружил потенциально вредоносную программу и заблокировал её. Молодец, да? А с другой стороны, тем самым он создал кучу дополнительной работы и себе самому, и сотрудникам банка, и нормальное функционирование бухгалтерии своего предприятия на пару дней на ровном месте тормознул, причём в самый ответственный момент. А оно надо было? Его об этом начальство просило?

Ну и традиционно, последняя фраза про троянских коней. В начале 2000 года, я уже в другом банке (в местном филиале другого банка) внедрял уже другую систему Клиент-банк. Технически она была устроена иначе, хотя по общему принципу деления на модули и похоже, но внутри конструкция иная. В частности её "основная программа", запускавшаяся на компьютере клиента, была написана сторонним разработчиком под Windows, исходных текстов её у банка не было. Тем не менее, даже в эту "закрытую" программу я мог в значительной мере вмещаться - её локальная база данных была для меня открытой книгой, там я мог вытворять что угодно по своему желанию. Впрочем, здесь речь не об этом. А о том, что к этой "закрытой" программе стороннего разработчика я первым же делом, уже наученный прошлым опытом, не дожидаясь видимого проявления реальных проблем, присобачил своего троянского коня. Мой новый троянец немного технически отличался от предыдущего, но сохранял все основные, проверенные временем принципы: написано всё было абсолютно не скрываясь, в обычных командных файлах *.bat, *.cmd, совершенно открытым текстом. Запускался троянец перед началом выполнения основной программы (чтобы можно было обновлять любой файл, пока он ещё не открыт программой), а также во время работы подсистем криптографии и транспорта. В смысле, сам ярлычок запуска программы, Клиент-банк, я переделал так, чтобы он указывал не на саму программу, а на отдельный командный файл, а уже из него сначала запускался мой троянский конь, анализируя и запуская, в свою очередь, полученные в предыдущем сеансе связи пакеты обновлений/исполнений, если таковые были, а уже после отработки всех троянских команд, запускалась сама программа стороннего разработчика. Запуск же троянца до и после работы транспортной и криптографической частей выполнялся ещё проще. Там сами разработчики программы предусмотрели запуск внешнего командного файла, чтобы организовать максимально гибкую для банка работу с этими сложными подсистемами. Разумеется, оригинальные примеры реализации этого командного файла от имени разработчика выглядели крайне добропорядочно, но я тут же встраивал туда вызов и своих троянских блоков команд, в подходящих местах.

Результат оказался ровно такой же, как и в предыдущем случае. Никто из клиентов на присутствие троянца ни разу не пожаловался. А необходимость личных выездов к клиентам для обновлений и исправлений снизилась на один-два порядка! Впрочем, это уже был наш последний троянский конь. Все последующие версии Клиент-банк, которые мы использовали, организовывались как "тонкие клиенты" (т.е. интерфейс клиентской части открывался непосредственно в окне интернет-браузера, а все необходимые данные подставлялись в это окно и обрабатывались затем, уже сервером со стороны банка), поэтому необходимость технической поддержки способом подмены файлов с участием локальных на компьютере клиента троянцев, просто исчезла. Пропала востребованность этой устаревшей технологии.

Банковская часть (бэкенд)

До сих пор старательно обходил стороной этот вопрос. Он на самом деле большой, сложный и сумбурный но попытаюсь кратко.

Первые бета-тесты бэкенд

Это я уже упоминал в предыдущем тексте. Изначально, чтобы хоть как-то тестировать работу самых первых клиентов в самые первые дни внедрения, нужна была какая-то программа, которая бы со стороны банка ловила клиентские платёжные поручения. Написал что-то простое, одноразовое на FoxPro. Ну поймала эта программа входящий от клиента платёж, а дальше что с ним делать? А ничего! Точнее - пока ещё ей толком нечего делать. Программа этот платёж распечатывает на принтер (благо со свободным на минуточку принтером в свеженьком, едва начинающем работать банке, и нет особых проблем). Там же впечатываются данные: от кого и когда именно принят платёж. И всё. А потом этот бумажный листок с платежом передаётся девочке-операционистке, обслуживающей счёт этого клиента, и та работает с платежом ровно так, как если бы клиент сам привёз в банк этот платёж на стандартном бумажном носителе. Только вместо личной подписи и печати клиента, на бумажном платеже стоит моя подпись - я лично подтверждаю, что все полагающиеся проверки ЭЦП клиента выполнены успешно (впоследствии от этого быстро отказались, ограничились типовой надписью об успешности проверки ЭЦП от имени сервера филиала, при условии, что эту успешность в любой момент для любого платежа, можно в присутствии комиссии легко перепроверить). 

А потом вечером, или в свободную от клиентов паузу, эта операционистка приносит мне листок, где отмечено, какой из платежей "моих" подопечных успешно принят и оплачен, а какой отказан. Или даже не приносит листок, а просто встаёт над плечом и диктует. А я, сверяясь с её данными, вручную в своей примитивной программулечке формирую на каждый платёж положительную или отрицательную квитанцию (программа дальше по отдельной кнопочке автоматом формирует из них исходящие почтовые пакеты для клиентов). Вот и вся "автоматизация"! Понятно, что такая технология считаться приемлемой никак не могла! Какой уж тут, нафиг, Клиент-банк, если практически всё делается руками и сопровождается бумажками?! Я этот факт отлично понимал! Но ведь это же были только первые дни тестового внедрения!

АБС "Садко", но для начала электронные платежи с ЦБ

Прежде, чем рассказывать, как дальше я совершенствовал банковскую часть Клиент-банк, нужно напомнить, какие вообще программы были основными инструментами для банков. Так вот, в каждом банке есть Самая Основная Банковская Программа (все слова пишутся с заглавных букв, а читаются обязательно со священным придыханием в голосе!) Шучу! В банке есть, обычно одна основная программа, именуемая АБС - Автоматизированная Банковская Система. Иногда большая часть функционала бухгалтерского учёта в банке ведётся в единой АБС. К этому, обычно стремятся, но не всегда так получается. Бывает, например, что некоторые части банковского учёта, например обслуживание сети банкоматов и платёжных терминалов, выносятся в отдельные, почти полностью автономные подсистемы, слабо связанные с центральной АБС. Бывает, опять же например, что обслуживание физических лиц и юридических лиц вынужденно разносится по двум разным АБС, а общий итог бухгалтерского учёта приходится вести ещё и в третьей АБС. Всяко бывает. тем не менее, в общем случае, АБС - это центр бухгалтерского учёта в банке, и она очень важна для ежедневной работы. В нашем банке в 1995 году и позже, ГО сам использовал и предлагал нам (филиалам) использовать некую АБС под названием "Садко". Более подробно расскажу о ней чуть-чуть ниже, сейчас же отвлекусь немного в сторону. Я специально упомянул, что могут активно использоваться и другие подсистемы программного обеспечения, слабо связанные с центральной АБС, выполненные иными разработчиками, но важные для успешного ежедневного функционирования банка. 

В нашем банке, точнее именно в нашем местном филиале банка, подобной подсистемой стала система внутрирегиональных электронных платежей, разработки местного ЦБ, о которой многократно говорил в предыдущих частях. Собственно именно под задачу интеграции с этой системой, шеф вообще поручил мне заниматься системой Клиент-банк. Предполагалось логичным, что пришедший от клиента электронный платёж автоматически (или почти автоматически) перенаправляется в ЦБшную систему, для отправки в банк получателя. Результаты его приёма в этой системе автоматически формируют квитанцию об успешности или отказе. В итоге, конечный получатель платежа, в совсем другом банке города, видит поступившие на его счёт деньги буквально через единицы-десятки минут после фактической отправки платежа нашим клиентом с его собственного офисного компьютера. Аналогично, наш клиент может оперативно, через несколько (десятков) минут увидеть информацию, что на его счёт поступили деньги из другого банка и тут же, в течение одного рабочего дня, ими воспользоваться. Красиво?!

Именно эту доработку я и выполнил в первую очередь в своей изначально чисто тестовой банковской части системы. Я интегрировал её с ЦБшной программой электронных платежей, благо это было не очень сложно. Форматы файлов с исходящими и поступающими электронными платежами в ЦБшной программе были определены и описаны в документации. Я даже мог бы использовать именно эти форматы в своей программе, но к счастью, такая идея мне сразу не понравилась. ЦБшный вариант был неудобен, постоянно менялся, причём, иногда, неочевидным образом. Проще было в моих программах хранить платежи в моём внутреннем формате, а для обмена с рабочим местом ЦБ конвертировать их в актуальный ЦБшный формат и обратно. От идеи полностью автоматической отправки клиентских платежей на оплату в ЦБ я, разумеется, тоже сразу же отказался. Автоматизация, это хорошо и полезно, но последнее слово при контроле всегда должно оставаться за ответственным человеком! Поэтому я вывел на рабочие места операционисток вариант банковской части своей программы, где отправляемые клиентами платежи отображались в виде оперативно обновляемых списков. Бухгалтерши могли в любой удобный момент просмотреть подробности "своих" платежей, нужные отправить на оплату, а ошибочные задержать или отменить с комментарием о причине отмены. Помеченные к оплате документы, собирались в отдельный реестр у ответственной бухгалтерши. Та печатала этот реестр (в форме списка с итогом), утверждала его у начальства филиала, а после утверждения одной кнопочкой формировала готовый файл документов на оплату для ЦБшного рабочего места. О ручном наборе клиентских платежей в жутком тяжеловесном интерфейсе ЦБшного компьютера, все немедленно забыли! Поступающие из ЦБ ответы на платежи при следующих сеансах обмена автоматически формировали почтовые пакеты-квитанции для наших клиентов. Здесь уже не было ничего страшного, чтобы сформировать для клиента квитанцию на результат отправки его платежа в полностью автоматическом режиме, без всякого ручного утверждения, но, разумеется, и операционисткам принятые квитанции немедленно становились видны. Аналогично, поступающие в адрес нашего банка электронные платежи закачивались в специальные списки в моей программе. Там операционистки, прямо со своих рабочих мест в сети, могли просмотреть поступившие платежи, распечатать их, принять решение, что с ними делать дальше. Совершенно типовая схема обмена межбанковскими платежами, реализацию которой с небольшими вариациями, я в последующие годы видел в большом количестве разных современных АБС. Но я же её тогда САМ придумал?! ;) Никто мне ничего похожего раньше не подсказывал!

А вот теперь - про АБС "Садко"

В предыдущих абзацах я намеренно упростил схему прохождения платежей. Создал ложное (точнее специально упрощённое, для начального вхождения в тему) впечатление, что все исходящие платежи отправляются только в другие банки нашего региона. А поступающие платежи приходят тоже только от них. Но ведь это не так! А если клиент делает исходящий платёж внутри нашего же филиала, например другому нашему клиенту, или же в пользу собственно нашего банка? А если он делает платёж в совсем другой регион, который не подключен к электронным платежам местного ЦБ? А если исходящий платёж делает не клиент, а сам наш филиал, по своей банковской инициативе? Да и платежами всё не заканчивается. Кроме платежей клиентам нужно видеть выписки по своему банковскому счёту (что пришло, что ушло) и точно знать остаток на своём счёте на каждый момент времени. А всего этого в ЦБшной программе электронных платежей нет и быть никак не может. Это вообще не их компетенция, им это не интересно. Все эти данные как раз и должны сохраняться и обрабатываться в АБС банка. 

Уже сказал, наша АБС в период 1995-1997 годов называлась "Садко". Разработчиком программы числился "Инкомбанк". Как я понимаю, изначальном в этом банке программа разрабатывалась их внутренним отделом ИТ, к ней были и положенные исходные тексты, и вся необходимая документация. При любом изменении в требованиях ЦБ или своего начальства, немедленно выпускалась новая подверсия программы, отражающая требуемые изменения. Программа была написана в известной среде Borland TurboPascal, причём еще какой-то ранней версии, чуть ли не 4.0, задолго ДО внедрения фирмой Borland популярной оконной оболочки TurboVision. Вся логика программы, все интерфейсы, все отчётные формы были жёстко заданы внутри исполняемых файлов *.exe. Ну, т.е. вероятно вся логика программы была зафиксирована внутри основных исходных текстов на Паскале, и при каждой модификации требовала полной перекомпиляции кода. Ну а ГО нашего банка, похоже купил (или украл, это тоже возможный вариант) АБС "Садко" у "Инкомбанка" без исходных текстов программы, и без технической поддержки. С тех пор требования ЦБ и законодательство неоднократно (регулярно!) менялись, а вот дорабатывать код "Садко" к этим изменениям было уже совсем некому. В результате, от относительно функциональной изначально программы, постепенно отваливались в неработоспособное состояние. один кусок за другим. К концу 1995 года, когда я начал всю эту ситуацию наблюдать и чувствовать на собственной шкуре, там не работал почти ни один стандартный отчёт. Дело дошло до смешного, даже нормальное платёжное поручение из нашего "Садко" распечатать не получалось - печаталась совсем не актуальная, устаревшая (давно законодательно отменённая) форма, в которой, к тому же не хватало значительной части обязательных реквизитов. Спрашиваете, а откуда же тогда наши операционистки печатали нормальные платёжные поручения? Была некая мааааленькая программка, написанная каким-то бухгалтером ГО на коленке (или опять же спёртая у соседей, фиг знает). Там можно было ввести и почти правильно распечатать платёжку, но нельзя было её сохранить. Чуть позже кто-то откуда-то притащил шаблон файла MS Word, также содержащий похожую на правильную страничку для ручного ввода текста. А потом появилась программа платежей местного ЦБ, которая позволяла набирать и печатать платежи (как уже говорил, с жутко тяжёлым и тупым интерфейсом), даже ей обрадовались. А потом я дал бухгалтерии возможность печатать нормальные платежи в правильной форме из своей только начинавшей внедряться банковской части Клиент-банка, и вот это уже вызвало у операционисток бурные и продолжительные восторги! :) Маленький частный вопросик, именовавшийся в филиале Великой_Неразрешимой_Проблемой_Правильной_Печати_Платёжных_Документов (кратко:  ВН4ПД) был, наконец, снят с повестки дня.

Так, а для чего же тогда филиал использовал свою АБС "Садко"? В основном, в режиме примитивной "машины проводок". Говорят, мы в те времена были не одни такие. Чуть ли не ЦБ тоже аналогично в конце 1990-х жаловался на свою АБС (уже, кстати, далеко не первую попытку внедрения новой АБС в ЦБ со времён конца СССР), что она тоже ничего более полезного, чем "машина проводок" не умела, нуждалась в многочисленных костылях). Суть примерно такая. Есть база клиентов, есть база открытых счетов (часть счетов для клиентов, часть для самого банка). И то и другое более-менее работоспособно. По каждому счёту на конец дня можно вычислить правильное сальдо (остаток денежных средств). За каждый день ведётся список проводок: дебет одного счёта, кредит другого счёта, сумма проводки. Исходя из начального остатка и списка проводок за день, можно вычислить новый остаток счёта на конец дня. Исходя из начальных остатков, оборотов (проводок) по всем счетам и конечных остатков на конец дня, можно сформировать общий баланс организации (банка) за день: общие остатки по активу и по пассиву в сумме по всем счетам должны на начало и на конец дня совпадать (в смысле актив с пассивом совпадать) и общие обороты за день, суммарный дебет всех проводок и суммарный кредит тоже за день должны совпадать. Вот и ВСЁ. Примитивная бухгалтерская программа, которая только и умеет, что хранить остатки по счетам, обороты по проводкам за день, и умеет формировать по остаткам и оборотам правильный баланс - вот эта программа и называлась тогда "тупой машиной проводок", которая больше ничего делать не умеет.

Вроде бы эта программа была в работе мягко говоря, не очень актуальна. Но ГО настаивал, чтобы в качестве эталонного хранилища проводок мы использовали именно её (как индикатор "верности вассала", что ли?) и чтобы ежедневные балансы мы обязательно тоже формировали оттуда. Ещё там оставались частично работающими парочка отчётов, которые выгружали списки проводок по определённым критериям в текстовые файлы-полуфабрикаты, которые, в свою очередь загружались в таблицы Excel, и уже там обрабатывались "наколеночными" макросами, разработанными в ГО, с обязательным ручным допиливанием. Так получали ещё часть недостающей обязательной отчётности. Да, я всё ещё не упомянул, как хранила данные наша АБС "Садко"? Как сейчас понимаю, это и была та самая знаменитая технология доступа к файлам данных через программу-библиотеку Btrieve, которая была в тот период очень распространена в относительно недорогих, но уже заметно переросших порог в сотню-другую записей коммерческих базах данных, и использовалась во многих банках и других структурах. Я в то время о Btrieve слышал, и даже весьма уважительные отзывы, но почему-то совсем не предполагал, что у нас как раз она и есть. С моей точки зрения, вся БД АБС была разбита на отдельные таблицы. Каждая таблица в отдельности представляла их себя совершенно типовой файл данных обычного TurboPascal, состоящий из записей однородной структуры. Определялась структура файла данных прямо в исходном коде программы на Паскаль примерно так: type TableX = file of record A, B, C :.... end; Где A, B, C - какие то поля данных, нужные для записей именно этой таблицы. Я мог не знать, что такое Btrieve, это мне простительно. Но вот синтаксис определения типизированных файлов с записями в TurboPascal, вот это я знал на отлично! И догадывался, что если требовалось какую-то таблицу модифицировать, например добавить новое поле к каждой записи, или изменить размер какого-то поля, программист должен был исправить исходный текст программы, потом перекомпилировать все затронутые изменением модули, и пересобрать весь проект АБС заново. Понятно, что это задача не нашего филиальского уровня. Далее, каждый файл с таблицей записей данных, дополнительно сопровождался обычно несколькими индексными файлами предназначенными для ускорения поиска нужных записей. Структуру индексных файлов я не знал, и раскапывать её не собирался, мне это по сути и не было нужно. Доступ к отдельным записям отдельных таблиц контролировался сетевой операционной системой Novell NetWare, на дисках сервера которой лежали файлы БД АБС "Садко".

А из всего, что я сообщил в нескольких предыдущих абзацах, для проявлялась странная, точнее сказать ОЧЕНЬ ПРОТИВОРЕЧИВАЯ картина. Смотрите сами:

- 1) мне нужно любой ценой реализовать по заданию шефа платёжный электронный документооборот в филиале, полноценную систему Клиент-банк;

- 2) для электронного документооборота вроде бы уже есть некая начальная база - ЦБшная программа платежей. Вот только она во первых крайне сырая, а во-вторых бОльшую часть наших платежей она вовсе НЕ охватывает, и даже в перспективе не собирается помочь охватить! Это не их ЦБшное дело;

- 3) по-хорошему, все наши платежи должны вестись внутри нашей АБС "Садко", она нам для того и дана из столицы. Вот только вести там базу платежей не просто нельзя, а буквально физически невозможно! Не говоря уже о чудовищно устаревших на несколько лет формах документов, там в таблицах половина требуемых полей для хранения современных реквизитов платежей не была предусмотрена, да и никто не был способен их туда добавить - это технически невозможно, нет исходных текстов программ;

- 4) но отказаться полностью от бессмысленной АБС "Садко" тоже нельзя, ГО это строжайше запрещает - все проводки за день должны отображаться в Садко и баланс должен получаться оттуда! Точка, и ША!!!

Ну и как я должен был совместить вот эти пункты 1) 2) 3) м 4)? Что я должен был выбрать?!

- Погоди, Ёж! Мне кажется, ответ очевиден! Ведь у вас же был, кажется, довольно крупный банк. И у его ГО много клиентов, и региональных филиалов много, тоже со своими списками клиентов, у многих свои интересы. Неужели никто ничего во всей этой массе офисов с кучей грамотных специалистов, не мог подсказать, посоветовать? Так ведь не бывает в реальной жизни?

- Бывает, Шеркало, увы, бывает. Я говорил об этом ещё в самом начале развёртывания темы. Не было тогда во всей стране НИКАКИХ работающих электронных платежей. Ни у кого НЕ БЫЛО! Наш город был объективно первым. И никто ничего по теме не мог мне тогда посоветовать. Впрочем, почти никто и не хотел, и не пытался (за редкими исключениями, которые я старался ранее не забыть упомянуть). Большинство откровенно считали меня мудаком и фантазёром, который сам придумал себе идею-фикс, и сам же сдуру изнемогает под её тяжестью, вроде бы бежит впереди паровоза. Надо мной откровенно смеялись (но НЕ клиенты, те обычно высказывали уважение). Такое отношение сохранялось примерно до конца 1999 года. Тогда смеяться перестали, но я к тому времени уже работал в другом банке, над гораздо более современным вариантом системы. Где, впрочем, присутствовало МОРЕ собственных проблем, и тоже всплывали крайне неприязненные отношения со стороны некоторых столичных чинуш, считавших (небезосновательно), что я могу мимоходом, по моему провинциальному скудоумию, пошатнуть их личную властную монополию, в уже обжитых и доходных местечках-отдельчиках, но это уже иная тема.

Альтернативная АБС "ABSA"

Итак, ЦБшная программа электронных платежей весь функционал наших банковских электронных платежей выполнять никогда не будет. Она даже в качестве просто образца крайне ограниченно годна. "Мы мирные люди, но наш бронепоезд не поезд, не бронь, и не наш!" Электронные платежи должны вестись в нашей АБС "Садко", но она не знает не только того, как выглядят электронные платежи, эта АБС вообще не имеет понятия, что есть такие документы - современные платёжные поручения, хотя бы даже просто бумажные, какой уж там электронный обмен, о чём речь?! И дорабатывать эту АБС в ближайшие несколько месяцев никто не будет (да это и физически невозможно). И менять эту АБС на более современную опять же в ближайшие месяцы (годы) категорически запрещено. Так и что же мне делать? Сесть на пенёк, съесть пирожок, поплакать немножко и уволиться? Но я же был молодым, зелёным, хотел успешно работать и зарабатывать хотя бы на прокорм своей скромной зарождающейся семьи. Увольняться на ровном месте в мои планы тогда не входило. Я принял решение разрубить этот Гордиев узел в стиле Александра Македонского - раз наша банковская АБС не умеет нормально работать с платёжными поручениями, значит я сам напишу свою собственную АБС, которая будет это уметь!!!

На самом деле, дела (извините за невольный каламбур) шли всё же не так страшно, как только что озвучил. Я не рубил весь лес сплеча, а аккуратно, ежедневно (но, по возможности быстро) дорабатывал свой уже имеющийся код банковской части системы Клиент-банк. Ну и разумеется, не пытался написать ВСЮ АБС с нуля - мне это вовсе не требовалось. Я просто вынес в свою программу на FoxPro абсолютно весь функционал, отвечающий за работу с платёжными поручениями (и ещё, вынужденно, связанный с ведением расчётных счетов клиентов). Но только с ними. Другой функционал (а его в типичной АБС набирается весьма и весьма много) я оставлял без своего внимания. Получалась на выходе такая своеобразная функционально-обрезанная "половинка" от настоящей АБС. Но вполне качественная и эффективная половинка.

Расширенную до половины АБС программу банковской части Клиент-банк, я незамысловато обозвал аббревиатурой ABSA. Это название должно было, по моему замыслу, обозначать словосочетание Automated Bank System Alternative, или в переводе на русский: "Альтернативная Автоматизированная Банковская Система". Впрочем, большинство простых бухгалтерш нашего филиала смысла аббревиатуры не поняли, но простое слово "ABSA" вполне были в состоянии запомнить и произнести. Как я уже сказал, в ABSA был постепенно (на самом деле довольно быстро, не более, чем за месяц) перенесён абсолютно весь функционал связанный с платежными поручениями. Электронные платежи клиентов, проходящие через систему Клиент-банк, изначально обрабатывались именно там. Бумажные платежи клиентов, не важно зарегистрированных в Клиент-банке, или просто чисто бумажных клиентов-"отказников", тоже были перенесены туда, только вводить их операционисткам приходилось с бумажных носителей вручную. Ну так же и раньше делалось, просто в ABSA я постарался интерфейсы ручного ввода платежей выполнить максимально удобными, эффективными и эргономичными - специально регулярно опрашивал об удобстве и наших операционисток, и бухгалтерш клиентов (алгоритмы ввода и интерфейсы, они ведь одни и те же в обоих случаях работали), внимательно выслушивал и принимал критику. Максимально старался там, где это возможно, обеспечить заполнение нужных полей вводимого платежа из справочников, а справочники внимательно и регулярно обновлял, как на банковской части, так и на клиентской. После переноса ручного ввода платежей в ABSA о других костылях для ввода позабыли напрочь. Во всяком случае внутри филиала и вплоть до внедрения в начале 1998 года новой современной АБС позабыли. Печать платежей, во всех необходимых случаях, также осуществлялась из ABSA. Все внутрибанковские платежные поручения (как между двумя клиентами нашего филиала, так и между счетами филиала и клиента, тоже проходили внутри "альтернативной" АБС. Все платежи, которые предназначались для внутри-регионального обмена заворачивались на ЦБшную программу электронных платежей (касается  и исходящих, и входящих). Прямой файловый шлюз с ЦБшной программой поддерживала именно ABSA, т.е. налаживать обмен документами между ЦБшным рабочим местом и нашей основной АБС "Садко" я с самого начала даже не планировал - совершенно бессмысленная затея. Все бумажные межрегиональные платежи проходили через ту же ABSA, только с ручной обработкой. 

Все необходимые квитанции на платежи, как на входящие, так и на исходящие, формировались тоже в ABSA, по возможности автоматически и в электронной форме, а если требуется, то и вручную операционистками. Очень важная часть обмена платежами - выписки по счетам для клиентов. Каждый клиент системы Клиент-банк должен иметь регулярную возможность контролировать остаток на своём счете - что пришло, что уже ушло, сколько денег было, сколько осталось. Соответственно, нам нужно было уметь регулярно формировать выписки по счетам клиентов, содержащие входящие/исходящие остатки и полный оборот средств по счёту за прошедшую часть дня. Мы для всех клиентов системы Клиент-банк принудительно формировали так называемые "окончательные" выписки утром следующего рабочего дня. Но клиенты, по своему желанию, могли самостоятельно запросить в электронном виде "промежуточную" выписку за текущий день, которая содержала только те движения по счёту, которые к моменту запроса успели завершиться в банковской бухгалтерии. Клиенты всегда инструктировались, и прекрасно это понимали, что за оставшуюся часть банковского операционного дня их "промежуточная" выписка может быть дополнена новыми проводками, в результате может измениться и её исходящий остаток. Это с одной стороны совершенно нормально, а с другой стороны - это удобнейший инструмент оперативного контроля за денежными средствами. 

Запрос на промежуточную выписку формировался клиентом в виде специального технического электронного документа, вроде обычного платежа, только совершенно другого формата, намного проще, чем платёж. Этот документ содержал буквально три-четыре значимых поля данных, вместо нескольких десятков полей данных в платёжном поручении. Далее, запрос на выписку подписывался ЭЦП клиента, как и платежи, и отправлялся к нам в банк вместе с платежами (ну или отдельно, по желанию) при очередном сеансе связи. На стороне нашего филиала запрос клиента на выписку обрабатывался в ABSA автоматически, без всякого ручного вмешательства (если не возникали технические ошибки проверки ЭЦП, проверки корректности реквизитов запроса и т.п., требующие немедленной реакции безопасников - простейший пример, клиент пытается получить выписку по счёту другого клиента, тут уж явное вмешательство компетентного человека требуется!), в ответ на запрос ABSA вместо квитанции о получении (как на платёж) формировала промежуточную выписку и складывала её почтовый ящик, отправляемой этому клиенту почты. Повторюсь, если все необходимые проверки корректности запроса завершались успешно, выписка в ответ на запрос получалась полностью в автоматическом режиме, уже, обычно, через десяток секунд после получения запроса. Количество запросов на выписки от одного клиента в день никак не ограничивалось, и вообще никак не контролировалось. Хоть каждую минуту новую выписку запрашивай, если тебе не лень. Сами выписки клиентам в ABSA, как промежуточные, так и окончательные, представляли собой обычные текстовые файлы, можно даже сказать, неструктурированные текстовые файлы *.txt. Их можно было просто просматривать в окне встроенного в FoxPro текстового редактора на экране, можно было распечатать на принтер прямо оттуда же, можно было легко скопировать в любой подходящий внешний текстовый редактор. Несколько примитивно реализовано, но достаточно удобно и эффективно. Наши клиенты в целом оставались довольны. Хотя в более поздних системах Клиент-банк предлагались более развитые подходы, с хранением строк выписки (проводок) в базе данных, и с формированием текста выписки, как отчёта по этой БД, Но для первой попытки и так вышло вполне неплохо. 

А вот о другой особенности формирования клиентских выписок, просто необходимо упомянуть. Я уже подчёркивал, что мы полностью перенесли в ABSA работу с платёжными поручениями, а остальные документы оставили на совести "Садко". Но ведь по клиентскому счёту проходят ежедневно не только платёжные поручения! По этому же счёту проводятся и чисто внутрибанковские документы, платежами не являющиеся и инициируемые банком, а не клиентом, и кассовые документы, отражающие движение наличных средств клиента, и некоторые другие. И все документы, не являющиеся платежами, строго говоря в ABSA не ведутся, а вот в выписку, которую клиент видит в системе Клиент-банк, все эти документы попадать в виде отдельных строк (проводок) просто обязаны, иначе грош цена такой выписке! И на исходящий остаток каждой выписки все эти "внешние" документы самым непосредственным образом влияют! Значит и они обязаны учитываться в ABSA. Пришлось написать для ABSA процедуру двухсторонней синхронизации проводок с "Садко".

Собственно говоря, синхронизация в одну сторону, из ABSA в "Садко" предусматривалась с самого начала. Ведь, если я принял решение вести ВСЕ платежи банка внутри ABSA, а итоговый баланс филиала формируется в "Садко", то я просто обязан был предусмотреть механизм загрузки обработанных в ABSA документов в форме кратких проводок в "Садко". Там, насколько помню, был реализован готовый механизм загрузки проводок из внешнего текстового файла, с краткой строкой информации о каждой отдельной проводке. Вот я быстренько научился из ABSA выгружать такие файлы в специальную папку, а бухгалтерия их потом в удобные моменты по специальной кнопочке загружала в "Садко". При этом загружались только кратчайшие сведения "дебет-кредит-сумма" и кажется ещё был комментарий проводки "за что деньги?". Сами платёжные документы с полной информацией о реквизитах, и с историей их прохождения по этапам обработки, оставались в ABSA. 

Когда (ооочень скоро!) понадобилась синхронизация обмена и в противоположную сторону, из "Садко" в ABSA, пришлось научиться передавать также информацию по используемым счетам клиентов и по совершённым по этим счетам внутренним проводкам. Здесь я готового отчёта для выгрузки файла с подходящим содержимым в самой АБС "Садко" не нашёл. Отчёты выгрузки проводок были, но как обычно слишком устаревшие и узко-специфичные. Пришлось действовать иначе. Как я уже говорил, файлы данных АБС "Садко" выглядели с моей точки зрения как примитивные "type file of record...end;" в обычном Turbo Pascal. Никто не мешал мне открыть файл с проводками в режиме чтения, и копаться в нём из моей собственной паскалевской программки сколько мне хочется. Я при этом даже конфликта блокировки записей в системе не вызывал, работал только на чтение (большей частью), а Novell NetWare Btrieve был достаточно умным, чтобы это моё чтение молча игнорировать. Да, над форматами записей в файлах счетов и проводок, пришлось пару дней помучиться (документации же не было никакой!), все поля распознать не удалось. Но ВСЕ и не требовалось. Нужную мне информацию я в ABSA выгружать научился. В итоге у меня появился инструмент, чтобы при необходимости свободно обмениваться проводками между двумя "АБС" в обе стороны. Остатки по счетам я синхронизировать не стал (из-за факта независимой работы ABSA простая синхронизация выходила невозможной), но научился, после ещё пары дней поиска и  исправления ошибок, полностью верно подсчитывать исходящие остатки на своей стороне в ABSA. Синхронизация проводок между двумя системами выполнялась частично вручную, по команде операционисток, частично автоматически, при формировании выписок клиентам. Разумеется, были предусмотрены защитные механизмы, так что каждый синхронизируемый документ попадал из одной АБС в другую только в одном экземпляре, а не дублировался при каждом новом акте синхронизации.

Кстати, именно тот факт, что в ABSA, кроме электронных платежей клиентов, как это изначально задумывалось, были вынесены вообще все платежи филиала банка, значительная часть банковской базы счетов и значительная часть вообще всех проводок по этим счетам, включая операции формирование выписок и остатков, именно этот факт и сподвигнул меня на то, чтобы присвоить своей ABSA почётный титул "Альтернативная АБС", а не скромный статус "бэкенд для Клиент-банка". ;)

Последний подзаголовок "...Чем же всё это окончится? Будет апрель!.." 

А закончилась интенсивная доработка моей первой в жизни системы Клиент-банк, почти что в один день - с наступлением 01.01.1998 года. Я выше об обстоятельствах этого момента уже упоминал, теперь повторюсь, немного с другой стороны. С начала 1998 года ЦБ полностью поменял правила бухгалтерского учёта для всей банковской системы России. Изменено было всё: план счетов, формы первичных документов, виды, формы и порядок составления отчётности. Незатронутыми оказались только самые базовые принципы бухгалтерии, берущие своё начало ещё в средних веках. Что? Ах да, вру! Даже некоторые базовые принципы заколебались, например из плана банковских счетов полностью исключили фундаментальное понятие активно-пассивных счетов (в бухгалтерии предприятий они до сих пор есть, а в банках, с 1998 - уже нет). Менялось в учёте практически ВСЁ. Ранее работавшие по старым принципам банковского бухгалтерского учёта АБС, становились практически бесполезны, большую часть функционала требовалось менять, а сотрудников переучивать. 

Поскольку этот переход на другие принципы учёта хоть и проводился формально в один день, но планировался он заранее. Все бухгалтеры (кто держался в теме) знали о предстоящей революции в учёте ещё как минимум с начала 1997. И по мере сил, готовили к плановому шоку своё руководство и отделы/департаменты ИТ. Так вот, руководство нашего банка в Москве тоже конечно заранее было в курсе. И они поняли, что это самый удобный момент, наконец-то полностью отказаться от всех задолбавшей и совершенно бесполезной в современных условиях АБС "Садко". Вместо неё внедряли абсолютно новую, современную АБС с централизованной в ГО тех.поддержкой, и полностью соответствующую новым требованиям ЦБ. Если не ошибаюсь, это была АБС "Symbols / ВА-БАНК" (это два названия одной и той же АБС в разные периоды её разработки) от фирмы "ФОРС". Впрочем, подробно я о ней повествовать не буду, а в оправдание своей "нетвёрдой памяти о ней, могу сказать, что это была "не моя" АБС! Меня (как и других региональных ИТ-специалистов) почти не допускали к её тех.поддержке, всё делалось из ГО централизовано. Я не знал её внутреннего устройства. Я никогда не писал к ней никаких собственных доработок. Да и уволился из этого банка спустя несколько месяцев после внедрения. Не мудрено, что я толком и названия её в памяти не сохранил. Могу только сказать, что технически это была вполне современная, вполне работоспособная и полностью функциональная АБС, не чета нашей прежней беспомощной "Садко". Центром этой новой АБС была СУБД "Oracle", быстро набирающая популярность. Филиальские части АБС работали (для ускорения) с использованием локальных серверов "Oracle" в каждом филиале. Эти сервера функционировали на базе ОС Sun "Solaris" (UNIX-совместимая), сервера SUN SPARCstation (в нашем филиале во всяком случае). Филиальские БД Оракл регулярно синхронизировались с центральной БД Оракла в ГО. Синхронизация учитывала наличие сравнительно медленных каналов связи. Бухгалтерия филиала работала большей частью напрямую с локальными серверами из программ на базе терминального доступа к серверам Solaris. Терминальные программы, разумеется, запускались из-под Windows (к тому времени уже большей частью Windows95), но технически были именно терминалами для доступа к UNIX.

Очень прилично выглядела новая АБС нашего банка, имела разнообразный функционал в более-менее готовом виде. Но вот подсистема Клиент-банк в новой АБС по-прежнему полностью отсутствовала даже в ближайших планах. Ну не успели такую подсистему ещё придумать в столице к началу 1998, хотя планы уже строились. Но это только лишь бумажные планы на момент внедрения новых принципов учёта. А у нашего филиала уже работало более сотни активных клиентов, регулярно использующих Клиент-банк и обменивающихся сотнями электронных платежей каждый рабочий день. Бросить их без поддержки мне никто не позволял. Приходилось дорабатывать под новые правила и свою систему Клиент-банк, и её банковскую половину ABSA. Других вариантов опять не просматривалось, как и двумя годами ранее, к началу 1996. 

Сама по себе, техническая доработка программ на FoxPro у меня опять никаких чрезмерных сложностей не вызвала. Ну были одни типы счетов, структуры таблиц в БД, формы документов, правила контроля. Ну поменялось всё это на совсем-совсем другое? Ну и что? Первый раз мне что ли свои программы на FoxPro приходится переписывать? Было бы время! Времени было как обычно мало, буквально впритык, но с учётом сверхурочной работы, его в реальности хватило. Что ещё? С транспортом и криптографией на этот раз гораздо проще! В этой части вообще можно было ничего не переделывать, ни буковки не менять. Моя "троянская" часть, отвечающая за обновление клиентских программ, уже сказал, отработала тогда крайне успешно и эффективно! Хотя в ней как раз понадобились доработки по апгрейду БД и программ на клиентской стороне, но это получилось. Последняя проблема - банковская часть ABSA была изначально заточена на обмен с АБС "Садко", а новая АБС работала совсем иначе. Но и здесь не оказалось серьёзных проблем! Новая АБС имела готовый штатный функционал по загрузке/выгрузке списков проводок через текстовые файлы. Настроил ABSA на формат этих файлов обмена и получил на выходе функционал, ничуть не худший, чем работавший в прошлом году. 

Вот только в данном случае, фраза "не худший", хоть и вполне справедлива, но это уже вовсе не похвала. Функционал должен был стать лучше, много лучше, с учётом кратно расширенных возможностей новой АБС, а остался на первых порах на старом уровне "не худший, чем был". Мне, разумеется, это не нравилось. Я постепенно делал плавные доработки, с целью вынести основную обработку платёжных поручений филиала в штатный интерфейс новой АБС. А в ABSA сохранял только непосредственные шлюзы с ЦБшной программой (она, кстати, тоже полностью поменялась в 1998 году, но это уже не моя тема) и своим Клиент-банком. Ни то, ни другое, наша новая АБС абсолютно не поддерживала. Вполне получилось. А к тому моменту, когда всё срочное успокоилось, и начала подходить пора новых, плановых доработок, я уже готовился к переходу в другой банк и активные собственные разработки в этом банке аккуратно свернул. Тут и сказочке конец!

Совсем-совсем итог-итог. Моя первая система Клиент-банк, разработанная в условиях катастрофической нехватки информации и при почти полном отсутствии положительных примеров (как и опыта) у других разработчиков, оказалась на удивление удачной и жизнеспособной. За время использования к системе подключались многие десятки клиентов. Общее количество подключенных за всё время работы клиентов - несколько более 200. Количество одновременно работающих активных клиентов - около 150 на последних этапах эксплуатации системы. Отзывы от работающих клиентов - почти 100% строго положительные (не считая справедливой критики не совсем удачных технических решений на ранних этапах внедрения). Клиенты особо отмечали невероятную простоту работы с системой, которая к их удивлению, ничуть не снижала очень высокую эффективность работы. Также отмечался высокий уровень удобства работы, опять же удивительный, по мнению многих клиентов, с учётом видимой простоты и даже примитивности устройства системы. Эту самую простоту устройства при максимуме удобства и эффективности мне ещё несколько лет спустя припоминали некоторые "бывшие" клиенты при встрече - дескать, никогда позже они такого сочетания качеств не встречали. Из недостатков в первую очередь упомяну - вся программа ориентировалась на работу под MS-DOS, без перспектив плавного перехода к современным интерфейсам и технологиям, что к середине 1990-х (момент внедрения) было нормальным, но уже несколько спорным, хотя и объективно вынужденным решением, а к началу 2000-х явно требовало активного внедрения совершенно новых технологий. Ну а общее впечатление - первый же блин получился далеко "НЕ комом". И начальство, и клиенты остались весьма удовлетворены таким внедрением Клиент-банка. На этом - пока всё.