Спецпроекты

Безопасность Бизнес Телеком Интернет Цифровизация ИТ в банках ИТ в госсекторе Ритейл Маркет

Тонкости SLA IaaS: за что можно требовать компенсацию с провайдера

Оформляя услуги облачных провайдеров, нельзя пренебрегать составлением SLA (Service Level Agreement) — договора об уровне сервиса. В основном соглашении, как правило, описывают количество машинных ресурсов и типы заказываемых опций, но не затрагивают вопрос об их качестве. Этот пункт оговаривается именно в SLA.

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

Перейти к рейтингу SLA облачных провайдеров

Компенсации за простой

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

Оформляя услуги облачных провайдеров, нельзя пренебрегать составлением SLA — договора об уровне сервиса

Именно этому вопросу был посвящен первый рейтинг SLA от Market.CNews, опубликованный в июне 2020 г.

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

Большинство рейтингов поставщиков облачных услуг имеет выделенный пункт — «максимальная компенсация». В том случае, если она ниже 100%, то платить придется даже за ресурсы крайне низкого качества.

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

Даже если у поставщика предусмотрена аналитическая панель, не всегда за простой будут возвращены деньги. Система может проверять доступность каждые 5 минут. Тогда короткие периодические аварии останутся неучтенными.

Общий алгоритм действий примерно следующий:

  1. Ознакомиться и усвоить порядок выплат компенсаций на простой IaaS.
  2. Незамедлительно открыть тикет, если вы заметили неработоспособность ваших ресурсов, предположительно, по вине провайдера.
  3. Проверить работоспособность 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 на данный момент не распространен. Однако некоторые ведущие страховые компании уже заявили о развитии в этом направлении.

Короткая ссылка