Проблемы администрирования приложений в банке, или как администратору не впасть в административный раж

/Дмитрий Феофилактов, Начотдела системной интеграции Отделения банковских разработок компании ЗАО ФОРС-ХОЛДИНГ. Банковские разработки. 2002, ?3, стр. 33-37/

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

настройка и установка совокупности;

установка достаточно изменений (показавшихся в следствии исправления неточностей либо модификации совокупности);

воспроизведение действий пользователей для инициирования процесса и диагностики проблемы исправления неточностей;

проверка работоспособности совокупности;

создание резервных копий совокупности;

восстановление совокупности.
Потому, что приложений без неточностей не бывает, то вторая, третья и четвертая задачи поднимаются в большинстве случаев с печальной регулярностью. К тому же для банковских совокупностей свойственны постоянные обновления благодаря трансформации законодательства (вступают в воздействие новые законы, инструкции и т. д.) либо технологии работы банка (с целью уменьшения операционных издержек, ускорения обработки документов и т. д.). Все это совместно ведет к тому, что пакеты трансформаций в АБС смогут поступать частенько.
Сложность исполнения задач администратора связана с солидным числом рабочих мест, работоспособность которых он обязан обеспечить, и с ограниченным временем для их исполнения — работа банка не имеет возможности нарушаться из-за сбоев в программном обеспечении.
Итак, главная неприятность ИТ-администратора в среднем либо большом банке пребывает в необходимости систематично обновлять программную совокупность на солидном числе пользовательских рабочих мест. О средствах ее решения мы и желали бы поболтать в данной статье.
Конечно, мы опираемся на опыт администрирования отечественных наших клиентов и сотрудников, что был взят в различное время в ходе внедрения АБС ‘Ва-Банк’, ‘Ва-Банк ПЛЮС’, SYMBOLS-R, ‘Ва-Банк XL’. Все эти совокупности являются интегрированными АБС с широким комплектом функций и исходя из этого практически устанавливаются практически на каждом компьютере в банке. Эти совокупности реализованы в классической архитектуре клиент—сервер, и при их разработке употреблялись средства компании Oracle.
С главной проблемой эксплуатации совокупности в банке сталкиваются администраторы всех АБС, реализованных в архитектуре клиент—сервер, независимо от ОС и СУБД. Мы сохраняем надежду, что отечественный опыт ее решения в среде Oracle будет занимателен ИТ-сотрудникам многих банков.

Договоримся о терминах

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

ПО (ПО) Сервера базы данных. Поставляется компанией Oracle. Потом — RDBMS;

файлы базы данных (БД) — место хранения пользовательских данных и части кода программы Приложения, потом — файлы БД.
Клиентская часть снабжает интерфейс с пользователем и предварительную обработку данных. Ее состав:

Oracle RunTime — ПО, поставляемое компанией Oracle, снабжающее сообщение с БД и выполняющее код программы Приложения (интерпретатор).

Файлы Приложения — содержат код программы, картины, шаблоны отчетов, описатели меню, SQL-скрипты, командные файлы и т. д. Поставляются компанией — производителем Приложения.
Обе эти части Приложения совместно трудятся в определенном программном окружении — остальном и операционной системе ПО, выполняющемся на данном компьютере. Это программное окружение мы назовем Рабочей средой приложения. В это понятие кроме этого направляться включить все настройки ОС, каковые наряду с этим употребляются, т. е. все то, что может оказать влияние на функционирование отечественного Приложения.

Рабочая среда приложения

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

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

Самостоятельно исправлять неточности в Рабочей среде приложения фактически нереально, возможно лишь устанавливать пакеты трансформаций от компаний-производителей (ОС и в нашем случае Oracle RunTime). Причем поменять либо автоматизировать процедуру установки достаточно не легко. Действительно, трансформации в данной части происходят достаточно редко.

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

Практически во всех случаях Алфавитно-цифровая среда является UNIX в качестве ОС и главное, встроенное в ОС и применяемое для работы приложение — терминал (telnet). Исходя из этого такую среду потом будем именовать терминальной. Для графической среды употребляется по большей части ОС Windows.

