Трудно сделать первый шаг
Автор
Григорий Рудницкий
Облака — новая технология, и не все и не всегда понимают, что это не простой аутсорсинг, что они накладывают ограничения на характеристики SLA.
Артему Плетневу, CIO Московской школы управления СКОЛКОВО, за свою карьеру ИТ-специалиста в разных компаниях приходилось реализовывать успешные проекты по переводу корпоративных сервисов в облако, поэтому об облачных решениях и связанных с ними сложностях и специфике он знает не понаслышке. Мы попросили его ответить на несколько вопросов.
Какое место в ИТ-стратегии Московской школы управления СКОЛКОВО занимают облачные решения?
Мысли об облаках возникают тогда, когда ты понимаешь, что развитие по классическому пути не позволяет тебе соответствовать ожиданиям, предъявляемым бизнесом. Это может касаться скорости развертывания сервисов и систем, адекватного сочетания цены и качества и т. д. В основном, когда мы говорим про облака, то обсуждение начинаем с рассмотрения инфраструктуры. Облака и инфраструктура — два понятия, которые наиболее полно укладываются в эту концепцию. Сегодня облачные решения предлагаются на рынке не только как инфраструктура, но и как приложения, как аутсорсинг.
Поэтому, получив опыт внедрения облачных технологий в одной из компаний, где я работал ранее, здесь, Московской школе управления, увидел, что все развивается по классическому сценарию. Что я имею в виду? Существует специализированное ИТ-оборудование, а также серьезная и достаточно стабильная ИТ-инфраструктура, но все это требует поддержки, модернизации. Все чаще бизнес смотрит на ИТ не только с точки зрения поддержки, поэтому разговаривать с бизнесом становится все сложнее на предмет необходимости модернизации и инвестиций в оборудование. Бизнес хочет слышать другие слова и выражения. Вот почему нам приходится искать иные способы и возможности модернизации оборудования, заходить «с другой стороны». Здесь следует обратить внимание на облачные технологии и на их применение для модернизации и оптимизации инфраструктуры.
Что для этого есть в бизнес-школе? Есть почва, есть о чем подумать, есть что проработать. Но мысли мыслями, а реальная жизнь накладывает свой отпечаток. Разумеется, задумываться надо не просто о самих технологиях, а о способах их реализации здесь. Никто не сомневается в том, что это необходимо и обеспечит определенные параметры качества, но вопрос, как это сделать правильно, с чего начать, чем закончить и где вовремя остановиться.
Какие проблемы и сложности «дооблачной эпохи» можно решить помощью внедрения корпоративных облаков?
Российский бизнес сам по себе достаточно молодой. А если говорить о развитии в ИТ в бизнесе, то они еще моложе. Ведь России в новую эпоху требовалось очень быстро переориентироваться и наращивать темпы роста. Соответственно, у ИТ не было времени применять технологии постепенно и поэтапно. Мы должны были быстро обеспечить самое необходимое, чтобы бизнес смог расти и догонять остальной мир. «Дооблачная эпоха» характеризуется набором разного оборудования и разных решений различной сложности. Также для нее особенно характерен переизбыток мощностей и сложность реализации в плане количества инфраструктуры, обеспечивающей одну задачу. Проще говоря, не было времени на раздумья — приходилось решать задачи, поставленные бизнесом. Появлялась задача — появлялась система. Так что «дооблачной эпохе» свойственен в первую очередь зоопарк систем и сервисов. Чем сложнее зоопарк, тем труднее были задачи ИТ по его поддержке. Часто ИТ не могли обеспечить непрерывность работы этих систем, что вызвало жалобы и недовольство бизнеса. Длительные простои, большое количество аварий и продолжительное время их устранения — таковы особенности «дооблачной эпохи».
Наступила «облачная эпоха». Но что такое облако? Разновидность того же аутсорсинга. Только аутсорсинг заключен в другую оболочку с другими параметрами. Но ничего принципиально нового здесь нет. Просто тебе не предлагают обслуживать твое собственное оборудование, тебе предлагают это оборудование как сервис со всеми характеристиками безопасности.
Вы говорите о зоопарке систем и оборудования. Но в некоторых компаниях исповедуется моновендорный подход, когда, допустим, используется все ПО и оборудование только от IBM или только от HP. Нужны ли таким компаниям облака?
Моновендорный подход не отменяет зоопарк. Зоопарк создается количеством решений, которые могут быть и от одного вендора. В определенный момент это количество перестает быть продуктивным, поскольку вендор может снять какие-то системы с производства, поддержка устаревших систем становится дороже, появляются новые продукты, которые плохо интегрируются со старыми. Возникает вопрос: а нужно ли отталкиваться от «железа» или приоритетом должен быть сервис как таковой? Раньше мы выбирали конкретную модель сервера, руководствуясь ее характеристиками. Сегодня мы держим в голове требования, которые предъявляет к производительности система, и ее мы должны внедрить для обеспечения тех или иных задач, поставленных бизнесом. Можно, конечно, найти под эти условия соответствующее «железо» или арендовать эти мощности в облаке. Однако не всегда можно угадать необходимые требования, часто возникают ошибки. Что же тогда остается? Покупать и устанавливать новый сервер со всеми вытекающими последствиями? В случае с облаками можно просто заказать дополнительные мощности. В публичном облаке это делается моментально, но даже если речь идет об Enterprise-решении, необходимые ресурсы будут предоставлены в течение нескольких дней.
Как правильно выбирать поставщика облачного решения? Что должно содержаться в SLA?
При выборе я бы ориентировался не только на количественные показатели, но и на существующий опыт работы. Облака — новая технология, и не все и не всегда понимают, что это не простой аутсорсинг, что они накладывают ограничения на характеристики SLA.
Компании, уже предоставляющие облачные сервисы на рынке, в процессе работы с заказчиком оттачивают предложенные варианты, а затем смогут предоставить их и другим клиентам. Так что здесь важнее всего опыт и отзывы реальных клиентов, которые уже пользуются облаками от данного поставщика.
Важна ли отраслевая экспертиза?
Я бы пока не говорил об отраслевой экспертизе. Облака пока, как и аутсорсинг, применимы к стандартным или стандартизированным сервисам. Инфраструктура, сеть, электронная почта, хостинг во всех компаниях одинаковы. Поэтому здесь нужно принимать во внимание тоже стандартные параметры типа отказоустойчивости, наличия собственных или арендованных мощностей и т. п. Конечно, нужно избегать посредников между конечным сервисом и потребителем. Провайдер облачных сервисов должен иметь свои мощности, свои ЦОДы, свое оборудование. Когда мы внутри ИТ-департамента определяем какие-то требования SLA по доступности систем, то зачастую не можем это сделать, поскольку не всегда понимаем, как их реально измерить и как ими управлять. Мы обычно опираемся на то, что если в течение года не было аварий или сбоев, то можно говорить если не о 100%-ной, то уж точно о 99,9%-ной доступности. Компания, которая предлагает SLA, предусматривающий 99,9%-ный уровень доступности, должна располагать двумя территориально разделенными ЦОДами, резервным копированием данных и т. д. Но параметры влияют на цену. Соответственно, когда мы выбираем SLA с меньшим уровнем доступности, то должны получить ответ, почему он меньше, за счет чего услуга дешевле. Возможно, используются уже не два ЦОДа, а один, внутри которого расположено два хранилища. Достаточно ли ему этого или нет, заказчик должен сам адекватно оценить.
Соответственно, очень важно, чтобы компания, предлагающая облачный сервис, была способна адекватно оценить каждую строчку своего предложения, а не просто говорить, дескать, у нас есть здание, у нас есть куча оборудования, приходите к нам, доверяйте нам свои данные.
Как посчитать экономический эффект от внедрения того или иного облачного решения? Как избежать ошибок при подсчете?
Прежде чем оценивать экономическую эффективность, важно понять, на какие дискретные составляющие, понятные и ИТ, и бизнесу, можно разделить ИТ-сервис. Когда мы говорим об облаках, то оперируем понятием pay per use (плата за использование). Как этот параметр видят ИТ и бизнес? Это может быть один сотрудник, один почтовый ящик, один гигабайт данных. И если возможно, сначала следовало бы в таких дискретных пропорциях просчитать и оценить существующий сервис, Но иногда это нельзя сделать, поскольку сервис либо пока отсутствует, либо работает в амплитудном режиме — сегодня затрат ноль, завтра — много. Но выстроив такую сервисную модель, ты уже можешь, оперируя параметрами, легко понять, какие затраты и какие преимущества принесут облака твоему бизнесу.
Вообще, обязательно должно присутствовать понимание, из чего складывается стоимость текущего ИТ-сервиса. Это не просто контракты на поддержку, не просто стоимость «железа». Это еще и люди, персонал и вся окружающая инфраструктура.
Почему, на ваш взгляд, российские компании и CIO в отличие от своих западных коллег не очень-то стремятся в облака, хотя и проявляют к этой теме постоянный интерес?
Тут дело в специфике России. У нас очень многие ИТ-директора являются техническими директорами. А технический директор привык к тому, что у него все находится под рукой и он всем этим реально управляет. На Западе несколько другая ситуация. Там, как правило, ИТ-директор — это не технический директор, а именно CIO в полном смысле слова, руководитель, управляющий информацией, а не инфраструктурой. А значит, ситуация диктует другие подходы, поскольку западные CIO уже не мыслят техническими категориями. Для них неважно, что представляет собой инфраструктурная подложка, им важен сам сервис, который они предоставляют бизнесу, и быстрые ответы на вопросы бизнеса. У нас же все иначе. Во всех компаниях уже имеется своя достаточно серьезная ИТ-инфраструктура. Как я уже говорил, часто наблюдается зоопарк в плане «железа» и в плане систем, что существенно тормозит переход в облака. Когда мы в другой компании осуществляли проект по такому переходу, то параллельно оптимизировали весь ландшафт приложений. Ведь что представляет собой миграция системы в облако? Это не просто перенос, это и оптимизация системы, и ее документирование — словом, глобальная переработка, сопряженная с серьезными ресурсными и финансовыми затратами. Ведь далеко не всегда все системы поддерживаются собственным ИТ-департаментом компании. Нередко бывают и такие ситуации, когда система работает уже много лет, ее начинали создавать одни люди, продолжали другие, поддерживают третьи, и что с ней делать, никто не знает. Ее просто боятся трогать, мол, работает и хорошо. Данный фактор тоже часто останавливает переход в облака.
Как правило, если что-то и переносят в облака, то это стандартные сервисы, о чем я уже говорил. Что-то более сложное и комплексное уже сразу внедряется в облаке. Если вы задумались о внедрении новой ERP-системы, имеет смысл поразмыслить над тем, чтобы ее сразу же внедрять в облачном варианте. Мощности уже обеспечены, оборудование покупать не нужно, поэтому стоимость проекта окажется существенно ниже и будет складываться только из требований бизнеса. Бизнес не понимает затрат на инфраструктуру. Кроме того, очень сложно бывает спланировать процесс миграции существующей системы в облако. Это нужно сделать, не останавливая бизнес. Вопрос в том, есть ли достаточное количество ресурсов для того, чтобы поддерживать работу компании и при этом обеспечивать миграцию.
И последний вопрос. Какие объективные и субъективные сложности могут подстерегать при переводе тех или иных бизнес-процессов в облака?
Одна из сложностей — сделать первый шаг. Если сначала ты выступаешь, как сервис-менеджер, то в облаках ты уже скорее контракт-менеджер и delivery-менеджер. Ты уже не отвечаешь за обслуживание, ты отвечаешь за сервис, который стоит над облаками. Готов ли к этому ИТ-директор? Это большой вопрос. Сложно спланировать все эти преобразования, о которых я уже говорил. Не всегда под рукой достаточное количество ресурсов, чтобы его осуществить.
Когда все хорошо, последующие выгоды очевидны и легко просчитываются. Но на первом этапе требуются очень серьезные инвестиции. Готов ли к ним бизнес? Обладает ли ИТ-директор достаточными навыками, чтобы убедить бизнес в том, что при крупных вложениях сейчас он получит солидную выгоду потом? Облачные соглашения обычно долгосрочные, меньше чем на пять лет их нет смысла заключать. В начале будет больше затрат, в конце — меньше.
Еще один немаловажный фактор — недоверие к партнерам. У вас в компании есть свой штат ИТ-специалистов. Вы им худо-бедно, но управляете. Дали им задание — они бегут выполнять. В случае с облаками — уже не побегут, если ты заранее не установил параметры этого «бега», либо побегут, но за отдельную плату. Разговаривать с бизнесом про SLA — дело неблагодарное, но необходимое. И в любом случае нормативы SLA будут выше ожиданий бизнеса. Нормативы всегда и везде высокие, но это вовсе не означает, что все выполняется по нормативам. Все выполняется с той скоростью, которая обеспечивает оптимальное соотношение цены и качества, а также в соответствии с процедурами инцидент-менеджмента и управления изменениями. Своим людям можно дать команду — и они сделали. Вопрос в том, то ли они сделали, туда ли они воткнули, да и туда ли они побежали? Но если опытная компания берет на себя обязательства по обеспечению работы той или иной системы, включаются вышеупомянутые процедуры, и каждый шаг проверяется с позиций его влияния на сопряженные конфигурационные единицы и сервисы, затем проверяется работоспособность сделанного, а уже потом компания рапортует вам о выполнении задания. Да, это чуть дольше, чем работа собственных специалистов, но качество такой работы выше, поскольку соблюдены все те шаги, которые обычно нами не соблюдаются. Быстро сделанное дело — не значит сделанное качественно.
Опубликовано 01.07.2013