Источник: журнал CIO №5

"Облачные" ИТ-сервисы дают компаниям гибкость и адаптивность, позволяя избежать проблемы наличия избыточных мощностей в период спада и недостатка ресурсов во время подъема деловой активности. Какие выгоды дает компании частное "облако"?

Общая ИТ- и бизнес-идея "облачных" вычислений отвечает ожиданиям заказчика по созданию собственной вычислительной инфраструктуры. За последние 10-15 лет в большинстве государственных и коммерческих структур в РФ уже созданы и работают различные распределенные информационные системы (ИС). Теперь на передний план вышла задача поддержки их работоспособности. И вот здесь кроются основные проблемы заказчика: изношенный аппаратный и программный фонд, хронический дефицит квалифицированных кадров, унаследованные информационные ресурсы. При этом сетевая инфраструктура, как правило, вполне сносно работает на объектах автоматизации и далека от перегрузок.

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

По сравнению с публичным собственное частное "облако" будет выгодно тем компаниям, которые потребляют большой объем ИТ-услуг, который может быть спрогнозированным в среднесрочной перспективе. А также тем, которые по каким-то причинам не могут передать информацию провайдеру "облачных" сервисов (большинство таких компаний сконцентрировано в банковской сфере).

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

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

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

СЕМЬ ШАГОВ В "ОБЛАКО"

Основные этапы перехода к частному "облаку":

• анализ целесообразности и способа перевода тех или иных приложений в "облако";
• анализ готовности ИТ-инфраструктуры к переходу, определение направлений необходимого развития ИТ;
• модернизация ИТ-инфраструктуры, систем управления и систем обеспечения ИБ;
• построение или изменение процессов управления ИТ для соответствия "облачной" модели, развертывание "облачной" среды;
• миграция ИТ-сервисов в "облако".

Старший технический консультант EMC EMEA East Антон Жбан ков отмечает, что начать необходимо с проведения полной инвентаризации ИТ-активов и документации процессов для выяснения текущей позиции, с которой и будет осуществляться миграция: "Если у вас нет полного понимания ситуации с ИТ-активами, процессы взаимодействия бизнес-подразделений и ИТ складывались как-то сами по себе и не документированы, то эта стартовая позиция называется "бардак". Как говорит один мой коллега, не надо автоматизировать бардак - получится автоматизированный бардак. В приложении к "облакам" все будет точно так же, получится на выходе "облачный" бардак, еще более запутывающий участников за счет дополнительных абстракций. Поэтому необходимо в первую очередь навести порядок". Для проведения аудита Георгий Полихрониди, генеральный директор компании IBS Platformix, настоятельно рекомендует привлекать опытного внешнего "консультанта". Именно на этом этапе важно оценить целесообразность проекта, определить финансовые и организационные выгоды, если таковые будут. В результате аудита появляется возможность дать осознанный ответ, пожалуй, на главный вопрос: а стоит ли вообще переходить в "облако"?

Следующий шаг - используя полученную информацию об ИТ-активах, перейти к созданию каталога услуг, за которые отвечает ИТ-департамент: доступ к Интернету, электронная почта и так далее. Затем каждой услуге присваивается категория важности и бизнес-подразделения выставляют требования к RPO и RTO (Recovery Point Objective - условно количество данных, которые могут быть потеряны при сбое; Recovery Time Objective - время, в течение которого компания может не получать данную услугу). Переведя технологические параметры в рубли, можно получить допустимые потери денег компании при сбое. Исходя из этих цифр, совместно с ИТ-отделом обсуждаются варианты защиты этих услуг, ищется баланс между стоимостью защиты услуг и потерь компании при сбое.

Ключевой момент при переходе к "облаку" - анализ целесообразности и способа перевода тех или иных приложений.

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

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

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

Необходимо выбрать технологическую платформу. Существует масса параметров, на основе которых делается выбор, но главные из них - соответствие характеристикам и принципам будущей инфраструктуры, поддержка вендора, цена, изменение операционных расходов. "Можно ли найти провайдера виртуальной вычислительной платформы, на которой будут работать системы, оптимизированные для отечественных высокопроизводительных (для своего времени) мейнфреймов? - рассуждает Валерий Андреев. - Этот вопрос встает практически перед каждой организацией, инициирующей проект миграции в частное "облако". Точно можно сказать, что в выигрышном положении находятся компании, построившие свои ИС с использованием middleware, ориентированного на асинхронное взаимодействие элементов ИС. В принципе, такая архитектура позволяет проводить миграцию поэтапно и обеспечивать мирное сосуществование и согласованную работу традиционных и модернизированных участков ИС".

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

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

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

