Облачные SLA: ясны ли условия сделки?

Вероятность серьезных сбоев при работе с облачными вычислениями заставляет задуматься над простым, но важным вопросом: помогут ли жесткие SLA уберечь вашу организацию от проблем?

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

Многие поставщики облачных решений не заключают соглашение о качестве сервиса (Service Level Agreement, SLA). Большинство пойдет на это, если вы потребуете. Другие вступят в переговоры о SLA только в крайнем случае.

Многие поставщики облачных решений вообще не заключают соглашение о качестве сервиса. Большинство пойдет на это, если вы потребуете. Другие вступят в переговоры о SLA только в крайнем случае. И только не слишком озабоченные своей репутацией провайдеры готовы перекроить собственные SLA и согласиться на любые условия клиента. Как правило, если удается внести изменения в SLA, то они носят финансовый характер (например, более длительное время бесплатного предоставления услуг в качестве компенсации за нарушения SLA), но не операционный. Объясняя, почему предлагаемые изменения не могут быть приняты, поставщик будет ссылаться на некие административные ограничения, упоминать репутационные риски, которые и без того заставляют его обеспечивать высокое качество сервиса.

Облачные SLA: опасайтесь бесконечного списка исключений

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

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

Для некоторых видов облачных сервисов, особенно “инфраструктуры как сервис” (IaaS), такое резервирование может оказаться привлекательным для заказчиков, поскольку дополнительные затраты могут быть оправданы практическими нуждами. Но если резервный ЦОД находится в другом регионе, остается открытым вопрос, как ваш поставщик гарантирует моментальное и незаметное для пользователей переключение на резервный ЦОД в случае сбоя в основном ЦОДе.

Для других облачных сервисов, таких как “ПО как сервис” (SaaS), подобную избыточность обеспечить труднее, поскольку возникает необходимость в полной репликации приложения (с учетом его кастомизации) и поддерживающей его инфраструктуры.

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

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

Конечно, все определяется конкретными обстоятельствами. Например, если внутренняя система электронной почты недоступна в течение определенного времени, это неприятно, но вряд ли напрямую скажется на прибыли компании. С другой стороны, если упадет веб-сайт электронной коммерции, через который проходит большая часть ваших продаж, удар по прибыли и по репутации будет незамедлительным и серьезным. В этом случае вы, безусловно, задумаетесь о том, чтобы разместить веб-сайт у себя, особенно если у вас уже есть проработанный план его восстановления и вы располагаете значительными ресурсами.

Если вы делаете ставку на облачные сервисы внешних поставщиков, наличие жестких SLA дает неоспоримые преимущества. Прежде всего SLA может послужить стимулом для поставщика к тому, чтобы выполнять взятые на себя обязательства.

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

Обычно максимальный размер компенсации в облачных SLA эквивалентен 25% от регулярных платежей. В некоторых SLA оговаривается фиксированный тариф за несоблюдение конкретного параметра соглашения, например доступности сервиса. Другие определяют компенсацию в некоторых единицах (эквивалентных, скажем, 1/30 от ставки того месяца, когда соглашение не было соблюдено) и начисляют такие единицы за каждую минуту простоя сверх оговоренного в соглашении периода. Преимущество такого подхода к определению компенсации за нарушения SLA заключается в том, что вашей компании для получения компенсации не нужно выяснять, какой именно ущерб она понесла в результате перерыва в предоставлении сервиса, и подтверждать это доказательствами.

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

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

Вы должны изучить все эти особенности SLA для облачных услуг. SLA — это не замена вашим системам резервного копирования и оно не исключает необходимость в подготовке плана восстановления данных. На самом деле, некоторые облачные SLA, наоборот, требуют наличия у заказчика системы резервного копирования, дабы поставщик мог указать в контракте, что не несет ответственности за сервис.