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

Intelligent Enterprise: Что было в банке до того, как началась модернизация комплекса инфраструктуры? И чем такая ситуация вас не устраивала?

Аркадий Затуловский: Как, наверное, и у большинства российских банков, у нас долгое время не было своего полноценного центра обработки данных. Были лишь серверные комнаты с необходимым минимумом инфраструктуры. Первый более-менее полноценный ЦОД появился у нас в 2009 году. Как раз тогда остро встала задача внедрения новой автоматизированной банковской системы [АБС]. А АБС эта имела весьма высокие требования к инфраструктуре, и комплекс на основе оборудования IBM просто негде было тогда размещать. Под данную задачу был создан небольшой ЦОД на площадях, принадлежащих банку. Мы этот ЦОД запустили, установили оборудование, потом внедрили новую АБС.

С того времени банк продолжал развиваться. Внедрялись новые системы, и соответственно росло количество используемого оборудования. А его тоже нужно было где-то размещать. С другой стороны, остро встал вопрос о том, чтобы вывести на новый уровень всё, что связано с восстановлением систем после аварий.

Где-то с 2009-го мы начали активно использовать виртуализацию. А это серьезно повышает требования как к качеству энергообеспечения, так и к потребляемой мощности стоек.

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

Владимир Джума: Для нас первичным было создание всего, что связано с обеспечением непрерывности. И это общая тенденция. Если раньше многие банки считали избыточными требования стандарта TIER III, то сейчас все активнее строят ЦОДы уровня TIER IV. Мы для себя решили, что нам необходимо обеспечить резервирование в полном соответствии как минимум со стандартом TIER III, который не допускает простоев инженерной инфраструктуры даже для ее планового обслуживания. Уже на стадии проектирования был заложен высокий уровень гибкости: мы можем использовать стойки как на 5 кВт, так и на 15 и даже на 20 кВт. Такая возможность была заложена в решение с самого начала. Хотя могу сказать, что стойка, которая реально, в номинальном режиме, потребляет 20 кВт, — это скорее из области легенд, как показывают результаты мониторинга нашего ЦОДа.

Как удалось идею модернизации ЦОДа «продать» руководству? Помогло ли влияние Группы Nordea?

А.З.: «Продать» руководству проект модернизации ИТ-инфраструктуры — задача не слишком сложная. Достаточно четко показать зависимость между развитием банка и инфраструктуры. Мы показали, что модернизация ИТ даст возможности для органического развития бизнеса и для этого нужны инвес­тиции в ИТ.

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

Выбор решения и выбор подрядчика… Как проходили данные про­цедуры?

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

При этом мы понимали, что сделать одновременно хорошо, дешево и быстро невозможно и придётся чем-то жертвовать. Из этой триады мы пожертвовали сроками. Работы продолжались несколько дольше, чем первоначально рассчитывалось, зато мы получили ожидаемое качество и сохранили запланированный уровень финансовых затрат.

Что касается выбора технического решения, то здесь также рассматривалась продукция разных вендоров. Но решение Schneider Electrick оказалось безусловным лидером в том, что касалось построения комплексных систем управления ЦОДом. Альтернативные решения, такие как EcoBreeze или DRUPS, просто не существовали в приемлемом для нас виде. По крайней мере на тот момент. Так, например, DRUPS нужной нам мощности на рынке тогда не было. Кроме того, нас не устраивал чрезвычайно высокий уровень шума систем этого типа: более 100 dBa. А по соседству с нашим офисом находятся жилые дома и дошкольные учреждения. Да и размещение оборудования массой в несколько тонн не слишком простая задача, по крайней мере в офисном здании. Таким образом, в то время, когда проектировался наш ЦОД, сформированное нами решение было если не самым технологически совершенным, то максимально близким к этому уровню.

Какие этапы работы оказались наиболее сложными?

