Редакция CNews готова принять пресс-релизы компаний на адрес news@cnews.ru.
Приглашаем вас делиться комментариями о материалах CNews на наших страницах платформ Facebook, Telegram и Twitter.
*Текст подготовлен по материалам Computerworld
Каждый поставщик, предлагающий IaaS, SaaS и прочие услуги, заявляет о гарантиях доступности облачных ресурсов и сервисов, что подтверждается соглашением об уровне обслуживания, или SLA. Заключая договор с поставщиком, клиенту стоит уделить внимание деталям SLA, поскольку в мелочах обычно скрываются важные нюансы. О них и поговорим в этой статье.
Соглашения об уровне обслуживания для облачных услуг отличаются от остальных SLA. При этом облачные провайдеры не горят желанием вносить изменения или корректировки. Недобросовестные поставщики и вовсе предпочитают выстраивать отношения по принципу «одно ко многим», подразумевая использование единого SLA, применимого ко многим заказчикам. Такой подход хорош для поставщиков, но вовсе не подходит клиентам со специфичными задачами.
SLA некоторых облачных поставщиков сравнимы с бесполезными бюрократическими бумажками. А все потому, что в некоторых случаях они становятся причиной сбоев в работе критичных для клиента сервисов. Клиенту, возможно, не удастся согласовать каждое изменение в SLA, но стремиться к детализации и внимательно читать соглашение стоит, ведь каждый раздел SLA весьма важен. Для оценки полноты и «прочности» облачных SLA предлагаем рассмотреть семь значимых нюансов.
В этом пункте SLA определяется уровень доступности сервиса, оказываемого поставщиком услуг, где содержится ответ на вопрос «Что по части доступности получает клиент от провайдера в рамках выбранной услуги?». Ответ напрямую зависит от потребностей и целей, отраженных в клиентском договоре. К примеру, SaaS-провайдер может гарантировать доступность приложений 99,5 % времени.
Этот пункт определяет временные рамки, связанные с уровнем доступности сервиса и отвечает на вопрос «В какое время обеспечивается приемлемая доступность услуги?». Продолжим начатый пример: провайдер обеспечивает доступность приложений до 99,5 % времени согласно заданному интервалу: с 8:00 до 20:00 с понедельника по пятницу (этот параметр еще называют «согласованное время работоспособности услуги», или СВР).
В этом разделе SLA приводятся условия, при которых поставщик не гарантирует прописанную в SLA доступность или производительность. Поскольку этот раздел освобождает поставщика от выполнения прописанных обязанностей, список здесь должен быть явным и ограниченным. Так, SaaS-провайдер может потребовать послаблений в вопросе доступности или производительности в случае отказа оборудования, находящегося под контролем третьих лиц (например, сетевого оборудования интернет-провайдеров) или когда клиент использует приложения ненадлежащим образом, нарушая требования, приведенные в документации по продукту.
Для IaaS-сервисов распространенной проблемой является явное или неявное отсутствие в SLA гарантий доступности интерфейса управления виртуальной инфраструктурой. В этом случае при необходимости, например, экстренно увеличить размер потребляемых ресурсов вы можете столкнуться с невозможностью сделать это самостоятельно по причине неработоспособности консоли самообслуживания. Задержка в такой ситуации может привести к инциденту.
Этот раздел SLA отвечает на вопрос «Откуда и как поступает информация, которая используется для оценки соответствия провайдера согласованному уровню сервиса?». Часто клиент в этом вопросе полагается на поставщика облачных услуг (предоставление отчета «по запросу»). В идеале такая информация должна быть доступна клиенту в любой момент через интерфейс самообслуживания.
Это период, в течение которого клиент оценивает соответствие поставщика заявленному SLA. Данный раздел приводит ответ на вопрос «Как часто клиент проверяет соблюдение поставщиком приемлемого уровня доступности и производительности?» и дает представление о сроках, связанных с SLA.
Особенно важный момент — это период, за который рассчитывается доступность, оговоренная в SLA. Чем он меньше, тем менее продолжительный единовременный простой сможет позволить себе облачный провайдер без нарушения SLA. Если для вас критично не только общее время простоя, но и максимальная продолжительность единичного простоя, то в этом случае период расчета показателя доступности должен быть не больше одного месяца.
Многие клиенты сталкиваются с вопросом корректного выполнения расчетов. Чем больше в этом пункте определенности, тем лучше. Если расчеты клиента разнятся с расчетами поставщика, это вызывает беспокойство. Поэтому здесь помогут детали и расчетные формулы. Рекомендуем приводить примеры и вести разговор в цифрах.
И, наконец, клиенту стоит знать ответ на вопрос «А что, если?..». Здесь следует обратить внимание на размер ответственности облачного провайдера в случае несоблюдения SLA. Такая ответственность должна быть оговорена в размере не менее 100 % оплаты за отчетный период при значительном для клиента простое.
Без SLA облачный аутсорсинг превратился бы в настоящую неразбериху и «тушение пожара на ощупь». У хостинг-провайдера просто не было бы цели, к достижению которой он должен стремиться, чтобы удовлетворять, а возможно, и превосходить ожидания клиентов в отношении качества услуг. А без знания нюансов облачных SLA сложно оценивать риски, связанные с оказанием облачных услуг. Заключая договор с поставщиком, следует внимательно прочесть соглашение, поскольку оно дает понимание, какие обязательства облачный поставщик несет перед клиентом.
Редакция CNews готова принять пресс-релизы компаний на адрес news@cnews.ru.
Приглашаем вас делиться комментариями о материалах CNews на наших страницах платформ Facebook, Telegram и Twitter.