Поставщики облачных услуг предоставляют различные гарантии, среди которых есть доступность сервисов и ресурсов, которые указываются в соглашении об уровне обслуживания. Чаще всего это соглашение обозначают аббревиатурой — 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: Краткий обзор программных реализаций
Поделиться с друзьями
Комментарии (9)
muon
27.12.2016 07:32Мне вот что интересно:
… за исключением периодов времени, вызванных:
То есть если в ДЦ нет сети, то это сугубо проблемы пользователя и провайдера? С таким соглашением я могу на локалхосте под кроватью пять девяток гарантировать. Хочется верить, что вы на добросовестности прилагаете максимальные усилия для повышения доступности, и просто на всякий случай решили написать бумажку, по которой пользователь от вас может требовать нихрена.
<...>
- Неработоспособностью каналов связи и оборудования, находящихся вне зоны ответственности/контроля Компании ООО «ИТ-ГРАД 1 Клауд».
- Приложениями или компонентами Клиента не подконтрольными и не управляемыми Компанией ООО «ИТ-ГРАД 1 Клауд», которые привели к невозможности оказать Услугу.
— Компьютер, который вы мне продали с пожизненной гарантией, сдох!
— Ну раз сдох, то пожизненная гарантия кончилась ?\_(?)_/?
1cloud
27.12.2016 11:09+1С таким соглашением я могу на локалхосте под кроватью пять девяток гарантировать
Про это мы очень подробно рассказывали вот тут: 1, 2, 3.
Если говорить серьезно и немного отойти от шуток, мы с радостью рассмотрим ваш вариант редакции этого пункта соглашения. Тут нужно еще раз просто прочитать SLA и подумать о том, что действительно контролирует провайдер и где граница его полномочий.vikarti
27.12.2016 12:43-1А почему это проблемы клиента?
Да — вы не контролируете напрямую падение аплинков — но можете взять больше независимых аплинков. Вы не контролируете что электросеть отключится — но на то и стандарт что два независимых ввода + генераторы, если мало.
Вспоминается SLA той же GoGrid — https://www.datapipe.com/gogrid/legal/sla/ — прямо прописано что в SLA входит, а входит туда и сеть, в том числе и внешняя, и более менее понятно что меряется. И 10 000% компенсации. правда service credits. Как то же они это гарантируют? Либо таких находят возможность договора с провайдерами подписать нужны либо таки страховка есть на случай проблем.
В вашем SLA — не понятно даже что например входит в доступность сети.1cloud
27.12.2016 13:02+1А почему это проблемы клиента?
Об этом мы и не говорим :) На самом деле наше оборудование размещается в дата-центре SDN в Санкт-Петербурге, одном из крупнейших и современных ЦОД в стране, и дата-центре Dataspace в Москве, услуги которого доступны в безаварийном режиме уже более трёх лет.
В вашем SLA — не понятно даже что например входит в доступность сети
В нашем SLA есть специальный раздел «определения», где как есть и про доступность, и про формулу расчета.vikarti
27.12.2016 15:02Посмотрите как это у gogrid написано, про ту же сеть например.
У вас — я не вижу вообще как та же недоступность сети считается (и даже не понятно какой именно сети — внутренней или доступ извне?).
muon
27.12.2016 14:53Я бы воспользовался вашим советом: список ограничений должен быть строгим и коротким. Три провайдера даже по 85% дают 0,34% простоев. Ваша статистика есть только у вас, но вряд ли вы найдёте провайдера хуже 85%. Стоят ли эти доли процента отдельного исключения в SLA?
И не забывайте, что у админов есть средства объективного контроля. Если nagios стабильно показывает 99,5%, а вы стабильно отчитываетесь о «нормированных» 99,8%, то это не добавит прозрачности и доверия.
Тут нужно еще раз просто прочитать SLA
Только ещё раз прочитав SLA, я обратил внимание, что шкала компенсации сильно нелинейна. В первый раз я посмотрел только на последнюю строку, ужаснулся и закрыл страницу, не вникая. 76% — это не из мира высоких технологий. Зачем они вам? Если у вас будет такой даунтайм, то вы понесёте настолько огромные репутационные и, надо думать, материальные потери (сломалось что-то реально большое), что половина абонентки вас не спасёт, перед смертью не надышишься. Просто уберите, или хотя бы поднимите, чтобы первой цифрой была девятка.
reji
Откуда взята цифра в 76, 98% для включения «компенсации»?
Правильно ли я понимаю, что в пересчете на дни, вы ~85 суток в году вы можете лежать без какой-либо компенсации?
muon
1cloud, вы что, не прочитали статью «Как правильно постить на хабр»? Там есть про важность отвечания на первые комментарии к посту.
1cloud
Спасибо за ценный совет :) На самом деле тут все прозрачно, в SLA необходимо учитывать целый спектр возможных ситуаций, в том числе и распределение размера компенсации в зависимости от показателей доступности. Да, все это есть в нашем примере.