«Рольф»: подготовка к миграции в облако

ГК «Рольф» — один из крупнейших в России автомобильных бизнесов, включающий в себя подразделения с различной спецификой бизнес-процессов. Как и большинство других подобных предприятий, в результате экономического коллапса компания начала поиск путей оптимизации затрат на ИТ и снижения ТСО. Однако, как оказалось, ИТ-инфраструктура не только не могла быть оптимизирована, но и требовала дополнительных капитальных вложений, хотя бизнес сокращал расходы. Данная инфраструктура включает в себя 380 серверов, мощные хранилища данных и систему резервного копирования. Большая часть центральных систем и серверов сосредоточена в главной серверной комнате, остальное распределено по дилерским центрам (28 в Москве и Санкт-Петербурге). Кризис приостановил плановое обновление парка оборудования, и в 2010 году компания оказалась в ситуации, когда главная серверная была переполнена оборудованием возрастом три–пять лет, большую часть которого следовало заменить в ближайшие два года. В дополнение ко всему сама серверная нуждалась в расширении и обновлении инженерных коммуникаций.

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

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

В итоге, сделав необходимые оценки, мы подошли к решению о переводе ИТ-инфраструктуры в облако внешнего провайдера.

Выбор провайдера

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

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

Для большинства серверов и систем нам ближе оказалась модель IaaS (Infrastructure as a Service). При выборе мы руководствовались следующим принципом – выбирать тот уровень услуги, бизнес-кейс которой мы способны рассчитать, показав эффективность. Чем выше уровень услуги, тем выше должен быть уровень зрелости ИТ в компании — должно быть четкое понимание, из чего складываются затраты на поддержку сервиса внутри компании и как повлияет на стоимость его перевод к внешнему провайдеру. Кроме того, должен быть четко определен план развития сервиса, количество изменений и качество (или наличие) процессов работы с ним у бизнеса.

С серверами все просто — подсчитать их реальную совокупную стоимость владения (Total Cost of Ownership, TCO) несложно, а развития сервиса как такового вообще нет. Сложнее с платформой (Platform as a Service, PaaS) или программным обеспечением (Software as a Service, SaaS) — здесь не всегда очевидны тенденции развития бизнес-приложений, количество доработок и кастомизаций, которые захочет бизнес. Не всегда ясно, насколько рационально используется сервис сейчас, быть может, стоит сначала привести все в порядок и только потом осуществлять перенос. И само собой, почти у каждой компании есть свой уникальный «самописный код», который не возьмется поддерживать ни один провайдер, поэтому для таких систем подойдет только IaaS. Покупка сервисов по моделям PaaS или SaaS должна быть очень детально рассчитана, в противном случае компания может получить громадные затраты на дополнительные изменения в будущем или завышенный счет из-за нерационального использования заказанного обслуживания.

В конце концов мы решили, что по модели SaaS будем покупать электронную почту (антиспам-сервис включен), антивирус и резервное копирование – эти сервисы достаточно статичны и не требуют сильной кастомизации. Мы решили перевести на PaaS такие сервисы, как SAP HR, серверы баз данных Microsoft SQL Server и Oracle, как только детально просчитаем модель затрат и оптимизируем использование. Переводить на SaaS собственные бизнес-приложения «Рольф» пока не планируется — они постоянно изменяются и дорабатываются и их пока проще и выгоднее реализовывать своими силами. Перевод остальных сервисов в облако не так рискован, поскольку платформа чаще всего стабильна и для поддержания работоспособности требует лишь рутинных операций и четко отстроенных процессов. Все остальное мы переводим в IaaS с оплатой за сервер (виртуальный или физический, в зависимости от мощности) и за гигабайт, если речь идет о хранении данных: почта тарифицируется по количеству почтовых ящиков определенного объема, сервис резервного копирования — за гигабайт данных; антивирус включен в стоимость сервера (см. рисунок).

Схема потребления облачных услуг

Теперь наступило время подключения бизнеса, основная задача которого в данном проекте состояла в согласовании будущего каталога услуг и соглашений об уровне обслуживания (Service Level Agreement, SLA), а также в финансировании проекта.

Если бизнес до перехода ИТ в облака никогда не видел каталога услуг и SLA на текущие сервисы, то у ИТ-директора обязательно возникнут проблемы. Во-первых, бизнес может не понять разделение «единого ИТ» на отдельные сервисы с отдельным SLA и биллингом. Во-вторых, внедрение SLA – это тяжелый и трудоемкий процесс. Сложно объяснить бизнесу, что на самом деле ИТ-инфраструктура компании осознанно работает не со стопроцентной надежностью и не может молниеносно выполнять все заявки. Внедрение культуры в соответствии с ITIL в ИТ-департаменте необходимо проделать задолго до перехода в облака.

