Семь раз примерь: выбор поставщика IaaS- и SaaS-сервиса

Логотип компании
Семь раз примерь: выбор поставщика IaaS- и SaaS-сервиса
Важнейшим плюсом при использовании IaaS-сервиса являются сохранение пользовательских интерфейсов и отсутствие необходимости менять «пользовательский опыт».
В недавнем выступлении на пользовательской конференции Amazon Web Services старший вице-президент компании Энди Джесси (Andy Jassy), говоря о преимуществах полного переноса ИТ-операций в облако, обозначил новую тенденцию – повсеместное использование облаков не только для второстепенных задач, но и для критически важных или даже вообще всех ИТ-операций компаний. 

Сегодня облака могут стать источником для предоставления трех основных типов сервисов: инфраструктурных (Infrastructure as a Service, IaaS), включающих серверы, системы хранения и сетевые ресурсы; платформных (Platform as a Service, PaaS), необходимых для развертывания приложений; бизнес-приложений, необходимых для доставки приложений по подписке (Software as a Service, SaaS). Мы рассмотрим выбор поставщика IaaS- и SaaS-услуг.

Особенности SLA и NDA при выборе Iaas-сервиса

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

При выборе провайдера необходимо изучить два ключевых документа: SLA (соглашение об уровне сервиса, правила оказания услуг) и NDA (соглашение о конфиденциальности).  Если что-то вам обещают на сайте провайдера, но эти обещания никак не описаны в SLA/NDA, то считайте обещания пустыми. Мало того, отсутствие описания важного для вас процесса говорит о том, что он не налажен у провайдера.
Что обязательно должно быть прописано в SLA/NDA:

1. Зона ответственности облачного провайдера 

Правильный сервис-провайдер должен четко обозначить, за что отвечает он, а за что – вы или ваш ИТ-специалист. Обычно эта граница по умолчанию проходит по уровню «виртуальная машина как объект гипервизора». Всё, что ниже этого уровня,  – зона провайдера, всё, что выше, – ваша. 

2. Гарантии качества, надежность

Стандартно под «SLA 99,9%, 99,95%» подразумевается процент работоспособности (доступности) в течение определенного времени. Период расчета SLA в один месяц – это хорошо. В данном случае речь идет о максимальной недоступности в продолжение около 40 минут в течение месяца, что абсолютно нормально практически для любого бизнеса. Если же речь идет о годе, то стоит задуматься, так как, например, «не более восьми часов простоя в год» может означать, что эти восемь часов могут продлиться непрерывно. А это целый рабочий день, что недопустимо, но провайдер не понесет за это ответственности.
Качество работы, которое можно косвенно оценить, должно быть прописано по измеримым параметрам:  скорость ввода-вывода к диску, загрузка процессора, задержки в канале, контроль свопинга ВМ. За несоответствие провайдер несет ответственность.  

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

Следует обратить внимание и на то, какую финансовую гарантию готов нести провайдер. Для вас сумма в месячную абонентскую плату несущественна, а для провайдера, который допустил серьезный простой, это может быть 1/12 годовой выручки, что недопустимо. Отсюда ответственность размером в месячную абонентскую плату за несколько часов простоя очень существенна и вряд ли будет допущена провайдером.

Не менее важно, насколько провайдер готов к существенным авариям, которые могут вывести из строя любой элемент инфраструктуры, включая ЦОД. В SLA понятно, думал ли он вообще об этом.

Неотъемлемым элементом обеспечения надежности является резервное копирование. В SLA должно быть прописано: что, как, когда и куда копируется (план резервного копирования), как получить доступ к резервным копиям, как мониторится резервное копирование, какой канал от резервной копии до боевой системы или в Интернет. 

3. Конфиденциальность

NDA (соглашение о конфиденциальности) регулирует данный вопрос и помогает понять, как провайдер относится к вашей информации, за что готов нести ответственность. В нем как минимум должно быть прописано: определение конфиденциальной информации, регламент доступа и обработки провайдером  конфиденциальной информации клиента, ответственность провайдера за нарушение конфиденциальности.  

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

4. Эластичность и самообслуживание

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

Нужно проверить, есть ли SLA на доступность портала самообслуживания, как реализована его отказоустойчивость.

5. Доступность 

Если облако работает безупречно, но постоянно падает ваш канал в Интернет, то работать все равно не получится. Здесь важны сетевая инфраструктура провайдера и понимание, за какой сегмент он несет ответственность, отвечает ли и может ли влиять на своих канальных провайдеров. На самом деле ситуация это нечастая, и реальный SLA каналов в Интернет сейчас очень высокий.

