Тонкости SLA IaaS: за что можно требовать компенсацию с провайдера
Оформляя услуги облачных провайдеров, нельзя пренебрегать составлением SLA (Service Level Agreement) — договора об уровне сервиса. В основном соглашении, как правило, описывают количество машинных ресурсов и типы заказываемых опций, но не затрагивают вопрос об их качестве. Этот пункт оговаривается именно в SLA.
В обиходе под SLA зачастую понимают неработоспособность сервера, то есть его полную остановку. На самом деле возможностей затребовать компенсацию с провайдера гораздо больше: даже если какой-то один параметр долгое время вне допустимых значений — это уже повод открыть соответствующий тикет.
Перейти к рейтингу SLA облачных провайдеров
Компенсации за простой
В самую первую очередь при составлении договора заказчик обязан уточнить, какую именно компенсацию готов выплатить IaaS за простой облачной инфраструктуры. На самом деле это один из первых вопросов, возникающих у клиентов. Людей интересует, готов ли провайдер понести ответственность за финансовые потери абонентов услуги.
Именно этому вопросу был посвящен первый рейтинг SLA от Market.CNews, опубликованный в июне 2020 г.
Если собрать несколько договоров разных поставщиков и проанализировать их, то можно увидеть, что размер компенсации за сбои работы сервера и, как следствие, простой инфраструктуры заказчика, никогда не превышает стоимость купленных опций. В более чем половине SLA-договоров указывается сумма за час простоя меньше, чем заказчик выплатит. Другими словами, с клиента взимается плата даже во время простоя ЦОД.
Большинство рейтингов поставщиков облачных услуг имеет выделенный пункт — «максимальная компенсация». В том случае, если она ниже 100%, то платить придется даже за ресурсы крайне низкого качества.
Большую роль играет метод определения времени простоя. Тут следует учесть, что многие провайдеры хитрят с определением периода бездействия. Конечно, если внедрена панель мониторинга, то неисправность будет выявлена сразу после ее возникновения. Другое дело, когда проблему обнаруживают по факту обращения клиента спустя некоторое время.
Даже если у поставщика предусмотрена аналитическая панель, не всегда за простой будут возвращены деньги. Система может проверять доступность каждые 5 минут. Тогда короткие периодические аварии останутся неучтенными.
Общий алгоритм действий примерно следующий:
- Ознакомиться и усвоить порядок выплат компенсаций на простой IaaS.
- Незамедлительно открыть тикет, если вы заметили неработоспособность ваших ресурсов, предположительно, по вине провайдера.
- Проверить работоспособность BaaS, DRaaS или иной защитной системы.
Компенсации за снижение характеристик облака
Если поставщик гарантирует 100% компенсации в случае простоя, то далеко не факт, что выплата будет полноразмерной. Дело в том, что некоторые инфраструктуры могут терять под 90% производительности, даже если из 10 арендованных серверов из строя вышел только один. В таком случае лучшее, на что остается надеяться, — компенсация за снижение характеристики облака.
Когда в договоре SLA есть пункт о том, что компенсация начисляется, исходя из общего процента работоспособности серверов, то заказчик вряд ли получит 100% потраченных денег обратно. Предположим, что из 10 арендованных машин были повреждены только 2. Тогда в ходе проверки будет определено, что снижение характеристик составило 20%. Соответственно, заказчику вернут некоторую долю, исходя не из 100%, а именно из 20%. При этом провайдер не будет нести ответственность за то, что от этих 2-х серверов зависело функционирование всего проекта.
Выше приведен принцип вычисления суммы на основании уровня предоставленных услуг, зависимость в нем прямо пропорциональна, но бывают и более сложные формулы расчета компенсации. Некоторые провайдеры обеспечивают частичный возврат средств при незначительных потерях и 100% выплаты, если общий процент доступности падает ниже определенного порога — например, 50%.
Алгоритм действий здесь примерно следующий:
- Оценить и запомнить примерную среднюю скорость работы сервисов.
- Если наблюдается их замедление без видимых причин с вашей стороны, открыть соответствующий тикет.
- Для систем высокой важности задействовать резервные ресурсы (замедление бизнеса компании, как правило, обходится в десятки и сотни раз дороже, нежели возможные компенсации со стороны провайдера).
- По факту восстановления скорости работы сервисов определить величину компенсации, причины произошедшего и продумать план действий в подобных ситуациях в будущем.
Компенсации за отсутствие доступа к хранилищу
Различные варианты расчета — еще один способ IaaS-провайдеров обойти выплаты по договору SLA. Данный показатель рассчитывается как процент работоспособности серверов в течение месяца или года. В некоторых случаях учитывают не потоковые значения, а усредненные (1 месяц — 30 дней).
Допустим, сервер не работал в течение 10 часов на протяжении месяца (720 часов). Доступность хранилища можно рассчитать по следующей формуле: ((720-10)/720) * 100=98,611%.
Иногда провайдеры делают оговорку, что общий период рассчитывается с вычетом времени профилактических работ, которые, например, могут занять до 5 часов. Тогда формула будет иметь такой вид: ((715-10)/715) * 100=98,601%. В этом варианте недоступным хранилище оставалось немного дольше, поэтому и компенсация будет выше.
Как потребовать компенсацию
Многие современные IaaS все-таки делают ставку на прозрачность своих услуг. Сотрудничество с подобными может идти по нескольким направлениям. Чаще всего фирма предоставляет автоматический ежемесячный отчет. В нем будут продемонстрированы уровни доступности серверов за указанный период. Второй вариант подразумевает самообслуживание клиента при помощи мониторинговых панелей. Специалисты ИТ могут отслеживать загруженность процессора или других ресурсных узлов арендованной машины и при необходимости делать акцент в службе поддержки о проблемах.
Любой облачный сервис ведет собственную статистику работоспособности. На основе отчетных данных можно вычислить снижение доступности и время простоя. Все документы хранятся у провайдера и должны предоставляться заказчикам по требованию или автоматически по истечении определенного периода. Благодаря этому покупатель услуги сможет оценить качество опции и сравнить данные с собственной собранной информацией о работоспособности ЦОД.
Что еще важно в SLA IaaS? Обзор Market.CNews
Ответственные именитые провайдеры выплачивают компенсацию без участия клиента. После самостоятельной оценки работоспособности средства возвращаются на баланс или плюсуются к оплаченному периоду эксплуатации (процедуру также необходимо оговаривать в договоре SLA). Естественно, если неисправность ЦОД была выявлена заказчиком, а поставщик ее не компенсировал, необходимо заявить об этом в службу поддержки. После будет проведена проверка на основании накопленных отчетов.
Как защититься от аварий и потери данных
Компенсация провайдера практически никогда не позволяет полностью нивелировать финансовые потери от простоя системы. Единственный правильный ход — обеспечение своей инфраструктуре стрессоустойчивости посредством соответствующих сервисов.
DRaaS — возможность восстановить работоспособность своего проекта за считанные минуты. Поставщики данной опции обеспечивают своих клиентов резервными мощностями, которые могут запускаться в случае возникновения проблем с основными ЦОД. При этом подразумевается полное копирование всей структуры, поэтому перезапуск можно произвести с посторонних компьютеров. Так, даже физическое повреждение офиса не повлечет долгих простоев, достаточно пересадить специалистов за любые другие ПК.
Узнать актуальные цены на DRaaS от нескольких поставщиков
BaaS — еще одно смежное решение, позволяющее сохранить данные в случае утраты работоспособности основного хранилища. Периодическое резервное копирование на аппараты с реальной доступностью, близкой к 100% в год, позволит быстро восстановить базы данных в случае неполадок основного сервера.
Описанные услуги резервного копирования и послеаварийного восстановления — дополнительные опции, предоставляемые провайдером. Естественно, желающие обзавестись подобной страховкой должны обговорить процедуру ее получения в отдельном договоре.
Еще один вариант защиты от финансовых потерь в случае простоя облачных сервисов — страховой полис. Такой подход при вопросах IaaS на данный момент не распространен. Однако некоторые ведущие страховые компании уже заявили о развитии в этом направлении.