Реалии хостинга

Алексей Телятников Возраст: 46 лет Образование: Московский физико-технический институт, факультет радиотехники и кибернетики Послужной список последних лет: 2011 — настоящее время ЗАО «Связной Банк», член правления, директор департамента ИТ 2007–2011 CPM Group, управляющий партнер 2002–2007 «Росгосстрах», член правления, заместитель генерального директора, руководитель департамента ИТ 2001–2002 Консорциум «Альфа-груп», директор по ИТ 1997–2001 Фондовая биржа РТС, вице-президент 1995–1997 ЗАО «Технический центр РТС», генеральный директор

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

У вас за плечами большой опыт руководства ИТ-подразделениями крупных российских организаций. Там использовался хостинг?
     Использовался, но в других масштабах. Свой последний ЦОД я построил в 1999 году, когда работал в РТС. В то время услуг хостинга в России практически не было. Более того, этот ЦОД тогда сдавал часть своих мощностей в аренду. Фактически РТС была первой организацией, которая начала предоставлять услуги размещения серверов финансовых компаний на своей площадке (кстати, сейчас очень многие биржи оказывают подобные услуги). Кроме того, в «Росгосстрахе» одним из моих первых шагов в должности CIO был переход в арендованный ЦОД.
«Связной Банк» пошел дальше: мы арендовали инфраструктуру, приобретя все необходимые серверные мощности как услуги.

Какие преимущества давал хостинг организациям, где вы работали?
     Первое преимущество — гибкое управление стоимостью ИТ-инфраструктуры. При массовом объеме выполняемых операций ИТ-расходы на обработку отдельных операций в финансовом и телекоммуникационном секторах должны быть минимальны, чтобы себестоимость продуктов была как можно ниже. Приходится тщательно оценивать наши затраты и себестоимость продуктов, очень внимательно планировать наши расходы и ресурсы.
ИТ-инфраструктура сейчас все больше зависит от электроэнергии, ее доля в эксплуатационных расходах стабильно растет не только на Западе, но и в России. В штате ИТ-службы, как правило, нет специалистов по приобретению дешевого электричества и созданию правильной инфраструктуры энергоснабжения. В штате ИТ-компании, владеющей ЦОД, такие специалисты наверняка есть, и это второе очевидное преимущество хостинга.
     Третье преимущество — возможность выбора того стандарта инфраструктуры, который больше подходит нашей организации. Например, стоимость хранения 1 Тбайт данных в системах разного класса может различаться в десятки раз. Если организация создает большую систему хранения исключительно для своих целей, то ей придется идти на определенный компромисс, поскольку, скорее всего, у нее не будет возможности держать штат инженеров, умеющих обслуживать три совершенно разные системы хранения, — это дорого. При работе с аутсорсером у организации есть возможность приобрести более дорогую услугу хранения для работы одних приложений, предъявляющих высокие требования к надежности хранения и скорости доступа к данным, и более дешевую для других, благодаря чему можно существенно снизить стоимость операций, это очень важно! Кроме того, приобретая инфраструктуру как услугу, можно намного снизить риски, связанные с изменением цен на рынке оборудования.

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

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

Каковы основные риски выбранной вами схемы?
     Я вижу два основных риска. Первый — это квалификация поставщика услуги с точки зрения соответствия декларируемого и реального сервиса, то есть соответствия того сервиса, который зафиксирован в нашем SLA, и того уровня обслуживания, который реально предоставляется. Развеять сомнения мог бы независимый аудит аутсорсера, но пока таких услуг в России нет, а проводить аудит своими силами будет слишком накладно. Второй риск связан со степенью уникальности заказчика для данного поставщика: можно придумать набор таких услуг, которые поставщик больше никому не предоставляет, в этом случае выигрыша для заказчика, скорее всего, не будет — такие услуги будут стоить слишком дорого. В перспективе это станет самым значительным риском.
     Я был бы очень доволен, если бы появился хостинг-провайдер, работающий хотя бы с десятком финансовых организаций, это дало бы мне уверенность в том, что он работает качественно и что у него достаточно ИТ-ресурсов (по мере роста потребностей клиентов он сам будет эти ресурсы наращивать). Таких провайдеров пока нет, а те, что есть, предлагают «индивидуальный пошив».

