ИБС БИСКВИТ и филиальная сеть банка "Каспийский": проблемы, поиски, решения

Успешное развитие банка, в идеале, требует внедрения единой автоматизированной банковской системы, в нашем случае — ИБС БИСКВИТ, как в головном офисе, так и во всех филиалах, с необходимостью создания в головном офисе единой базы данных (БД) на основе репликации БД филиалов, а не с помощью обмена телеграммами. Опытом проделанной в этом направлении работы мне бы и хотелось поделиться с заинтересованными читателями.

Итак, мы завели у себя в головном офисе по одной БД на каждый филиал, включая головной офис, — всего 18. В базу каждого филиала ввели список клиентов, счета, остатки по ним и получили вступительный баланс. Специалистами фирмы БИС были предложены протоколы для репликации информации из существующих БД филиалов, но поскольку банк располагает высококвалифицированными программистами и настройки системы расписаны со всей прозрачностью, было принято решение доработать этот вопрос силами банка. Затем мы утвердили макет телеграмм по проводкам, открытию, закрытию и изменению счетов, написали процедуры их автоматического импорта, утвердили регламент закрытия операционного дня банка в головном офисе по каждому филиалу и по банку в целом и начали сопровождать все эти БД в головном офисе.

В итоге мы получили возможность составлять баланс и другие виды отчетности в целом по банку на основе проводок каждого филиала, а не на основе присылаемых из филиалов (зачастую крашенных) телеграмм, вести Главную бухгалтерскую книгу банка (ГК) с обеспечением аудиторского следа. Иными словами, стало возможным детализировать счета ГК вплоть до первичного документа по любому филиалу за любой день. Цель достигнута: генеральная бухгалтерия и руководство банка теперь могут контролировать работу филиалов. Однако на деле не все так прекрасно, как этого бы хотелось.

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

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

Решить проблему помогло внедрение одинакового, хорошо масштабируемого программного обеспечения во всех филиалах банка, которое позволило создать в головном офисе объединенную БД, полученную на основе репликации БД каждого филиала. В нашем случае — это ИБС БИСКВИТ. Почему программное обеспечение должно быть одинаковым, понятно — намного легче создать объединенную БД, поскольку мы имеем дело с идентичными информационными полями и, самое главное, все доработки к программам делаются и утверждаются в головном офисе и рассылаются по всем филиалам, что избавляет автоматизаторов в филиалах дублировать работу друг друга. Хорошо масштабируемой система должна быть потому, что филиалы у нас различаются как по объему работ, так и по аппаратному обеспечению. В головном офисе, например, где выполняется пять тысяч транзакций в день, у нас стоит мощный восьмипроцессорный сервер, а в филиале, выполняющем не более ста проводок в день, соответственно обычный ПК в качестве сервера.

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

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

Таким образом, после внедрения в головном офисе и во всех филиалах банка единого программного обеспечения появилась возможность для ведения БД по всем филиалам в головном офисе на основе репликации. Практически сразу встал вопрос: как это сделать? После консультаций со специалистами фирмы БИС были выбраны решения репликации, стандартно представленные в СУБД PROGRESS. Мы изучили три варианта: репликация на основе триггеров, репликация на основе after-imaging файла и репликация на основе инкрементального бэкапа (incremental backup).

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

Нам же был нужен быстрый в плане разработки и эффективный способ репликации. Такими способами были стандартные средства промышленной реляционной СУБД Progress — after-imaging файл (AI-файла) и инкрементальный бэкап. Однако при репликации на основе инкрементального бэкапа теряется возможность периодически делать ежедневный полный бэкап базы. Вследствие этого мы решили отдать предпочтение репликации на основе AI-файлов.

Итак, решив использовать репликацию на основе AI-файлов, мы разработали следующую схему.

1. Филиал включает в базе механизм ведения журнала AI.
2. Периодически на сервере филиала запускается скрипт, который подготавливает AI-файл к отправке (архивирует его на диск) и начинает ведение нового AI-файла.
3. Копия AI-файла шифруется и передается в головной офис по каналу связи.
4. В головном офисе запускается скрипт, который распаковывает присланный файл и накладывает AI-файл на эталонную базу филиала.
5. Эталонная база копируется в рабочую базу филиала.

При таком механизме репликации встает вопрос: как же быть с пользователями головного офиса, имеющими доступ к БД филиалов? Раньше, при использовании телеграмм для передачи информации из базы филиала в копию, хранящуюся в головном офисе, таких проблем не возникало, потому что при таком способе таблица пользователей и их права не затрагивались. Теперь же полная синхронизация копии с удаленной базой филиала повлечет за собой и копию таблиц пользователей. Дело в том, что в базах филиалов заведены лишь свои пользователи, имеющие возможность работать с базой. В головном офисе уже другие пользователи имеют свои собственные логины и пароли. Для удобства подключения пользователей к базам филиалов нужно, чтобы логин в базе головного офиса совпадал с логином и паролем во всех копиях баз филиалов.

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

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

Сама схема репликации осталась прежней, как и при AI-файлах.

1. Периодически на сервере филиала запускается скрипт, который делает инкрементальный бэкап базы (bac-файл).
2. Копия bac-файла шифруется и передается в головной офис по каналу связи.
3. В головном офисе запускается скрипт, который распаковывает присланный файл и накладывает bac-файл на эталонную базу филиала.
4. Затем эталонная база копируется в рабочую базу филиала, и туда же импортируются права пользователей головного офиса.

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

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

В результате проделанной работы мы получили практически полный контроль за БД филиалов. Копии БД обновляются три раза в день: в 11-00 для получения сводного баланса банка, в 15-00 для предварительного расчета валютной позиции и ночью для составления отчета по кассе. Теперь согласно требованиям международных стандартов возникает вопрос о централизации бухгалтерского учета. Например, нужно сделать так, чтобы некоторые проводки филиал только инициировал, а подтверждала бы их генеральная бухгалтерия головного банка, другими словами, существовала возможность изменения базы филиала пользователями головного офиса. Этого можно достичь следующими путями:

• перенести все счета филиалов в БД головного офиса и дать доступ филиалам для проведения проводок;
• дать доступ филиалам в рабочие БД филиалов в головном офисе;
• дать доступ сотрудникам головного офиса к БД в филиалах;
• осуществить двухстороннюю репликацию.

Безусловно, у каждого варианта есть свои плюсы и минусы, и банк выбирает для себя наиболее приемлемый. При этом уже имеющийся опыт, проверенный на практике, поистине бесценен. Обращаюсь к коллегам с приглашением к участию в обсуждении данной темы.