Интервью c Григорием Корниловым (Kaspersky Lab)
Мы берём интервью у Григория Корнилова, старшего сервис менеджера Лаборатории Касперского. Григорий обеспечивает пользователей вычислительной инфраструктурой с использованием ресурсов облачных IaaS-провайдеров и отвечает за соответствие этого сервиса строгим корпоративным SLA.
Григорий расскажет нам о двухлетнем опыте использования IaaS и о том, как они пришли к решению использовать ресурсы внешнего облака.
Григорий, как давно и при каких обстоятельствах Лаборатория Касперского обратила свое внимание на облачные сервисы?
Использование «облачных» сервисов в инфраструктурной части началось 5 лет назад с небольшого проекта с компанией, которая построила для нас приватное «облако». Однако взаимодействие с этой компанией осуществлялось не столько как с сервис-провайдером, сколько как с компанией, которая разместила наше оборудование и поддерживала его без обязательств по функциональности среды виртуализации. Получилось, что мы купили оборудование, разместили его у сторонней компании, и она стала оператором нашего оборудования. Отсутствие формальной юридической ответственности за функциональность среды виртуализации сказывалось на отношении к нам и нашим запросам. Мотивация и скорость решения возникающих проблем нас не устраивали.
Это подвигло нас посмотреть в сторону сервис провайдеров, т.е. тех компаний, которые при работе с нами будут понимать ширину своей зоны ответственности. На тот момент у нас ожидалось достаточно крупное расширение, и нам не хотелось увеличивать количество своих администраторов, покупать свое железо, покупать стойко-места. Мы сделали определенные оценки и поняли, что сервис-провайдер сделает лучшее или сопоставимое по стоимости предложение, а трудозатраты на развитие инфраструктуры будут минимальны. Также по опыту могу отметить, что сервисы обычно дешевеют, а свои сотрудники, наоборот, дорожают. Таким образом, было решено использовать облачную инфраструктуру сервис-провайдера, четко регламентировав то, за что готовы отвечать мы, а за что должен отвечать сервис-провайдер.
Вы рассматривали только российских облачных провайдеров или западных игроков в том числе?
В первую очередь мы, конечно, рассматривали российских представителей, так как нам требовалось организовать качественную сетевую связанность с нашей инфраструктурой. Изучив рынок, сертификации компаний, практику предоставления облачных сервисов, мы поняли, что данный сегмент рынка IT услуг наиболее развит в Москве и Санкт-Петербурге.Мы рассматривали нескольких европейских сервис-провайдеров, но значительных преимуществ для себя не обнаружили. Кроме того, при размещении за рубежом появляются вопросы по сетевой связанности, по быстродействию, а по менталитету, по разнице во времени, когда третья линия специалистов находится в другой временной зоне. Все эти факторы могли негативно сказаться на уровне поддержки сервиса. Потому предпочтение было отдано именно российскому сервис-провайдеру. Что касается стоимости, то я бы не сказал, что сервисы на западе существенно выгоднее.
Григорий, с чем связана тенденция удорожания стоимости своих сотрудников?
Держать в своем штате сотрудников, которые поддерживали бы решение самостоятельно, проблематично. Это специалисты очень высокого уровня. Критически важной задачей нашей компании является поддержка бизнес процесса выпуска обновлений, который должен работать 24/7. Получается, что нам надо было бы вкладываться в круглосуточную службу поддержки, в том числе в высококлассных специалистов. А уж стоимость высококлассных специалистов в Москве только растет.
Григорий, рассматривали ли вы услугу аренды выделенных физических серверов? В интернете по-прежнему ходит очень много споров и сравнений аренды облачных и dedicated серверов.
Мы не рассматривали вариант dedicated серверов, потому что у нас основные затраты уходят на системных администраторов, которые работают не с серверами, а с программным обеспечением виртуализации. Это самые дорогие специалисты. Поэтому, если и пользоваться услугами стороннего сервис-провайдера, то уж точно включая администрирование виртуальной среды.
У нас есть достаточный опыт аренды стойко-мест, приобретения оборудования и его эксплуатации. Мы знаем, какая линия поддержки сколько стоит. Оставить самую ценную часть себе — все равно что не сделать шаг в направлении сервиса. Обычно действительно серьезные проблемы случаются не с оборудованием, которое задублировано и по юнитам и по составляющим элементам. Поэтому отдавать сервис-провайдеру только хостинг — неэффективно.
Григорий, при рассмотрении облачных провайдеров на какие параметры вы обращали внимание?
Мы сформировали свое видение сервиса, который мы хотим получить. Сразу отмели провайдеров, которые были не согласны с нашим SLA (например, запрошенными штрафными санкциями) или с распределением зон ответственности, которое мы ожидали. Также мы отмели сервис-провайдеров, которые были не согласны с нами по техническим моментам. Наши пользователи привыкли работать с определенным инструментарием в рамках нашей собственной инфраструктуры, в связи с чем мы выдвинули требование к провайдеру предоставить идентичный инструментарий для работы с облаком. Это основные моменты.
Много ли сервис-провайдеров отказалось, увидев ваш SLA?
Из восьми один отказался, его не устраивал запрошенный нами инструментарий и требуемый SLA.
О каком инструментарии идет речь?
Нам необходим доступ к управлению ресурсными пулами и виртуальными машинами напрямую в VMware vCenter. Мы определили, что сервис-провайдер будет ответственен за общую среду виртуализации, а нам будет предоставлять урезанные административные права на конкретные ресурсные пулы, чтобы наши администраторы самостоятельно создавали новые машины, подключали, выключали. Отказавшийся сервис-провайдер настаивал на использовании VMware vCloud Director, управление через который существенно отличается от уже используемого нами vCenter.
Я правильно понимаю, что вы рассматривали только тех сервис-провайдеров, которые также используют VMware?
Да. Наши администраторы, которые работают с виртуальными машинами (не поддерживают виртуализацию, а именно работают с виртуальными машинами), привыкли работать с vCenter. Переучивать их на другой интерфейс, заставлять работать в различных средах — это дополнительные и ненужные затраты.
Григорий, насколько глубоко вы изучали провайдеров? Проверяли ли вы реальное соответствие возможностей выполнить заявленный SLA?
Изучение провайдеров мы начинали с проверки наличия их сертификации у вендора, смотрели каким партнерским статусом они обладают. Смотрели качество дата-центров, на базе которых будет реализован сервис, изучали опыт работы сервис-провайдера с решениями VMware.
Очень важным моментом для нас была компетенция сервис-провайдера по системам хранения данных, на наш взгляд это самая сложная вещь в инфраструктуре. Выход из строя сервера приводит к небольшому даунтайму части виртуальных машин, потому что среда виртуализации перезапустит их на резервных серверах. А выход из строя хранилища может «положить» практически все виртуальные сервера сразу. Бывают случаи, когда неправильно установленное программное обеспечение может привести к недоступности всего хранилища.
Обычно используется одна система хранения данных, полностью задублированная и отказоустойчивая в конфигурации от производителя. В этом случае крайне важна компетенция сотрудников, которые управляют и обслуживают данное хранилище. Причем недостаточно статуса, подтверждающего большие объемы продаж системы хранения данных в целом. Необходимо, чтобы были именно сертификаты для администраторов хранилища.
Обращали ли вы внимание на уровень хранилища, его конфигурацию, типы дисков?
Да, мы требовали систему хранения данных не менее чем Mid-range уровня. Чтобы любые операционные работы по обновлению хранилища проводились без какого-либо даунтайма. Это было нашим обязательным условием.
Исходя из собственной практики использования системы хранения данных, мы уже заранее знали, какая нам примерно нужна конфигурация дисковой подсистемы. Это мы тоже определили как требование. Сервис-провайдеры со своей стороны предлагали дополнительные бенефиты (кэши, твердотельные диски).
Какие задачи были вынесены вами в облако?
В нашей компании есть бизнес-процесс выпуска обновлений модулей и антивирусных баз наших антивирусных продуктов. Этот процесс критичен, 24×7 постоянно работающий конвейер, гарантирующий, что обновление протестировано на всех поддерживаемых платформах и вовремя предоставлено нашим пользователям.
Весь штат специалистов, выпускающих эти обновления, работает в круглосуточном режиме?
Да, в процессе задействованы круглосуточные службы системных администраторов, разработчиков и вирусных аналитиков. Если бы этот процесс приостановился, то наши продукты стали бы менее качественно обеспечивать антивирусную защиту, а этого нельзя допустить.
Как выглядит процесс запроса ресурсов для вашего внутреннего заказчика?
Для внутреннего пользователя нет принципиальной разницы, откуда он получит необходимые ресурсы. Пользователь может отправить запрос в нашу внутреннюю службу IT поддержки на расширение какого-то ресурсного пула или на создание нового ресурсного пула. Пользователь знает, что бюджет, который компания наша заплатит за ресурсные пулы, потом будет классифицирован по пользователю и будет проведен внутренний биллинг.
Отмечу также, что внутренний пользователь предупрежден, что определенный уровень расширения ресурсов требует определенного времени. Обратиться же к внешнему сервис-провайдеру за дополнительными ресурсами может только согласованное контактное лицо.
Насколько жесткие значения параметров вы включили в SLA сервис-провайдера?
Мы исходили из того, что SLA с внешним сервис-провайдером должен быть строже, чем наш SLA перед нашими внутренними пользователями.
2 часа — это максимальный простой, который мы допускаем для сервис-провайдера, с учетом того, что у нас это не единственная среда. Есть собственная вычислительная мощность, которая может компенсировать риски, связанные с даунтаймом.
Если простой составит больше двух часов, то уже идут штрафные санкции. Штраф в размере оплаты 100% стоимости за месяц достигается при простое сервиса более двух суток.
Подводили ли вы промежуточные итоги работы вашей инфраструктуры в облаке?
Безусловно, подводили. Мы собрали статистику по доступности сервиса и обсудили ее с нашим внутренним бизнес-заказчиком. Качество сервиса было оценено на твердую пятерку. Единственным пожеланием было реализовать сервис от второго провайдера с таким же качеством, чтобы уменьшить зависимость от одного сервис провайдера.
Каким образом вы измеряете доступность сервиса? Используете ли какие-нибудь средства мониторинга?
Безусловно, доступность сервиса контролируется нашими системами мониторинга, посредством них мы отчитываемся перед внутренним заказчиком. Проблемы могут возникнуть не только у сервис-провайдера, но и на стыке инфраструктур или на нашей стороне. Стоит отметить, что наш внутренний SLA более широк, чем SLA сервис-провайдера.
Планируете ли вы перенос в облако других сервисов?
Сейчас таких планов у нас нет. Отмечу, что собственная инфраструктура, скорее всего, у нас и останется. Нам необходима внутренняя компетенция и минимальный уровень независимости.
Выдвигали ли вы дополнительные требования к сервис-провайдеру, о которых мы еще не говорили?
Да, например, интеграция систем сервис-деск. Нас не устраивал вариант, при котором кто-то должен куда-то зайти и что-то сделать, чтобы завести заявку. Мы определили требование по реализации интеграции IT сервис-деск систем на основе обмена е-мейл сообщениями определенного формата.
Пользователь обращается в IT сервис-деск нашей компании. В нашей системе специалист службы поддержки назначает заявку на определенную группу. Автоматически при этом сервис-провайдеру отправляется запрос на согласованный почтовый ящик. Сервис-провайдер отвечает в определенном формате, чтобы его ответ привязывался к изначальной заявке в нашей системе IT сервис-деск и сразу же был виден нашему пользователю. Таким образом, мы ускоряем взаимодействие сервис провайдера и пользователя, уменьшаем нагрузку на первую линию нашей службы поддержки.
Григорий, какой совет вы можете дать коллегам из других компаний, которые сейчас задумываются об использовании облаков?
В первую очередь нужно согласовать со своей службой безопасности то, какие данные вы хотите отдать на сторону сервис-провайдера. Служба безопасности определит, что можно отдавать и что нельзя. Мы такую оценку рисков проводили и ввели определенное ограничение на использование данного сервиса.
Большое спасибо.
До свидания.
Интервью брал Сергей Чуканов, директор по развитию компании ИТ-ГРАД