МИГРАЦИЯ

Миграция в частное "облако" пройдет с минимальными затратами в том случае, если соблюдается несколько условий, к Тесная интеграция ИТ и бизнеса, высокий уровень корпоративной ИТ-культуры. Нельзя избежать лишних расходов, если руководитель компании не считает свой ИТ-департамент провайдером ИТ-услуг. Часто ИТ воспринимается просто как исполнительная служба, в зоне ответственности которой лежит обслуживание компьютеров, принтеров и другого оборудования, к Качественный аудит, наличие полного комплекта проектной документации. Все участники процесса должны адекватно оценивать объем и состав ИТ-ресурсов, которые требуется перенести, к Необходим план миграции: все участники процесса должны четко понимать, кто, что и когда делает, к Каждый поставщик "облачных" решений имеет свои собственные наработки и методологии, но в целом при выстраивании процесса создания "облака" надо четко понимать требования и задачи бизнеса, ожидаемые им выгоды, после чего определять каталог сервисов (с учетом этапов) для развертывания в частном "облаке". В целом в процессе миграции должны быть четко определены этапы и состав работ. Обязательным является предварительное тестирование и включение в методику шагов по возврату изменений, а также вовлечение заинтересованных и компетентных пользователей со стороны бизнеса.

Как и любой крупный трансформационный проект, перенос ИТ-сервисов в частное "облако" следует начинать с составления каталога ИТ-сервисов, имеющихся в компании, и разделения их на критичные и некритичные. "Под некритичными понимают такие сервисы, простой или сбой которых не скажется негативно на основной деятельности организации, - поясняет Михаил Воронков, менеджер по развитию бизнеса компании Orange Business Services в России и СНГ - Критичными же могут быть, например, банковские транзакционные системы, выход из строя которых даже на несколько минут может принести значительные убытки.

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

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

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

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

Обратите внимание

Одна из существенных задач создания частного "облака" - рассмотрение целесообразности применения ПО для виртуализации. По заявлениям многих вендоров, без нее создать "облако" невозможно. Однако, как отмечает Игорь Литвинов, руководитель бизнес-направления аппаратно-программных комплексов компании "Микротест", на практике "облачный" принцип реализуем и без виртуализации. Самый известный пример - портал SalesForce. Один из основных поставщиков "облачного" сервиса работает без виртуализации, а вычислительную нагрузку распределяет специальное приложение. С технологической точки зрения важно следить, чтобы все элементы "облака" - СХД, сети, серверы - гарантировали определенное качество обслуживания для определенных приложений. Когда есть разделяемая ИТ-инфраструктура, важно уметь приоритизировать распределение ресурсов. На заключительном этапе (тестирования) происходит максимально полное испытание новой инфраструктуры на отказоустойчивость. Проверяется корректность переноса нагрузки на резервные вычислительные мощности, скорость реакции и сроки устранения неполадок. Георгий Полихрониди, генеральный директор компании IBS Platformix, обращает внимание еще на несколько моментов, которые следует предусмотреть в проекте на то время, когда частное "облако" будет введено в опытную эксплуатацию. Первым делом - время и возможности для устранения скрытых неполадок, которые всегда возникают при реализации крупных проектов. Во вторую очередь нужно разработать схему для дальнейшего масштабирования с учетом ограничений по количеству узлов, мощности, срокам и цене. Как правило, на этом этапе будет полезен привлеченный к проекту системный интегратор: схема масштабирования поддается типизации, поэтому нет нужды "изобретать велосипед", а возникающие неполадки хоть и всегда разные, но на их устранение у команды системного интегратора уходит куда меньше времени. Как показывает практика, даже компании, зарабатывающие деньги на ИТ, провайдеры публичных "облаков", иногда сталкиваются с крупными проблемами вследствие неверно выбранной архитектуры решения и даже несут прямые финансовые потери из-за технических сбоев или невозможности наращивать инфраструктуру соразмерно спросу на услуги. Поэтому имеет смысл не брать на себя риски самостоятельного проектирования и построения "облака", а "передать" их вендорам, готовым поставить интегрированное решение с минимальным временем развертывания.