На этапе формирования SLA требуется активное участие бизнеса — необходимо определить стоимость простоя бизнес-приложений и сервисов, чтобы подобрать адекватное SLA. Потратив на это столько времени, сколько потребуется, можно существенно сократить общую стоимость контракта, сохранив при этом лояльность бизнеса и его ожидания относительно качества будущих услуг. В нашем контракте для каждого приобретаемого сервиса есть три уровня доступности: 98, 99 и 99,5%. Разница в стоимости ИТ-инфраструктуры, способной обеспечить 99 и 99,5%, может быть более чем в два раза в связи с применением принципиально других технологий и уровня избыточности.

К счастью, задолго до проекта у нас уже был свой каталог услуг и SLA, согласованные с бизнесом, но все равно потребовались усилия для приведения типов сервисов к единообразию (деление на сервисы внутри ИТ-департамента компании может не совпасть с делением у провайдера) и ранжированию сервисов с точки зрения критичности для бизнес-процессов. Для того чтобы назначить соответствующее SLA облачным сервисам по доступности, потребовались отдельные усилия — у бизнеса был соблазн заказать все сервисы с максимальным уровнем надежности, не осознавая, зачем это реально нужно и сколько это будет стоить. В итоге нам удалось снизить SLA по доступности от изначально запрошенного бизнесом уровня 99,9% (наивысший) для 80% наших систем до нормального распределения, где наивысшую степень надежности (и стоимости) имеют действительно самые критичные для бизнеса сервисы и приложения, например ERP, которых не очень много.

Для инициации проекта был подготовлен бизнес-кейс, подготовка которого при наличии подробного текущего бюджета и модели затрат на поддержку ИТ-сервисов достаточно проста. Был взят ИТ-бюджет компании на пять лет, в котором обнулились ненужные для облака статьи и затраты и прибавились затраты на само облако. Итоговую сумму сравнили с пятилетним бюджетом по сценарию «без облаков». Разница получилась положительная, но не большая. Стоит отметить, что даже нулевая разница в бюджетах, на наш взгляд, хороший результат. Облака дают ряд преимуществ, которые трудно оценить в денежном эквиваленте, но они однозначно дают преимущества бизнесу. Основная идея проекта – не сократить бюджет, а приумножить доходы бизнеса. Гибкость, масштабируемость и гарантированное соблюдение реального SLA по доступности дадут бизнесу больше, чем простая экономия ИТ-бюджета.

Наш бизнес-кейс и контракт были рассчитаны на пять лет — меньший срок не давал окупаемости, а миграция в облака более 150 серверов означает прежде всего стратегическое долгосрочное партнерство. Таким образом, провайдер становится единственной точкой контакта и влияния, а, однажды мигрировав в облако, обратно что-то изменить (переход к другому провайдеру, возврат на собственные мощности) будет очень сложно и дорого. Поэтому первый важный критерий, который мы определили для себя, – поставщиком должна быть крупная международная компания, имеющая богатый опыт подобных проектов как в России, так и за рубежом, присутствующая на российском рынке не менее пяти лет.

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

Пожалуй, самым тяжелым на этапе аудита и выбора поставщика было сравнение каталогов услуг. У нас был собственный каталог, сформированный на основе наших пожеланий и знания рынка облачных сервисов, и еще два каталога от каждого из провайдеров. Оказалось, что сравнить даже такую достаточно простую услугу, как «сервер как сервис», в разных каталогах очень сложно. Начиная от чисто технических параметров (характеристики серверов, шаг наращивания мощности), разных типов SLA (разные уровни надежности и метрики восстановления при отказах) и заканчивая финансовыми показателями (минимальное время использования, срок и стоимость подачи сервиса). Даже такая простая услуга, как сервис резервного копирования, у обоих поставщиков описывалась и оценивалась по-разному. У одного было разделение на резервирование файлов, базы данных и тестовых систем с оплатой за гигабайт резервируемой информации с диска. А у другого резервное копирование делилось только на ежедневное и еженедельное при оплате места, занимаемого непосредственно на ленте, без разделения на то, что именно резервируется. Кроме того, провайдеры предлагали разное время хранения информации на лентах.

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

Ответственность за работоспособность не подразумевает изменений в системе. Хотите поменять имя сервера, изменить параметр реестра или просто поставить «галочку» среди сотен настроек ОС – пожалуйста, но если это не связано с тем, что сервер «плохо» работает. В таком случае это рассматривается как изменение, которое может тарифицироваться по отдельному прайс-листу на дополнительные работы. Сами вы эти изменения провести не можете, так как провайдер, что справедливо, забирает себе административные права, иначе невозможно гарантировать надежность.

Эти и другие нюансы, конечно же, должны быть предусмотрены в контракте — важно обратить особое внимание на то, что нужно как можно глубже вникать в детали всех предоставляемых сервисов, моделировать ситуации, как организована работа сейчас и как будет осуществляться через провайдера. Многие операции сегодня инженеры компании делают не задумываясь, как рутинные; например, если нужно перезагрузить сервер – пошел и перезагрузил. Но в облаках у внешнего провайдера такая операция означает выдачу запроса на обслуживание или изменение, отрабатываемого по своему SLA через службу Service Desk и, возможно, имеющего свою стоимость. Это не хорошо и не плохо — это иной подход к организации труда: от хаотичного нажимания кнопок к размеренной и планируемой работе, к дисциплинированности и ответственности за каждое действие. К этому нужно быть готовым.

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