Практические варианты компоновок Приложений

Компоновка Приложения для Терминальной рабочей среды продемонстрирована на рис. 1.

На практике применение ‘чистой’ терминальной рабочей среды фактически не видится. В большинстве случаев на рабочем месте устанавливается ОС Windows (т.е. графика) и дополнительное приложение — эмулятор терминала. Посредством этого эмулятора пользователь трудится с главным Приложением.

Наряду с этим файлы Приложения (его код программы) находятся на сервере, а пользователь применяет эмулятор терминала как средство доступа к главному Приложению. Потому, что программ — эмуляторов терминала довольно много, они прекрасно отлажены, а Приложение для работы с ними применяет стандартные интерфейсы, то надежность работы эмулятора близка к надежности работы ОС на рабочем месте.
На рис.1 пунктиром продемонстрирована ‘линия разреза’ — место, где возможно отделить Серверную часть Приложения от Клиентской. Так получается трехуровневая архитектура (сервер базы данных — сервер приложений — рабочее место). Необходимо заметить, что в этом случае ОС Сервера базы данных уже не обязательно UNIX, а, к примеру, Windows NT.
Разглядев подобную компоновку с позиций задач администрирования, возможно прийти к следующим выводам.

Практически Приложение устанавливается на один либо пара (в случае если имеется сервер приложений) серверов. На рабочее место ставится дополнительная программа — эмулятор терминала, что не весьма сложно: имеется встроенный эмулятор, входящий в поставку ОС, имеется эмуляторы, по большому счету не требующие установки.

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

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

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

Компоновка Графического приложения (‘чистый’ клиент—сервер) выглядит несложнее, потому, что нет дополнительной программы-эмулятора терминала.
Как видно из рис. 2, клиентская часть расположена на рабочем месте пользователя и тесно проинтегрирована с ОС в части настроек, хранящихся в системном реестре — главном месте хранения настроек ОС и приложений в ОС компании Микрософт (предположений Windows 95 и выше) — и общесистемных библиотек.
С позиций задач администрирования появляются следующие неприятности:

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

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

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

Компоновка с применением файл-сервера продемонстрирована на рис. 3. К купленным недочётам этого варианта направляться отнести:

возросший сетевой трафик в ходе работы приложения и вероятное замедление загрузки форм Приложения;

в случае если Oracle RunTime расположен на файл-сервере, то, при громадного разнообразия ПО, установленного на рабочих местах, вероятно разное поведение Приложения;

при необходимости установить дополнительное ПО для работы какой-то части сотрудников нужно будет устанавливать его на файл-сервер, т. е. всем, при чем вероятны конфликты предположений этого ПО. К примеру, в предположениях Oracle Developer6.0 и Developer6i построитель форм имеет одно да и то же имя ifbld60.exe. Смогут кроме этого появиться неприятности с безопасностью. К примеру, установка утилиты SQL*Plus, дешёвой для всех пользователей, воспринимается администраторами как вероятная ‘дыра’ в защите Приложения (при применения защиты данных на уровне формы приложения, в то время, когда в данной форме установлен фильтр на таблицу и пользователь видит лишь отфильтрованные записи), применение утилиты SQL*Plus разрешит просматривать всю таблицу полностью, поскольку пользователь сможет самостоятельно написать запрос без фильтра). Практически все недочёты Графической среды проистекают от громадного количества компьютеров и связаны с трудностями удаленной модификации и настройки Рабочей среды Приложения на каждом рабочем месте.
Одним из недочётов Терминальной рабочей среды с позиций пользователя есть убогость интерфейса. Исходя из этого все современные приложения применяют по большей части Графический интерфейс. Разглядим внимательнее дополнительные варианты графических компоновок, каковые смогут оказать помощь администраторам:

хороший X-Windows терминал;

Микрософт Terminal Server;

JAVA-терминал Oracle9i AS. Компоновка графического терминального Приложения фактически ничем не отличается от простого терминального. Отличие компоновки лишь в эмуляторе терминала — употребляется эмулятор графического терминала (более сложное и не через чур распространенное приложение). В остальном все схоже, и основное — клиентская часть расположена на сервере. Но неприятности у таковой компоновки также имеется.

