Поставщики облачных услуг предоставляют различные гарантии, среди которых есть доступность сервисов и ресурсов, которые указываются в соглашении об уровне обслуживания. Чаще всего это соглашение обозначают аббревиатурой — SLA, и в этой статье мы поговорим о важных нюансах, которые должны быть прописаны в SLA IaaS-провайдера (пример SLA 1cloud).
/ Flickr / Dennis Skley / CC
Все большее число приложений и объем вычислительных задач переходят на IaaS. Поэтому IaaS-провайдеры стараются гарантировать клиентам определенный уровень безопасности и комфорта и подстраиваться под изменяющиеся требования рынка, а также законодательства стран, в которых они предоставляют услуги. Все это приводит к изменениям в SLA.
«Некоторые аспекты в SLA облачных провайдеров на сегодняшний день устарели или, более того, вызывают замешательство. Например, есть поставщики, которые в своих SLA прописывают запрет на распространение информации о сбоях в работе инфраструктуры, — рассказывает специалист в области облачных сервисов Дэвид Линтикум (David Linthicum). — Что совершенно не помогает ни самому провайдеру, ни его клиентам, поскольку сложно назвать такие условия честными».
В попытке стандартизировать и предоставить рекомендации по составлению соглашения об уровне обслуживания Европейская комиссия начала продвижение документа, целью которого является обеспечение большей прозрачности для бизнесов при работе с облачными сервисами и изучении SLA. Инициатива получила название SLALOM и, как отмечает CIF, она позволит «снизить неопределённости» при миграции инфраструктуры в облако.
В новом документе собраны предложения и практики от влиятельных игроков облачного рынка. «Команда составила список терминов из сферы облачных вычислений, которые покрывают все аспекты отношений между провайдером и клиентом», — говорит Оливер Баррето (Oliver Barreto) из Atos.
Сам документ SLALOM вы можете найти по ссылке, а далее мы разберем несколько первоочередных пунктов, на которые следует обратить внимание провайдеру при составлении своего соглашения об уровне обслуживания.
Уровень доступности
В SLA облачного провайдера должны быть определены ключевые метрики, описывающие работоспособность облачного сервиса. Речь идет о доступности сервиса, количестве пользователей, способных получать доступ к сервису одновременно, а также времени, необходимом для обработки транзакций пользователей. Например, IaaS-провайдер может гарантировать доступность приложений 99,5% времени.
Также следует обозначить временные рамки, в которые этот уровень доступности обеспечивается, чтобы у клиентов не возникало вопросов. Если продолжать пример, то провайдер может обеспечивать доступность приложений до 99,5% времени с 8 часов утра до 8 часов вечера в будние дни. Этот параметр имеет свое название — согласованное время работоспособности услуги, или СВР.
Однако отметим, что при выборе провайдера обращать внимание только на «процентовку» не следует, нужно также учитывать, насколько провайдер готов к решению возникающих проблем и трудностей. Например, мы в компании 1cloud предлагаем резервное копирование, выполняющееся раз в сутки, чтобы защитить данные пользователей от утери в случае нештатных ситуаций. Копирование выполняется на удаленный дисковый массив, что делает данные доступными для восстановления даже при недоступности файловой системы сервера (и в случае выполнения пользователем необратимых действий).
Исключения
В SLA необходимо прописать допустимые условия, при которых провайдер не гарантирует указанные доступность и производительность. Поскольку этот раздел освобождает поставщика от выполнения своих обязанностей, список ограничений должен быть строгим и коротким.
Например, ограничение доступности во время проведения плановых технических работ и обновления программного обеспечения, а также в случае возникновения непреодолимой силы, в частности, отказа оборудования третьих лиц. Еще один вариант — отказ программного обеспечения вследствие нарушения клиентом рекомендаций, прописанных в документации к продукту.
Также в SLA следует отметить гарантии доступности интерфейса управления виртуальной инфраструктурой. Это позволит избежать недопонимания и других инцидентов в случае, когда клиенту потребовалось экстренно увеличить потребляемые мощности, а консоль самообслуживания оказалась недоступной.
Мониторинг
Пропишите в соглашении все, что касается безопасности и надежности хранения данных. Речь идет о достоверности и конфиденциальности информации, а также сохранности данных. Определите права доступа к информации, и круг лиц, несущих ответственность в случае её повреждения.
Предоставьте информацию об инструментах восстановления после аварии, а также оговорите процедуру сообщения о сбоях и выходе оборудования строя: формат и временные рамки. Укажите, какие меры для восстановления функционирования систем будут применяться.
Компенсации
Провайдер должен определить спектр компенсаций, которые он выплачивает в случае нарушения показателей доступности и других параметров качества. Ответственность провайдеры должна быть установлена в размере не менее, чем 100% оплаты за отчетный период при длительном простое. Например, 1cloud гарантирует 100% возмещение стоимости услуги при доступности сети меньшей, чем 76,98%.
Расчеты
Многие клиенты сталкиваются с вопросом корректного выполнения расчетов. Чтобы клиент был спокоен и понимал, «что его ждет», то его расчеты не должны расходиться со значениями, предлагаемыми поставщиком. Хорошим вариантом будет использование детальных формул. Также рекомендуем приводить наглядные расчетные примеры. Это поможет ИТ-отделу компании-клиента установить объемы необходимого аппаратного обеспечения и мощностей, а также определиться с ПО для организации.
Важно помнить, что соглашения об уровне обслуживания для облачных услуг отличаются от остальных SLA. Недобросовестные поставщики иной раз предпочитают выстраивать отношения по принципу «одно ко многим», подразумевая использование единого SLA и предлагая его всем заказчикам. Такой подход хорош для поставщиков, но совершенно не годится для клиентов со специфичными задачами.
P.S. Наш дайджест с 25 материалами о безопасности, работе программистов и опыте создания IaaS-провайдера можно почитать тут.
Дополнительные материалы из блога 1cloud:
/ Flickr / Dennis Skley / CC
Все большее число приложений и объем вычислительных задач переходят на IaaS. Поэтому IaaS-провайдеры стараются гарантировать клиентам определенный уровень безопасности и комфорта и подстраиваться под изменяющиеся требования рынка, а также законодательства стран, в которых они предоставляют услуги. Все это приводит к изменениям в SLA.
«Некоторые аспекты в SLA облачных провайдеров на сегодняшний день устарели или, более того, вызывают замешательство. Например, есть поставщики, которые в своих SLA прописывают запрет на распространение информации о сбоях в работе инфраструктуры, — рассказывает специалист в области облачных сервисов Дэвид Линтикум (David Linthicum). — Что совершенно не помогает ни самому провайдеру, ни его клиентам, поскольку сложно назвать такие условия честными».
В попытке стандартизировать и предоставить рекомендации по составлению соглашения об уровне обслуживания Европейская комиссия начала продвижение документа, целью которого является обеспечение большей прозрачности для бизнесов при работе с облачными сервисами и изучении SLA. Инициатива получила название SLALOM и, как отмечает CIF, она позволит «снизить неопределённости» при миграции инфраструктуры в облако.
В новом документе собраны предложения и практики от влиятельных игроков облачного рынка. «Команда составила список терминов из сферы облачных вычислений, которые покрывают все аспекты отношений между провайдером и клиентом», — говорит Оливер Баррето (Oliver Barreto) из Atos.
Сам документ SLALOM вы можете найти по ссылке, а далее мы разберем несколько первоочередных пунктов, на которые следует обратить внимание провайдеру при составлении своего соглашения об уровне обслуживания.
Уровень доступности
В SLA облачного провайдера должны быть определены ключевые метрики, описывающие работоспособность облачного сервиса. Речь идет о доступности сервиса, количестве пользователей, способных получать доступ к сервису одновременно, а также времени, необходимом для обработки транзакций пользователей. Например, IaaS-провайдер может гарантировать доступность приложений 99,5% времени.
Также следует обозначить временные рамки, в которые этот уровень доступности обеспечивается, чтобы у клиентов не возникало вопросов. Если продолжать пример, то провайдер может обеспечивать доступность приложений до 99,5% времени с 8 часов утра до 8 часов вечера в будние дни. Этот параметр имеет свое название — согласованное время работоспособности услуги, или СВР.
Однако отметим, что при выборе провайдера обращать внимание только на «процентовку» не следует, нужно также учитывать, насколько провайдер готов к решению возникающих проблем и трудностей. Например, мы в компании 1cloud предлагаем резервное копирование, выполняющееся раз в сутки, чтобы защитить данные пользователей от утери в случае нештатных ситуаций. Копирование выполняется на удаленный дисковый массив, что делает данные доступными для восстановления даже при недоступности файловой системы сервера (и в случае выполнения пользователем необратимых действий).
Исключения
В SLA необходимо прописать допустимые условия, при которых провайдер не гарантирует указанные доступность и производительность. Поскольку этот раздел освобождает поставщика от выполнения своих обязанностей, список ограничений должен быть строгим и коротким.
Например, ограничение доступности во время проведения плановых технических работ и обновления программного обеспечения, а также в случае возникновения непреодолимой силы, в частности, отказа оборудования третьих лиц. Еще один вариант — отказ программного обеспечения вследствие нарушения клиентом рекомендаций, прописанных в документации к продукту.
Также в SLA следует отметить гарантии доступности интерфейса управления виртуальной инфраструктурой. Это позволит избежать недопонимания и других инцидентов в случае, когда клиенту потребовалось экстренно увеличить потребляемые мощности, а консоль самообслуживания оказалась недоступной.
Мониторинг
Пропишите в соглашении все, что касается безопасности и надежности хранения данных. Речь идет о достоверности и конфиденциальности информации, а также сохранности данных. Определите права доступа к информации, и круг лиц, несущих ответственность в случае её повреждения.
Предоставьте информацию об инструментах восстановления после аварии, а также оговорите процедуру сообщения о сбоях и выходе оборудования строя: формат и временные рамки. Укажите, какие меры для восстановления функционирования систем будут применяться.
Компенсации
Провайдер должен определить спектр компенсаций, которые он выплачивает в случае нарушения показателей доступности и других параметров качества. Ответственность провайдеры должна быть установлена в размере не менее, чем 100% оплаты за отчетный период при длительном простое. Например, 1cloud гарантирует 100% возмещение стоимости услуги при доступности сети меньшей, чем 76,98%.
Расчеты
Многие клиенты сталкиваются с вопросом корректного выполнения расчетов. Чтобы клиент был спокоен и понимал, «что его ждет», то его расчеты не должны расходиться со значениями, предлагаемыми поставщиком. Хорошим вариантом будет использование детальных формул. Также рекомендуем приводить наглядные расчетные примеры. Это поможет ИТ-отделу компании-клиента установить объемы необходимого аппаратного обеспечения и мощностей, а также определиться с ПО для организации.
Важно помнить, что соглашения об уровне обслуживания для облачных услуг отличаются от остальных SLA. Недобросовестные поставщики иной раз предпочитают выстраивать отношения по принципу «одно ко многим», подразумевая использование единого SLA и предлагая его всем заказчикам. Такой подход хорош для поставщиков, но совершенно не годится для клиентов со специфичными задачами.
P.S. Наш дайджест с 25 материалами о безопасности, работе программистов и опыте создания IaaS-провайдера можно почитать тут.
Дополнительные материалы из блога 1cloud:
- Как мы автоматизировали работу с DNS-записями в хостинг-панели
- Мифы об облачных технологиях. Часть 1: техподдержка и управление
- Мифы об облачных технологиях. Часть 2: российские хостеры и защита данных
- Мифы об облачных технологиях. Часть 3: Говорим о железе
- Немного о VPN: Краткий обзор программных реализаций