Как отнеслось к хостингу ИТ-инфраструктуры высшее руководство банка?
     Решение о хостинге было принято еще до моего прихода в банк, поэтому я не знаю, как руководство восприняло предложение о переходе на хостинг. Сейчас оно относится к хостингу весьма благожелательно.
     В 2002 году, в период моей работы в «Росгосстрахе», выбирая аргументацию для руководства в пользу того, чтобы воспользоваться хостингом и не создавать собственный ЦОД, я подготовил расчеты и ответы на наиболее часто встречающиеся вопросы. Например, чем рискует компания из-за того, что ее системы будет обслуживать инженер из другой компании? Тем, что ее не проверила наша служба безопасности? Но эта проблема легко решается — потенциальный партнер не будет препятствовать такой проверке. Есть риск, что кто-то из сотрудников допустит серьезную ошибку? Но ответственность сторон в подобных ситуациях можно предусмотреть в договоре. Руководство компании тогда очень положительно восприняло мои доводы и согласилось на хостинг. Впоследствии это решение сильно облегчило переезд компании в новый офис — нам не пришлось перемещать серверное оборудование.
     По собственному опыту знаю, что хорошо подготовленный переезд банка из одного ЦОД в другой занимает не более 18 часов, включая физическое перемещение оборудования. Также я убедился, что благодаря тщательно продуманному переходу на хостинг доступность банковских систем увеличивается на порядок.

Как бы вы охарактеризовали российский рынок хостинга в целом?
     Большинство хостинговых услуг, которые доступны и востребованы в России, — это услуги по размещению в ЦОД оборудования заказчиков. В целом рынок ЦОД уже достаточно устоявшийся.
     «Связной Банк» уникален в том плане, что приобрел услугу доступа к инфраструктурным ресурсам — серверам, системам хранения и пр. Мы покупаем услуги распределенного ЦОД: поставщик предоставляет нам ресурсы, расположенные в двух физически разных центрах обработки данных, принадлежащих разным юридическим лицам. Мне важно то, что я приобретаю услуги у одного поставщика — у IBM, как их обеспечить — это его сфера ответственности. Разумеется, мы знаем и согласуем с ним схемы предоставления нам хостинговых услуг, но надежность и прочие параметры качества обслуживания — это его обязанность.

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

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

Как решается проблема обеспечения требований Федерального закона № 152-ФЗ «О персональных данных»?
     Я не вижу здесь особой проблемы. Мы никому не отдаем персональные данные, они хранятся и обрабатываются в нашей системе, хотя она и развернута на сторонних площадках ЦОД. Замечу, что ФЗ-152 — достаточно сложный закон, и правоприменительной практики по нему пока еще очень мало. Первый ключевой аспект, который мы учитываем и за выполнением которого следим, — чтобы данные не покидали границ России. Второй — четкое определение того, какие системы подпадают под закон о персональных данных. В целом, обеспечивая соответствие закону ФЗ-152, мы руководствуемся документами, которые подготовил ЦБ РФ.
     Насколько сложно обеспечить в российских условиях телекоммуникации необходимого для хостинга качества и как дорого они обходятся?
В черте Москвы это несложно и относительно недорого, в городе имеется хорошо развитая инфраструктура телекоммуникаций. Гораздо дороже обходятся телекоммуникационные каналы, связывающие банк с региональными филиалами. Мы стараемся не строить широкую телекоммуникационную инфраструктуру. Чтобы оптимизировать расходы на связь, мы выстраиваем разумную архитектуру сети и выбираем оптимальный пул интернет-провайдеров.

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

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

Как считаете, оправдывается ли прогноз Николаса Карра относительно превращения ИТ в разновидность коммунальных услуг?
     Уже есть ряд ИТ-сервисов, которые можно рассматривать как коммунальные услуги, например сеть передачи данных, доступ в Интернет, SMS и т. п. Они хорошо стандартизованы, у них есть понятная метрика. С другой стороны, есть приложения (например, банковские системы), которые пока не могут рассматриваться как коммунальные услуги. Конечно, существуют и другие приложения (например, «1С:Бухгалтерия»), которые вполне можно считать коммунальными в том смысле, что они известны и понятны очень многим пользователям и не представляет труда найти специалистов по ним, составить техническое задание и пр. В общем, я полностью согласен с прогнозом Карра.