— Иван, как бы вы определили, что подразумевает обеспечение непрерывности бизнеса?

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

— Какие критичные зоны вы бы выделили в обеспечении процесса непрерывности?

— Каждая зона по-своему критична, но с точки зрения «фатальности» последствий для бизнеса я бы выделил нижние уровни, так как они являются базовыми и от них зависит работоспособность и корректное поведение всех остальных систем.

— Какие в таком случае рекомендации можно дать для минимизации риска сбоев на уровне программно-аппаратного комплекса?

— Наряду с соблюдением общепринятых для банков и IT-компаний рекомендаций в части построения отказоустойчивых систем с высокой степенью доступности и обеспечения стандартов в области безопасности (на них я не буду особо заострять внимание) необходимо внедрять системы пассивного мониторинга и выстраивать процессы проактивного мониторинга. Немаловажным является и выбор аппаратного обеспечения под прикладное ПО. В данном случае важно непосредственное участие вендора этого ПО, гарантирующего работоспособность не только на момент внедрения, но и при последующем росте объемов бизнеса. К примеру, наша компания периодически проводит тестирования, в том числе «сайзинг» своих продуктов на оборудовании ведущих поставщиков, таких как IBM и Oracle.

— С какими проблемами могут столкнуться банки в ходе выстраивания отказоустойчивой инфраструктуры?

— Зачастую мы наблюдаем ситуацию, когда банк, покупая новое высокотехнологичное ПО, сталкивается с проблемой нехватки квалифицированных кадров, чтобы его поддерживать и развивать. В этом случае возможны варианты — взять нового сотрудника с рынка или же переложить эти задачи на текущих специа­листов. Второй подход поможет банку немного сэкономить, но в результате может привести через какое-то время к серьезным проблемам из-за недостатка квалификации сотрудника. Первый подход связан со значительными расходами, временем на поиски и адаптацию, а также с другими рисками прихода нового человека. Чтобы снизить риски и затраты, можно воспользоваться альтернативным вариантом и передать услуги по сопровождению нового программного обеспечения на аутсорсинг. По нашим подсчетам заказчик может экономить от 25% до 40% бюджета на содержание высококвалифицированных специалистов Oracle DBA, воспользовавшись соответствующими услугами аутсорсинга. При этом банк гарантированно получит поддержку специалиста, обладающего необходимой экспертизой и высокой квалификацией.

— Многие банки настороженно относятся к услугам по аутсорсингу, почему? Как аутсорсинг может решить проблемы финансовых организаций, связанные с организацией IT-инфраструктуры?

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

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

Как правило, при работе с аутсорсинговым партнером в SLA (Service Level Agreement) задокументированы все возможные ситуации, а также обязательства сторон. Это позволяет максимально оперативно реагировать на возникающие проблемы и получать обратную связь. Кроме того, при передаче работ на аутсорсинг снижаются риски, связанные с управлением сотрудниками (поддержанием их мотивации и лояльности).

— Вы перечислили несколько уровней IT-инфраструктуры, от эффективной и бесперебойной работы которых зависит непрерывность банковского бизнеса. Какие сбои происходят на уровнях вспомогательного и прикладного ПО? Какие меры необходимо принять банку, чтобы их избежать? Можете ли вы привести примеры из вашей практики?

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

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

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