Поделиться
Как провайдеры уходят от крупных компенсаций по SLA
Провайдеры облачной инфраструктуры IaaS часто заявляют о SLA на уровне 99,9% и выше. Заветным «девяткам» суждено подчеркивать высокое качество оказываемых услуг, а наличие «восьмерок» или «семерок» с маркетинговой точки зрения недопустимо. Однако на практике любые «девятки» могут превратиться во вполне обоснованные провайдером «нули». В рамках данной статьи Юрий Хомутский, директор проекта Market.CNews, рассказывает о тонкостях SLA-соглашений.
Ответственность провайдеров
Самый первый и самый главный вопрос, который должен возникать в ходе рассмотрения того или иного SLA, — какую вообще ответственность несет провайдер в случае низкого качества оказываемых услуг. Как показывает практика, этот вопрос действительно возникает у многих клиентов. В частности, с ним регулярно приходится сталкиваться на мероприятиях агентства маркетинговых коммуникаций CNews Conferences: готов ли провайдер разделить бизнес-потери клиента в случае краха облачной системы?
Анализ типовых соглашений большинства компаний показывает, что ответственность провайдера строго ограничивается стоимостью услуг, купленных у него, а иногда даже меньшей суммой. Иными словами, получая облачный сервис с катастрофически низким уровнем доступности, например, 5-10% (простой 90-95%), с клиента все равно могут списываться средства.
В рейтинге IaaS-провайдеров по SLA для этого предусмотрен показатель «Максимальная компенсация». И если его значение ниже 100%, то даже за услуги очень низкого качества клиенту придется платить.
На самом деле ограничение ответственности провайдера суммой выкупленных у него услуг вполне логично. Единственный способ повысить возможные выплаты — оформить страхование серверов, однако на данный момент этот рынок развит достаточно слабо.
100% — от какой суммы?
Но даже максимальная компенсация в 100% может не позволить получить от провайдера значительных средств. Дело в том, что IaaS представляет собой аренду множества серверных машин, а авария может произойти лишь на некоторых из них. Во многих SLA прямо прописано, что компенсация начисляется, исходя из стоимости неработоспособных серверов, а не из стоимости полного пакета услуг. Еще одна оговорка — исходя из стоимости «голой» инфраструктуры без учета дополнительных опций.
Предположим, клиент арендует 10 серверных машин, а фактический простой за месяц составил 5% времени. Предположим также, что, согласно SLA, компенсация за такой простой должна составить 100% оплаченных услуг, но есть пункт про учет только неработоспособных серверов.
В ходе проверки выясняется, что 8 серверных машин работали в штатном режиме, а авария случилась на 2 серверах. И здесь не важно, насколько критичными для функционирования сервисов клиента оказались именно эти 2 сервера. Быть может, сервисы клиента были полностью неработоспособны 5% времени в этом месяце. Но компенсация составит лишь 100% от стоимости конкретно этих двух серверов. То есть, около 20% стоимости аренды IaaS, если принять, что все 10 серверов имеют одинаковую конфигурацию.
Относительно чего считать доступность
Некоторые разногласия в расчет фактической доступности может внести формула ее расчета. В маркетинговых примерах зачастую расчет ведется как отношение времени доступности за месяц или год к длительности этого месяца или года. В SLA может быть прописано отношение доступности не к длительности месяца или года, а к максимально возможному периоду доступности, а этот период суть длительность месяца или года за вычетом профилактических работ и штатного простоя.
Впрочем, как показывает математика, такое уточнение на стороне клиента. Например, в июне 30 дней, или 720 часов. Допустим, длительность профилактических работ составила 4 часа, а длительность простоя — 2 часа. Тогда доступность относительно длительности месяца составит (720-2)/720=99,7222%.
Максимально возможный период доступности при этом будет равен 720-4=716 часов, а доступность относительно этого периода составит (716-2)/716 = 99,7206%. Эта цифра чуть ниже полученной выше, и этого может быть достаточно, чтобы перейти в зону более высоких компенсаций.
Профилактика – главная дыра SLA
Важный пункт анализа SLA — учет профилактики — как часто она может проводиться и как много времени занимать? Дело в том, что во время профилактики сервисы клиента могут быть полностью недоступны, но эта недоступность не подлежит компенсации со стороны провайдера, и в расчете SLA не участвует. Единственное значимое условие — о профилактике провайдер должен сообщить заранее (за 1-7 дней до начала профилактических работ, судя по проанализированным нами SLA).
Иными словами, разные операторы могут заявлять доступность 99,95% (простой 36 минут в месяц), но у одного из них на профилактику будет заложено 2 часа в месяц, а у другого — 4. Третий провайдер может вообще не регламентировать длительность профилактики — хоть весь месяц, главное, чтобы он об этом заранее предупредил.
Формально доступность сервисов трех таких провайдеров будет равна, а на практике максимальный простой составит 2 часа 36 минут у первого провайдера, 4 часа 36 минут у второго и 720 часов у третьего. Минимальный обоснованный уровень доступности составит, соответственно, 99,64%, 99,36% и 0%.
Вообще, профилактика — это главная дыра SLA-соглашений. Как видно из примера выше, аварийный (компенсируемый) простой сервисов может составлять 36 минут в месяц, в то время как штатный (профилактический, некомпенсируемый) простой может достигать 2 и более часов, что в 4 и более раза дольше аварийного.
Точность определения времени простоя
Еще один важный пункт — как провайдер определяет длительность простоя. И тут следует сфокусироваться на нескольких пунктах.
Во-первых, какой период считается простоем. Некоторые поставщики услуг внедрили панель мониторинга, которая автоматически фиксирует проблемы. Другое дело — фиксация проблем по факту открытия соответствующего тикета в службе поддержки. Если вовремя его не открыть, то и на компенсации рассчитывать не стоит.
Во-вторых, до каких величин округляется время простоя. Например, панель мониторинга проверяет доступность сервисов, в среднем, каждые 3-5 минут. Значит, большинство краткосрочных проблем системой не будет замечено, даже если они имели место быть.
Граница ответственности SLA
В рамках IaaS провайдер обеспечивает виртуальный сервер с заданными характеристиками и канал связи до узла связи. Надежность именно этих составляющих и регламентируется SLA. А панель управления IaaS, например, может иметь уже более низкий уровень доступности.
Однако ИТ-инфраструктура компании-клиента состоит не только из IaaS как такового. В нее входит софт, работающий в облаках, а также внешние каналы связи, софт и оборудование на стороне клиента и другие звенья. Каждое такое звено характеризуется собственным уровнем надежности, и, конечно, не вписывается в SLA IaaS-провайдера.
Более того, надежность ИТ-инфраструктуры компании в целом определяется как произведение уровней доступности каждого ее элемента. Так, уровень надежности инфраструктуры из 4 звеньев с доступностью каждого из них 99,9% в итоге составит всего 99,6%.
И еще. А что, собственно, такое недоступность?
Наконец, обратим внимание на тот факт, что, собственно, провайдер понимает под недоступностью сервисов. Тут привлекает внимание промежуточное состояние, когда сервер вроде работает, но его производительность ниже заявленной.
На этот случай ряд провайдеров предусматривает оговорки в своих SLA-соглашениях. Так, например, для различных компонентов IaaS может быть прописано штатное снижение производительности, допустим, на 20%. Если реальная тактовая частота того же виртуального процессора упала ниже отметки в 80% от заявленной величины, то пора открывать претензионный тикет.
Однако по другим SLA недоступность может наступать только при полном отключении сервера — самый худший вариант. В этом случае сервисы клиента, зависящие от облачной инфраструктуры, могут «подвисать, но фурычить». И в такие моменты о компенсациях не может быть и речи.
Что в итоге
В SLA можно копаться глубже и дольше, и постоянно находить все новые и новые подводные камни. В конечном итоге, помимо защиты клиента по части качества получаемых им услуг, соглашение SLA также призвано защитить и провайдера от слишком высоких компенсаций, а иногда и от потребительского терроризма.
Таким образом, если сервис клиента требует действительно высокой надежности, то SLA провайдера его не спасет, и защиту следует искать в диверсификации облачных услуг или построении сети собственных ЦОД. А ответ на вопрос, стоит ли детально анализировать SLA на предмет возможных компенсаций, зависит от доли затрат на облака в бизнесе компании.
Если эта доля высока, то каждая компенсация будет существенной экономией бюджета, и SLA должно рассматриваться самым пристальным образом. Если же доля низка, то тратить существенные временные и трудовые ресурсы на получение компенсаций будет невыгодно.
В любом случае, следует иметь в виду: чем выгоднее SLA для клиента, тем более надежными считает свои услуги поставщик. В этом плане SLA — основной документ, который юридически подтверждает уверенность провайдера в своей собственной инфраструктуре.
Короткая ссылка