Отыскать качественный эмулятор графического терминала сложно, и стоит он много. Сам он значительно сложнее, чем эмулятор простого терминала, и требует намного больших вычислительных ресурсов на рабочем месте.

Русификация графики в среде UNIX сложнее. Администратору нужно будет искать качественные шрифты, хороший тумблер раскладок клавиатуры.

Частично нужно будет перенести работу разработчиков Приложения в UNIX, поскольку необходимо будет учитывать специфику UNIX при разработке.

В случае если разглядывать вариант Микрософт Terminal Server, то неприятности русификации в том месте нет, а эмулятор поставляется вместе с совокупностью. Но имеется неприятности с масштабируемостью. Через чур большие требования предъявляются к ресурсам сервера Приложений.

Компоновка JAVA-терминала приведена на рисунке 4. Сложность совокупности в целом значительно возрастает. На сервере приложений запущено дополнительно два приложения: веб-сервер и FORMS-сервер. Клиентская часть приложения стала больше, поскольку в нее не считая форм (стандартного комплекта, как и для простого графического Приложения) вошли особые JAVA-апплеты, входящие в состав Oracle9i AS. Эти апплеты снабжают функционирование и прорисовку образа формы на рабочем месте пользователя в окне веб-браузера. Рабочее место также претерпело трансформации — сейчас на него установлен веб-браузер с JAVA-машиной. Выбор тут маленькой, но достаточный — JAVA-машина, либо встроенная в MSIE 5.0, либо поставляемая с Oracle9i AS, которая ставится как встраиваемое в браузер приложение (plugin). Имеется возможность применять легко JAVAViewer.
В данной конфигурации количество ПО возросло, но направляться учесть, что практически на всех рабочих местах уже установлен один из браузеров (MSIE либо Netscape Communicator). Следовательно, рабочее место пользователя уже оборудовано. Администратору необходимо обслуживать лишь серверы БД и Приложений.
Недочёты компоновки с JAVA-терминалом следующие:

настройки и сложность установки. На сервере приложений трудится дополнительное ПО;

повышенные требования к ресурсам рабочей станции. Для работы требуется веб-браузер с трудящейся JAVA-машиной;

без дополнительных неприятностей возможно применять лишь одну платформу — Windows. Применение вторых платформ требует дополнительных упрочнений от разработчиков, потому, что применяемые формы должны быть перекомпилированы под платформой, применяемой сервером Приложений. Но у данной компоновки имеется собственные преимущества, как обычные для компоновки с сервером Приложений, так и неповторимые:

практически ничего не требуется устанавливать на рабочие места. Соответственно, неприятности совместимости ПО не появляется;

пакет трансформаций нужно устанавливать лишь на сервер приложений;

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

вероятны смешанные конфигурации. Часть пользователей может трудиться через JAVA-терминал, часть — через Oracle RunTime. Наряду с этим нет никаких неприятностей рассинхронизации версий приложения — формы те же самые;

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

высокая производительность Сервера приложений и встроенная в Oracle9i AS возможность балансирования нагрузки. Один процессор может поддерживать работу до 100 пользователей.
В итоге применение Oracle9i AS при возросшей сложности администрирования сервера приложений разрешает упростить работу администратора по обслуживанию рабочих мест. Наряду с этим приложение трудится в Графической рабочей среде, а регулярные административные операции по сложности, автоматизации и трудоёмкости такие же, как и для Терминальной среды.
Мы постарались изложить все вероятные варианты компоновки Приложений, продемонстрировав их преимущества и недочёты.
Для Графических приложений (трудящихся с базами данных в архитектуре клиент—сервер) самоё перспективным нам думается вариант с применением JAVA-терминала (Oracle9i AS), потому, что администрирование рабочих мест в этом случае максимально упрощено. Но единого рецепта дать нереально. В конечном итоге все определяется Рабочей средой, ресурсами конкретного банка и опытом Администратора.

Финансовая жизнь

Проблемы администрирования приложений в банке, или как администратору не впасть в административный раж

The Difference Between VDI and Terminal Server

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: