Service Level Agreement (SLA): все о соглашении об уровне сервиса

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

Впервые термин SLA появился в IT-отрасли. В сфере информационных технологий (ИТ) существует методология ITIL (IT Infrastructure Library - Библиотека инфраструктуры IT). Именно оттуда пришло понятие Service Level Agreement. Хотя сейчас оно трактуется гораздо шире, основной областью, где используются соглашения об уровне сервиса, продолжает оставаться IT.

SLA (Service Level Agreement) - соглашение об уровне сервиса. Иногда вместо "сервис" употребляются слова "услуга" или "обслуживание". Суть не меняется. SLA-соглашение - документ с регламентом уровня обслуживания, которое провайдер (поставщик услуг) обязуется предоставить заказчику. В договоре SLA устанавливается уровень доступности сервиса. Дополнительно указывается время реакции на инциденты.

Грамотно составленное соглашение об уровне сервиса SLA уменьшает число формулировок с двояким толкованием. Заказчик и провайдер устанавливают ясные и понятные правила сотрудничества. Стороны четко знают свои обязанности и оперируют идентичными терминами.

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

Соглашение об уровне услуг SLA выгодно обеим сторонам. Заказчики обретают уверенность в своевременном устранении инцидентов и эффективнее планируют бизнес-деятельность. Провайдеры избегают рисков от необоснованных требований к качеству услуг.

SLA в информационных технологиях

В сфере ИТ SLA означает договор на оказание IT-услуг. В стандартном соглашении обычно оговариваются следующие моменты:

• период времени, в течение которого провайдер предоставляет сервис;
• порядок урегулирования спорных ситуаций;
• правила подачи и прохождения заявок на обслуживание специалистами провайдера;
• ответственность сторон;
• число, параметры, местонахождение ПО и аппаратных средств, которые задействуются в процессе оказания услуги;
• размеры и сроки внесения платы за использование сервиса.

Зачем бизнесу SLA?

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

Наличие SLA гарантирует прозрачность оплаты. Заказчик точно знает, за что платит деньги. В зависимости от условий сотрудничества, стоимость услуг устанавливается за использование сервиса в целом или с разбивкой по отдельным уровням.

Понятный механизм формирования оплаты позволяет к тому же прогнозировать затраты на применение информационных технологий. Причём за расходы легко отчитаться перед налоговой службой. Провайдер предоставляет полный пакет отчётных документов.

Если случаются простои по вине провайдера, заказчик несёт минимальные финансовые потери. Расходы компенсируются поставщиком услуг. Размер компенсации устанавливается договором и зависит от конкретной ситуации.

Примечание

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

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

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

Благодаря SLA провайдеры устраняют инциденты в рамках установленных договором параметров без согласования с заказчиками. Плюс вводят многоуровневое оказание услуг. Например, согласно срочности или выбранного тарифа.

Как правильно написать SLA

SLA составляется с учетом особенностей сервиса. В качестве ориентира можно воспользоваться следующим шаблоном.

• Служебная информация – история версий, сведения о владельце соглашения, лист согласования с фиксацией замечаний и предложений по тексту договора.
• Вводная (определительная) часть – название и версия системы, информация о разработчике, перечень модулей и интерфейсов.
• Границы предоставления услуг – удаленно/территориально (город и адрес), по графику/круглосуточно.
• Перечень услуг – обработка обращений заказчиков, устранение последствий инцидентов, консультации по работе сервиса и пр.
• Приоритеты – низкий, нормальный, высокий, высший.
• КПЭ (ключевые показатели эффективности) – время реакции и решения инцидентов в зависимости от приоритета.

Пример классификации приоритетов в SLA-соглашении

SLA-соглашение начинается с вводной или определительной части. В самом начале договора приводится глоссарий. В словаре коротко описывается информационная система (ИС) и перечисляются роли участников.

Для информационной системы указывается название. Если применяется "продукт из коробки", приводится производитель - например, Oracle или Microsoft. Для самописных решений описывается стек технологий, который лежит в их основе.

Участники делятся на обычных и ключевых пользователей, а также сотрудников разных уровней поддержки (первая, вторая, третья и пр.). Для большей ясности стоит привести названия подразделений и роли их специалистов, которые вовлекаются в процесс.

На следующем этапе определяются границы действия Service Level Agreement (SLA). Территориальные устанавливают, как и где оказывается сервис. Например, в удалённом режиме или офисе заказчика. Временные отвечают на вопрос, когда предоставляются услуги – круглосуточно/определённое время, будние/выходные/праздничные дни.

В функциональных рамках задаётся мажорная версия системы, которая не изменяется после инсталляции обновлений. Если ИС относится к модульному типу, приводится перечень модулей. Наконец, указывается конфигурация и интерфейсы.