В.Д.: Мы вообще решали очень сложную задачу, не один раз в ходе проекта вспоминали о фильме «Миссия невыполнима». И действительно, мы ограничены площадями, а они не слишком велики. Плюс серьезные ограничения, связанные с уровнем шума, плюс необходимость проводить работы, не прерывая основную деятельность других подразделений и не останавливая бизнес-процессы, но соблюдая при этом все требования нормативов. Чтобы вписаться в имевшиеся ограничения, например, при проектировании системы освещения, которую следовало разместить в очень узком запотолочном пространстве, использовали последние модели плоских светодиодных светильников. Или еще один пример: необходимо было предусмотреть возможность перемещать дизель-генераторные установки [ДГУ] системы резервного электропитания на расстояние до десяти метров, не снижая при этом уровень резервирования системы. Это нужно для того, чтобы энергетики Москвы могли получить доступ к силовому кабелю, который проходит как раз под нашей территорией. Кроме того, мы спроектировали и реализовали решения, направленные на существенное снижение шума от работающих ДГУ. В итоге он не выше, чем от автомобиля с запущенным двигателем.

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

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

Далеко не все идут на то, чтобы создавать систему автономного энергоснабжения. Как можно убедить противников в необходимости построения данного элемента?

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

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

Как формировался disaster recovery plan [DRP]? Насколько вообще эта задача трудоемка, сколько времени она занимает? Использовался ли опыт Группы Nordea?

А.З.: На уровне Группы существуют стандарты. Они регламентируют, например, требования к удаленности ЦОДа или к каналам связи для банков, которые входят в Группу. Так что мы вели проектирование на основе этих стандартов.

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

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

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

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

Надо сказать, что включение облачных сервисов в DRP — не такая уж сложная задача, как принято считать. Обычно полагают, что облачный сервис является прямым аналогом широко известных «бытовых» публичных сервисов Apple, Google, Microsoft или Amazon. Но это не так, мы используем специализированные сервисы, и это вполне укладывается в стратегию нашего развития. К данному сервису не может подключиться кто угодно. Его можно сравнить с закрытым клубом. И в выборе поставщика такого сервиса решающую роль ИТ-отдел, как правило, не играет. Наша роль была ключевой только при выборе облачной системы для специфического электронного документообмена с клиентами. Мы показали, что использовать СЭД от внешнего поставщика выгоднее, чем внедрять её своими силами на ИТ-платформе банка. Но последнее слово всегда за бизнесом. Просто потому, что бизнес платит и оценивает свои риски. Мы же со своей стороны оцениваем возможные риски в области ИТ. Так же, как подразделение информационной безопасности оценивает риски в сфере ИБ. Так что происходит комплексная экспертиза со всех сторон и мы принимаем решение совместно.

В.Д.: Для любых решений от внешних поставщиков, будь то облачный сервис или аренда стоек во внешнем ЦОДе, существует договорная база, которая требует безусловного исполнения. Естественно, есть соглашение об уровне сервиса [SLA], где нормируется стоимость нарушения наших требований в ясной и понятной денежной форме. Есть, наконец, стандарты, как выработанные нами, так и уровня Группы. В результате решение от внешнего поставщика выбирается не по принципу «что дешевле», а по принципу «что лучше». И значительная часть потенциальных поставщиков отсеивается уже на очень ранней стадии выбора.

Тренировки персонала — насколько это важно? Как часто их надо проводить?

А.З.: Эту задачу необходимо разделить на две части. Одна из них относится к ИТ-департаменту и касается того, что нужно делать при возникновении той или иной нештатной ситуации. То, о чем рассказал Владимир, — как раз частный случай такой вот ситуации. Да, один из самых распространенных, но далеко не единственный в своем роде.

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

Раз в год мы проводим тренировки. Люди должны знать, что делать в час «икс». Эти тренировки охватывают как ИТ-специалистов, так и бизнес-служащих. Ведь многие даже технические риски влияют на разные подразделения банка.

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

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

С Аркадием Затуловским и Владимиром Джумой беседовал обозреватель Intelligent Enterprise Яков Шпунт