Центр обработки данных является одним из главных активов современного банка. О том, как строился и развивался ЦОД банка DeltaCredit мы говорили с его руководителем службы эксплуатации информационных систем Андреем Столяровым.

Intelligent Enterprise: Какие системы эксплуатируются в банке? Как давно?

Андрей Столяров: Вследствие бурного развития бизнеса в 2007-2008 году в банке была принята новая стратегия развития ИТ. Полностью переделывалась фронтофисная система, а также внедрялось несколько новых приложений, в том числе и катастрофоустойчивое решение. В настоящий момент мы используем две фронтофисных системы на основе Microsoft SQL, автоматизированная банковская система (АБС) построена на базе Oracle. Широко используется виртуализация от Vmware.

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

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

Каков средний срок жизни оборудования в вашем ЦОД? От чего он зависит?

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

Как быстро эффект от внедрения данных систем становится осязаем?

Это зависит от многих факторов. Если СХД является «бутылочным горлышком», которое замедляло работу приложений, хранящих на ней свои ресурсы, либо предлагает качественное изменение процесса эксплуатации, то эффект будет заметен очень быстро. Точнее, практически сразу. В нашем случае после замены в 2010 году СХД пользователи сразу отметили, что приложения стали работать быстрее. На одной чаше весов была покупка новой СХД и замена дорогого FC канала более дешевым Ethernet, на другой – недешевое продление поддержки оборудования, аренда дорогого FC канала связи с резервным ЦОД и повышение операционных расходов, связанных с ограниченным функционалом оборудования. В нашем случае чаши этих весов сравнялись примерно через 2 года.

К тому же наша прежняя СХД использовала только дорогой протокол FC, и это приводило к тому, что стоимость системы связи при организации системы репликации данных между основной и резервной площадками увеличивалась втрое по сравнению с использованием массового Ethernet.

Решение этих задач привело нас к модернизации комплекса СХД и основой подсистемы хранения данных стал NetApp.

И таким «бутылочным горлышком» могут быть не только СХД. Причем более производительное оборудование может к тому же оказаться дешевле. И тому тоже есть практические примеры. Так, в нашем банке АБС до 2009 года работала на серверах архитектуры EPIC (Itanium). После ее замены на архитектуру x86 мы не только выиграли в цене, но и в производительности.

Однако такие революционные изменения происходят нечасто. Обычно развитие систем идет постепенно, эволюционным путем.

Как шли работы по проекту модернизации СХД?

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

Мы выбрали систему NetApp, так как это один из стандартов группы Societe Generale, и для нас действует скидка на оборудование этого вендора. В итоге мы приобрели 2 системы, для основного и катастрофоустойчивого ЦОД. При реализации проекта мы привлекли специалистов компании SiBiT. И их помощь часто оказывалась неоценимой.

В процессе внедрения две системы FASS 3240, размещенные в основном и резервном ЦОД, были объединены синхронной репликацией данных по технологии SnapMirror.

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

Какие системы менять наиболее трудно? Почему?

Можно выделить несколько таких систем.

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

Отсутствие виртуализации систем. Системы, установленные на «голое» железо, лишены гибкости в конфигурировании и модернизации. Со временем их обслуживание становится сложнее. Конечно, виртуализация не упрощает инфраструктуру. Скорее наоборот, но там просто другие проблемы.

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

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

Как найти баланс между обеспечением высокого уровня непрерывности и затратами? Всем ли реально необходим уровень TIER III и выше? Что делать, когда нужен соответствующий уровень отказоустойчивости, но нет на это ресурсов?

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

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

К тому же для многих компаний ЦОД уровня TIER III или IV действительно будет дорогим удовольствием. Когда роль ИТ велика, как например в финансовом секторе, как правило велика и цена простоя сервиса. Соответственно тут уровень доступности нужен высокий. Но даже в этом случае уровень затрат должен соответствовать возможному ущербу. Но все же для финансового сектора более предпочтительным является уровень TIER III. Для таких задач, как трейдинг или все, что связано с обслуживанием банковских карт, этот уровень, на мой, по крайней мере, взгляд, это и вовсе минимум. Там цена простоя очень велика и есть смысл рассматривать TIER IV.

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