Что такое SLA соглашение и зачем оно нужно?

SLA (Service Level Agreement) — соглашение об уровне обслуживания. Документ оговаривает измеримое качество предоставляемых услуг и качество перестает быть просто «высоким», а сервис «хорошим». Благодаря SLA уровень обслуживания можно измерить в процентах, баллах или долях, получив четкое понимание: что и в каком объеме будет выполнено в определенные временные рамки. Вот почему Service Level Agreement считается таким же важным документом, как договор, и заслуживает отдельной статьи.

Что такое SLA соглашение

Набор услуг

Основа соглашения SLA — перечень услуг. Он определяет, какие услуги оказывает ЦОД и в каком формате. Если это техподдержка, то дается определение, что входит в техническую поддержку оборудования, кто и как ее выполняет. Если доставка — подробно прописывается состав услуги и ее конечный результат. Чем более детально оговаривается формат сервиса, тем меньше спорных моментов и поводов к конфликтам. Сравните, какое определение информативней — «Доставка сервера» или «Доставка сервера, то есть транспортировка сервера от склада до склада в жесткой упаковке без подъема на этаж». Со вторым вариантом сразу понятно, на что рассчитывать.

Метрики качества

Метрики услуг универсальны, измеримы и численно отражают уровень сервиса. В дата-центрах такими метриками являются:

  1. Доступность сервиса. Определяется в процентах или часах/минутах/секундах в год. У нас в GreenBushDC доступность сервиса измеряется в процентах и составляет 99,982% в год.

  2. Время реакции на инцидент. Это время от получения сообщения об инциденте, например, отказе оборудования, до начала работ над проблемой. Инциденты, в свою очередь, делятся по уровню критичности на несколько категорий. Очевидно, что время реакции на сбои с низким уровнем критичности больше, чем время реакции на инциденты с высоким приоритетом.

Зачем вообще нужны эти метрики? Чтобы четко определить ожидания по качеству. В классических договорах это, как правило, не предусмотрено. Там вы можете увидеть размытое «Исполнитель обязан устранить неисправность после обращения заказчика». В соглашении SLA этот же пункт предельно конкретен: «Исполнитель обязан фактически приступить к устранению неисправности в рабочее время (9-18 часов) в течение 30 минут с момента регистрации заявки; в нерабочее время (19-08 часов) в течение 60 минут с момента регистрации заявки в журнале службы технической поддержки».

Что должно быть в хорошем SLA дата-центра

Пример гипотетический, но он полностью отражает разницу между договором и Service Level Agreement.

Условия оплаты и компенсации

Помимо определения услуг и метрик в SLA фиксируется порядок оплаты, момент ее списания и условия возврата средств за неиспользованную услугу. Также определяются штрафы и санкции за несоблюдение нормативов и нарушение условий. Размер штрафа рассчитывается как процент от стоимости договора.

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

SLA как фактор выбора дата-центра

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

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

Читать еще
Внутренний аудит информационной безопасности 18.06.2021
В копилку службы ИБ: методы, подходы и чек-листы для внутреннего аудита информационной безопасности.
Читать подробнее
Как разобраться с логированием: гайд для начинающих 25.06.2021
Зачем оно нужно, это логирование и как упростить процесс сбора, анализа и хранения логов.
Читать подробнее
Когда нужен внешний аудит информационной безопасности 09.07.2021
Про объекты, результаты и периодичность внешнего аудита информационной безопасности для операторов ПДн, объектов критической информационной инфраструктуры, субъектов НПС и других компаний.
Читать подробнее
Что такое тикет-система и как она применяется в ЦОД 16.07.2021
Чем тикет-система лучше телефонной поддержки и как ЦОД использует тикеты для улучшения работы.
Читать подробнее
Аварии в ЦОД и как их избежать 23.07.2021
Про экстраординарные форс-мажоры ЦОД на примере аварии дата-центра «Курчатовский» и меры защиты от основных глобальных рисков
Читать подробнее
Введение нового порядка госаккредитации ИТ-компаний в РФ 30.07.2021
Как изменится госаккредитация ИТ-компаний с 1 августа 2021 года? Делаем обзор изменений и нововведений.
Читать подробнее
Оставить заявку
После отправки заявки ожидайте звонка нашего менеджера.
* Поля, обязательные к заполнению.
Спасибо!
Данные вашего заказа будут переданы в отдел продаж.
После чего ожидайте звонка вашего личного менеджера.
контакты компании
Адрес компании
124460, Москва, Зеленоград, ул. Конструктора Лукина, д. 14А, офис 501
Поддержка 24/7
8 495 784 60 80
ПОЧТИ готово!
Спасибо, данные вашего заказа будут переданы в отдел продаж.
После чего ожидайте звонка вашего личного менеджера.
* Поля, обязательные к заполнению.