Планирование

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

Во-первых, это тип миграции. Мы выбрали полную переинсталляцию систем в облаке. В случае IaaS, провайдер предоставляет уже полностью сконфигурированный для конкретных бизнес-приложений сервер. Процесс инсталляции приложений достаточно трудоемкий, требующий высокой степени организации внутри ИТ-департамента. Для всех приложений нужно иметь документацию, полное понимание особенностей их работы, планы аварийного восстановления и опыт их применения — ведь фактически все будет восстанавливаться на пустом месте. Может потребоваться дополнительный бюджет, так как многое ПО может находиться на поддержке разработчиков, а без их помощи не справиться. Но зато можно построить абсолютно новую среду, а весь предыдущий зоопарк операционных систем, разных версий и степени обновления, со своими историческими ошибками превратится в набор стандартных ОС. Кроме того, вы получите опыт тестирования процессов реализации плана восстановления после аварий (Disaster Recovery Plan, DRP) по всем вашим приложениям. Миграция типа P2V (Physical-to-Virtual) – создание образа текущего работающего сервера и запуск его в виртуальной среде — не даст такого эффекта, к тому же провайдер может сильно занизить SLA по доступности или вовсе отказаться отвечать за ОС: никто не знает, какие баги хранят ваши ОС, кто и как с ними работал последние несколько лет.

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

Риски проекта

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

Все взаимоотношения с провайдером управляются с помощью договора — крупный провайдер будет дорожить своей репутацией на рынке и может быть более гибким за счет своего масштаба. Поэтому мы можем порекомендовать лишь тщательно подходить к выбору провайдера — в конце концов, большинство других, более привычных нам сервисов тоже нам уже давно не подконтрольны, например электроснабжение или каналы данных. Отдельным риском является закон о защите персональных данных (ФЗ-152) с его неопределенностью в трактовках. Здесь наша позиция такова: на сегодняшний день и контракт, и поставщик услуг полностью соответствуют закону, а гадать, когда начнется правоприменительная практика, смысла нет, она все равно не даст гарантий. Более того, использование облачных мощностей за границей, как в нашем случае, наоборот, упрощает задачу. Ведь по закону поставщик, ЦОД и т. д. должны соответствовать всем законам страны, на территории которой размещаются данные. В нашем случае данные размещаются в Германии, где HP присутствует много лет и имеет все необходимые сертификаты и согласования.

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

Второй технический риск – несовместимость приложений при миграции. Этот риск можно сократить до минимума путем выбора правильного поставщика и типа облаков. Во-первых, и сейчас, и в облаке мы используем серверы HP, имеем возможность выбирать как виртуальные, так и физические, поэтому риск несовместимости ПО с технологией виртуализации отпадает. Во-вторых, если нас в будущем не устроит какой-либо публичный сервис, например система хранения данных, допустим из-за ограниченности в его кастомизации, то всегда можно перейти на приватный вариант (HP предоставляет подобную возможность). Конечно, это потребует определенных затрат, но обеспечит благоприятный для бизнеса выход.

Планы

По состоянию на лето 2011 года проект находится в фазе активной миграции: настроена интеграция с сетями передачи данных и сервисом каталогов ActiveDirectory провайдера; проведена пилотная миграция тестового контура одной из бизнес-систем; полностью настроены и получены в использование более 30 серверов, на которые осуществляется миграция первой группы приложений. Полностью завершить миграцию планируется в октябре 2011 года.

После реализации первой части проекта развитие будет осуществляться по двум направлениям. Во-первых, уже сейчас идет аудит и формирование бизнес-кейса на проект создания инфраструктуры виртуальных настольных систем (Virtual Desktop Infrastructure, VDI) для всех рабочих мест ГК «Рольф» в облаке HP. Это позволит передать в облако остаток серверов, которые пока не могут быть перенесены из-за высокой скорости доступа к ним с ПК, например файловые серверы. Кроме того, даст возможность расширить каталог сервисов, оптимизировать поддержку пользователей, используя все преимущества VDI плюс гибкость и масштабируемость облачных технологий.

Во-вторых, будет проведен переход с модели IaaS на PaaS или SaaS. Получать инфраструктуру как сервис конечно же удобно, но серверы – это лишь платформа для бизнес-приложений, где также будут применимы все преимущества сервисного подхода. Мы планируем провести аудит и внедрить процессы управления для ряда приложений и потом передать их провайдеру облачных сервисов. Таким образом, ИТ-департамент группы компаний «Рольф» в большей степени будет сосредоточен на эффективном управлении сервисами и проектами по развитию основного бизнеса компании. По нашему мнению, штат ИТ-департамента любого не ИТ-бизнеса в эпоху облаков должен состоять из сервис-менеджеров, бизнес-аналитиков и менеджеров проектов.

***

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

Андрей Якимов (aayakimov@rolf.ru) – руководитель ИТ-инфраструктуры группы компаний «Рольф» (Москва).