Мониторинг информационных систем -- понятие, имеющее свою внутреннюю структуру. Формируя подходы к управлению ИТ-инфраструктурой в контексте бизнес-задач, следует учитывать это и помнить о некоторых особенностях развития бизнеса и его автоматизации в России. Как возникающие при этом проблемы решаются в условиях работы крупного российского банка? Об этом рассказывает начальник управления сопровождения банковских технологий МДМ-Банка Павел Андроняк.

Intelligent Enterprise: Банки всегда уделяли большое внимание мониторингу используемой ИТ-инфраструктуры, потому что здесь от нее очень зависит качество бизнес-процессов. Скажите, что предпринималось и предпринимается для решения этой задачи в МДМ-банке?

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

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

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

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

То есть, говоря о связи работы ИТ-систем с качеством бизнеса, мы вынуждены существенно выйти за рамки того, что подразумевается под мониторингом ИТ-инфраструктуры?

Можно сказать, что да. Для определенности давайте введем самую общую классификацию, о которой, впрочем, я уже частично сказал выше. В некотором смысле можно отдельно говорить о мониторинге инфраструктуры, имея в виду прежде всего инфраструктуру, лежащую в основе функционирования прикладных систем как таковых. Речь идет о серверном и телекоммуникационном оборудовании, системах хранения, операционных системах, каналах связи, кабельных сетях. Слежение за функционированием прикладных систем - тоже своего рода самостоятельная задача. И наконец, отдельно можно говорить о мониторинге групп взаимосвязанных систем в контексте функционирования бизнес-процессов. Последнее направление, кстати, в сфере корпоративной автоматизации не так давно оформилось во вполне самостоятельное, и ныне его принято называть Business Service Management (BSM).

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

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

Это обусловлено, по большей части, десятилетиями формальной отладки прикладных систем и взаимосвязей между ними в стабильных со всех точек зрения условиях. В российских банках, как известно, большинство ключевых систем -- российского производства. Они развивались и по сей день развиваются в соответствии с постоянными, порой радикальными изменениями законодательства и формальных правил ведения бизнеса. Чтобы сделать работу прикладных систем стабильной и надежной, нужно отработать все интерфейсы и все практические ситуации, имеющие место в реальном бизнесе, на что, естественно, необходимо время, которого не хватает никогда. В результате могут встречаться ситуации, когда, на первый взгляд, все компоненты ИТ-инфраструктуры функционируют штатно, а бизнес-процесс нарушен из-за ошибки, явившейся следствием впервые проявившегося стечения обстоятельств. Таким образом, обеспечить развитие систем в наших условиях без запаздывания относительно темпа изменений окружающей бизнес-среды и при сохранении высокого качества продукта крайне сложно и, в свою очередь, требует значительно более детального подхода к построению систем мониторинга.

Реализация данного подхода фактически подводит нас к необходимости мониторинга бизнес-приложений. Все сказанное выше доказывает: управление прикладными системами должно явно дополняться мониторингом базовой инфраструктуры и при этом явно учитывать специфику работы конкретной компании. У нас такие работы изначально развивались самостоятельно. Они, я думаю, будут и в дальнейшем основываться на собственных наработках. Ведь мы как никто другой знаем работу собственных прикладных систем и особенности построения нашего бизнеса. При этом, естественно, для этого используется весь доступный инструментарий. Так, мы вынуждены были интегрировать HP Open View с другими применяемыми у нас системами мониторинга -- тем же Oracle Enterprise Manager или CiscoWorks. Все это также было сделано в сотрудничестве с компанией "Крок". А увязывая эту работу с работой по отслеживанию базовой инфраструктуры, мы, по сути, уже успешно продвигались в реализации концепции BSM. Возникает уже качественно новая форма услуг бизнесу.

Прежде всего, в чем тут выражается качественная новизна? Расскажите об этом подробнее.

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

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

Здесь и происходит тот самый качественный скачок. Во-первых, мы можем перейти от политики устранения инцидентов к задаче совершенно другого, качественно более высокого уровня -- к управлению непрерывностью бизнеса. Во-вторых, мы переходим к адекватному диалогу с бизнесом на принципиально ином уровне, превращаемся из чистых исполнителей в партнеров. Еще до возникновения внештатной ситуации можно информировать совершенно конкретных сотрудников о возможной проблеме. Можно не в авральном режиме обсудить с сотрудниками других подразделений различные пути выхода из ситуации -- оптимизацию ИТ-процедур, бизнес-процессов или закупку нового, более мощного оборудования.

Пока вы говорите лишь о расширении возможностей видения проблемы самим ИТ-подразделением. А каким образом ставит задачи сам бизнес? Ведь не может же существовать такая ситуация, при которой способность ИТ-подразделения по осознанию влияния работы ИТ-систем на бизнес идет впереди культуры постановки задач самим бизнесом.

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

Это не SLA в классической трактовке данного термина. Но это имеет прямое отношение к оценке качества сервиса, равно как и к технологиям ITSM, которые мы сейчас внедряем.

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