Центр обработки данных как основной инструмент преодоления рисков внедрения ИТ (Р. Заединов, "Банковское дело в Москве", N 1, январь 2006 г.)

Центр обработки данных
как основной инструмент преодоления рисков внедрения ИТ

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

Каковы реальные риски?

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

Согласно опросу, проведенному компанией Eagle Rock Alliance, потери могут быть настолько значительны (см. график), что более 40% компаний прекращают существование уже при 72часовом простое ИТ-сервисов. Ни один из ведущих банков не может позволить себе и этих трех суток.

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

ЦОД как черный ящик

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

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

Такие параметры, как результат, время его получения и гарантия того, что система будет работоспособной, являются единственным, что интересует заказчика в данном случае. Эти параметры обычно обозначают термином SLA (service level agreement) - соглашение об уровне качества услуг. Как правило, процесс утверждения SLA лежит на плечах ИТ-директора компании-заказчика - именно он предлагает руководству те сервисы, которые предприятие будет использовать в процессе решения тех или иных бизнес-задач. Иными словами, не вдаваясь в технические подробности, руководство предприятия знает, за какое время могут быть получены необходимые сведения или отчеты.

"Рисунок"

Ты меня понимаешь?

Как определить - какие приложения являются критичными и какой уровень доступности им необходим? Для оценки и классификации приложений ИТ-руководитель организует диалог с представителями подразделений компании, которые являются пользователями. Вполне вероятно, что на вопрос: "Какие приложения являются для вас критичными?" он получит ответ: "Все!", а на вопрос: "Что случится, если приложение будет недоступно, скажем, один день?" - ему скажут: "Будет плохо".

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

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

Пути преодоления рисков

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

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

Учебная тревога

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

ЦОД построен. Что дальше?

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

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

"Диаграмма"

Р. Заединов,

руководитель направления центров обработки

данных компании КРОК

"Банковское дело в Москве", N 1, январь 2006 г.