SLA (Service Level Agreement) — соглашение об уровне обслуживания. Документ оговаривает измеримое качество предоставляемых услуг и качество перестает быть просто «высоким», а сервис «хорошим». Благодаря SLA уровень обслуживания можно измерить в процентах, баллах или долях, получив четкое понимание: что и в каком объеме будет выполнено в определенные временные рамки. Вот почему Service Level Agreement считается таким же важным документом, как договор, и заслуживает отдельной статьи.
Набор услуг
Основа соглашения SLA — перечень услуг. Он определяет, какие услуги оказывает ЦОД и в каком формате. Если это техподдержка, то дается определение, что входит в техническую поддержку оборудования, кто и как ее выполняет. Если доставка — подробно прописывается состав услуги и ее конечный результат. Чем более детально оговаривается формат сервиса, тем меньше спорных моментов и поводов к конфликтам. Сравните, какое определение информативней — «Доставка сервера» или «Доставка сервера, то есть транспортировка сервера от склада до склада в жесткой упаковке без подъема на этаж». Со вторым вариантом сразу понятно, на что рассчитывать.
Метрики качества
Метрики услуг универсальны, измеримы и численно отражают уровень сервиса. В дата-центрах такими метриками являются:
-
Доступность сервиса. Определяется в процентах или часах/минутах/секундах в год. У нас в GreenBushDC доступность сервиса измеряется в процентах и составляет 99,982% в год.
-
Время реакции на инцидент. Это время от получения сообщения об инциденте, например, отказе оборудования, до начала работ над проблемой. Инциденты, в свою очередь, делятся по уровню критичности на несколько категорий. Очевидно, что время реакции на сбои с низким уровнем критичности больше, чем время реакции на инциденты с высоким приоритетом.
Зачем вообще нужны эти метрики? Чтобы четко определить ожидания по качеству. В классических договорах это, как правило, не предусмотрено. Там вы можете увидеть размытое «Исполнитель обязан устранить неисправность после обращения заказчика». В соглашении SLA этот же пункт предельно конкретен: «Исполнитель обязан фактически приступить к устранению неисправности в рабочее время (9-18 часов) в течение 30 минут с момента регистрации заявки; в нерабочее время (19-08 часов) в течение 60 минут с момента регистрации заявки в журнале службы технической поддержки».
Пример гипотетический, но он полностью отражает разницу между договором и Service Level Agreement.
Условия оплаты и компенсации
Помимо определения услуг и метрик в SLA фиксируется порядок оплаты, момент ее списания и условия возврата средств за неиспользованную услугу. Также определяются штрафы и санкции за несоблюдение нормативов и нарушение условий. Размер штрафа рассчитывается как процент от стоимости договора.
В хорошем SLA есть еще и порядок разрешения спорных ситуаций. Случается, что исполнитель считает заявку выполненной, а клиент недоволен выбором технологии или результатом. К примеру, когда для восстановления работоспособности сервера подрядчик использовал не компоненты вендора, а расходные материалы из имеющихся на складе. Или когда отклонения от целевых метрик произошли по вине третьих лиц, а оборудование клиента не застраховано. Все спорные моменты невозможно отразить в соглашении SLA, но порядок рассмотрения и решения вопроса можно и нужно регламентировать.
SLA как фактор выбора дата-центра
SLA считается одним из основополагающих критериев выбора ЦОД. Именно поэтому в некоторых соглашениях об уровне обслуживания декларируются исключительно привлекательные уровни доступности или очень жесткие штрафные санкции. С такими SLA мы рекомендуем руководствоваться трезвым расчетом и потребностями бизнеса.
С позиции трезвого расчета имеет смысл проверить, отражают ли параметры SLA фактически достоверные показатели ЦОДа, а с точки зрения потребностей бизнеса — соотнести метрики SLA и предложенную компенсацию с финансовыми и репутационными потерями при простое IT-сервиса. На практике компенсация далеко не всегда решает вопрос экономического ущерба, поэтому реальная надежность, клиентоориентированность и эксплуатационная устойчивость дата-центра важнее декларируемых санкций и компенсаций.