Никто не застрахован от DDoS-атак. Они могут априори «завалить» практически любого провайдера. Поинтересуйтесь организацией сетевой инфраструктуры: есть ли независимые сетевые сегменты, готов ли провайдер вас разместить именно там, как быстро, и т. д.

6. Дополнительные инфраструктурные сервисы

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

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

Второй пример – получение системы безопасности как сервис (SecaaS). Ситуация аналогична предыдущей. Комплексные решения, устраняющие большой перечень угроз, стоят дорого и очень громоздки в эксплуатации. Если воспользоваться сервисом, то гибкость, мощность и возможности настройки сохраняются, а проблемы эксплуатации, обновления и т. д. уходят. Для эксплуатации средств безопасности требуется высокая квалификация специалиста. Если у клиента нет желания или возможности получить специалиста с такими знаниями, можно воспользоваться услугой «Управляемый (Managed) SecaaS», когда и настройку и мониторинг также выполняет провайдер. 

Конечно, на каждый дополнительный инфраструктурный сервис должен быть свой SLA.

7. Программное обеспечение

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

Нужно обратить внимание на наличие у провайдера (его лицензионный договор с вендором) права на предоставление ПО в аренду и на право, которое передается вам. Что вам можно, чего нельзя, как это право оформлено. Вы сможете предъявить указанные документы в случае проверки.

8. Техподдержка

«24×7» очень часто означает реакцию в режиме «24?7», то есть «ваша заявка принята» и не более. Соответственно, должны быть описаны типы обращений: инциденты, запрос на обслуживание, консультация и режим их выполнения. Как минимум инциденты должны быть ликвидированы в режиме «24?7» с гарантированными сроками.

9. Процедура расторжения договора

Когда женитесь, правильно подумать о том, как будете разводиться. Если бы все делали так, то брачные контракты стали бы нормой и не было бы стольких трагедий. С облаками такая же ситуация. Обращайте внимание на ответственность провайдера при расставании.

IaaS-платформа оперирует виртуальными машинами, поэтому в SLA должны быть четко прописаны процедуры передачи образов виртуальных машин, формы передачи и сроки, а также процедуры удаления и «зануления» удаляемых данных. Удобно, если эти функции вынесены в портал самообслуживания.

Особенности Saas-сервиса и его выбора

SaaS-сервисы предоставляют конечный сервис для конечных бизнес-пользователей. SaaS предлагает себя как альтернативу сложным офисным внедрениям и содержит в себе всю ИТ-составляющую. 

Помимо перечисленного выше, необходимо определиться с ответами как минимум на следующие дополнительные вопросы:

1. Интеграция с вашей системой безопасности

Обычно система безопасности небольшой компании построена на основе Active Directory, встроенного в Windows Server. Удаление или блокирование пользователя в AD приводит к гарантированному прекращению доступа сотрудника к корпоративным данным, поэтому важным показателем зрелости SaaS-сервера корпоративного уровня является возможность интеграции с вашим AD. 

2. Изоляция ваших данных

SaaS почти всегда предоставляется в режиме multitenant, то есть много клиентов (организаций) на одной инсталляции системы. Есть два уровня изоляции данных: отдельная БД либо одна база данных и ваши данные определяются в ней по ключу. Понятно, что второй вариант не позволяет устроить хорошую изоляцию данных, например любая ошибка разработчика может привести к тому, что ваши данные станут доступны другим клиентам SaaS-сервиса. Также в таком варианте невозможно организовать защиту персональных данных в соответствии с требованиями 152-ФЗ. 

3.  Возможность получения и использования данных вне сервиса

Если вы пользовались «1С», то достаточно получить базу (это должно быть прописано в SLA) и перенести на другой сервис. Если вы пользуетесь уникальным CRM-сервисом, то у него должен быть экспорт значимых данных: контакты, заказы, которые, возможно, можно будет пакетно загрузить в другой сервис или в локальную систему.
Для некоторых известных SaaS-сервисов этот риск крайне маловероятен, но если вы пользуетесь молодым интересным сервисом, то, к сожалению, риск актуален. Вообще, чем более развиты средства интеграции провайдера, тем безопаснее его использование.

Хорошим примером зрелого SaaS-сервиса является Office 365 корпорации Microsoft, который удовлетворяет всем перечисленным требованиям и возможностям миграции и интеграции.

Обязательно попробуйте

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

Опубликовано 24.12.2014

Похожие статьи