При составлении договора SLA описания услуг, которые формируют сервис, делаются краткими, но емкими и понятными. В будущем это уменьшает число вопросов от заказчиков.

Хорошая практика – приводить примеры услуг и сразу оговаривать, что в них входит или, наоборот, не включается. Услуги описываются компактно и нумеруются. В нумерованных списках гораздо проще ориентироваться.

Готовая определительная часть должна вызывать минимум вопросов. Чем меньше малопонятных моментов, тем лучше. Идеальный вариант – заказчик или его представитель понимает написанное с первого раза.

Метрики для SLA

Правильный выбор метрик для соглашения об уровне сервиса напрямую зависит от знания и понимания предметной области. В контексте информационных систем чаще всего оперируют 2 понятиями – время реакции на инцидент и целевое время решения проблемы.

Существуют и другие метрики:

• периоды простоя;
• время поддержки;
• задержка ответа от заказчика.

Если провайдер регулярно проводит плановое ТО систем, которые отвечают за мониторинг, есть вероятность несвоевременного ответа на запрос. Во избежание конфликтных ситуаций в соглашение об уровне сервиса SLA вводится ограничение. Как вариант, гарантируется время реакции на обращение заказчика в течение 1 часа за исключением понедельников в период с 3 до 6 утра.

При указании времени поддержки оговаривается период, когда провайдер не имеет возможности поддерживать работоспособность сервиса. Многие организации работают с понедельника по пятницу и отвечают на запросы заказчиков с 9-10 утра до 18 вечера. Аналогичный график прописывается в договоре техподдержки SLA.

К описанию периодов простоя стоит подходить вдумчиво. Особенно если провайдер несёт финансовую ответственность перед заказчиком из-за недоступности сервиса. В некоторых ситуациях поставщик не может принимать адекватные меры – военные действия, стихийные бедствия, аварии магистральных каналов связи и т. п. Форс-мажоры нужно постараться спрогнозировать заранее.

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

4 главных требования к метрикам SLA

1. Отражение качества сервиса.
2. Универсальность (использование одной и той же метрики во многих Service Level Agreement (SLA)).
3. Минимальное количество метрик.
4. Измеримость (чем проще измерить, тем лучше).

Если в договоре техподдержки SLA или аналогичном документе указывается больше 1 метрики, один из параметров обозначается как основной. Иначе провайдеру придётся заниматься сопоставлением метрик, а не критически важными проблемами. Распространённой практикой считаются штрафы за отклонение от нормы именно главного параметра.

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

Как мы видим, облака все больше и больше входят в повседневную жизнь как обычных людей, так и целых компаний. Облачные вычисления сильно упрощают, и главное – ускоряют процесс создания новых сервисов, что в свою очередь положительно сказывается на общих результатах компаний. Это гибкий инструмент, функционал которого совершенствуется год от года, позволяя переложить часть непрофильных задач на плечи провайдеров и сфокусироваться на своем основном бизнесе. Важной частью успешной работы является правильно составленный договор SLA.Михаил ТутаевЛидер продуктового направления PaaS SberCloud

Чек-лист: важные моменты SLA

Итак, мы получили общее представление, что такое SLA в IT. Пришла пора рассмотреть, на какие моменты стоить обратить внимание при подготовке SLA.

Группы пользователей. Когда система большая, не пытайтесь объять необъятное. Для начала возьмите несколько групп. Допустим, привилегированные и обычные пользователи. С парой категорий работать проще и эффективнее. Заодно получите мощный фундамент знаний для дальнейших действий.

Критические сервисы. Яркий тому пример – подключение к CRM. Если компания ведёт активную торговую деятельность, отсутствие связи с CRM рискует обернуться убытками. Работа менеджеров по продажам остановится или сильно замедлится.

Нормы качества. Принимайте в расчёт функционал сервиса и так называемые "целевые показатели".

Параметры и нормативы качества сервисов. Характеристики должны отвечать 2 требованиям. Во-первых, сопоставляться с бизнес-целями, которые преследует компания. Во-вторых, отражать потребности бизнес-пользователей системы. Примеры параметров – время устранения инцидентов и восстановления работы.

Фиксация SLA. После того, как разберётесь с предыдущими вопросами, зафиксируйте SLA среди пользовательских групп с учетом нормативов качества для отобранных критических сервисов.

Информирование пользователей. Об SLA оповещаются все без исключения лица, которых касаются правила из соглашения.

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

Анализ и оптимизация. Постоянно предпринимайте эффективные действия для достижения целевых показателей. Сервис должен на 100% удовлетворять потребности конечных пользователей.

Примеры готовых договоров SLA на английском языке

• GIVA
• PandaDoc.com