Соглашение об уровне обслуживания (Service Level Agreement, или SLA ) — договор между поставщиком ИТ-услуги и заказчиком. Появившись когда-то в ITIL как одна из рекомендаций, SLA стал незаменимым практическим инструментом. Сейчас именно на основе SLA в большинстве случаев выстраивается взаимодействие поставщика и заказчика.
Каждая компания составляет собственное соглашение с учетом требований заказчика. Тем не менее, есть стандартизованная структура SLA, которая включает около десятка разделов. Этой структуры, в большей или меньшей степени, придерживаются все:
- Описание, или определение, услуги, вовлеченные стороны, сроки действия SLA;
- Даты и время, в которые услуга будет предоставляться;
- Количество пользователей (сервиса), экземпляров оборудования или ПО;
- Регламент обработки запросов, инцидентов, а также подготовки отчетов о проблемах;
- Целевые показатели: согласованное время работоспособности, согласованное время поддержки, время реакции, доступность сервиса и т. д.;
- Расценки и график платежей за услугу;
- Компенсации за несоблюдение SLA и процедура разрешения спорных ситуаций.
Основной канал, через который поставщик и клиент взаимодействуют в рамках предоставления ИТ-услуги, — служба поддержки. Отсюда и ключевая роль Help Desk, или Service Desk, в SLA. Важно составлять подробное и грамотное SLA, чтобы оно учитывало все нюансы процесса оказания услуги.
Мы подготовили несколько советов, которые помогут составить SLA с измеримыми метриками и достижимыми целевыми показателями.
Периодически проверяйте и корректируйте SLA
ITIL рекомендует пересматривать и обновлять SLA всегда, когда в ИТ-сервис вносятся изменения. Так у поставщика и у клиента будет уверенность в том, что целевые показатели актуальны, а изменения не принесли вреда. В особенности это касается критичных метрик, таких как время работоспособности и время поддержки услуги.
Вы сервис-провайдер, который взял на поддержку виртуальную инфраструктуру клиента. Одна из ключевых метрик вашего SLA — параметр производительности системы хранения на HDD-дисках. Допустим, производительность СХД по SLA составляет 2000 IOPS.
В какой-то момент клиент переходит на новую ресурсоемкую СУБД. После чего в вашу службу поддержки начинает поступать всё больше запросов, связанных с медленной работой СХД. Выясняется, что клиента больше не удовлетворяет действующая метрика производительности, и он, не вникая в особенности технологии, просит пересмотреть SLA.
Анализируя отчеты Service Desk, вы можете действовать на опережение — пообщаться с клиентом и выяснить причины проблемы. Как вариант, можно перевести клиентскую базу данных на SSD-хранилище с производительностью 10 000 IOPS и предложить клиенту SLA с новыми метриками. Так, своевременный апгрейд инфраструктуры и пересмотр метрик поможет избежать конфликтной ситуации.
Однако даже если ваш ИТ-сервис не изменялся, «для профилактики» раз в год желательно проводить совместную ревизию SLA. Возможно, в бизнес-процессах клиента произошли изменения, которые повлияли на сервис, но не были учтены.
Быстрый старт Service Desk
Развёртывание и запуск ITSM-системы в сжатые сроки. Настройка платформы и обучение сотрудников
Узнать больше
Добавьте ограничения и исключения
Нередко проблемы с выполнением целевых показателей не зависят напрямую от качества работы техподдержки. Желательно учесть в SLA все возможные исключения, которые могут быть вызваны объективными или форс-мажорными обстоятельствами.
Время реакции. Если у вас проводится регулярное плановое техобслуживание систем мониторинга, когда вы не можете оперативно ответить на запрос, укажите это в SLA в качестве ограничения. Например: «Гарантированное время реакции на запрос — до 1,5 часов, кроме каждой второй среды месяца в период с 1.00 до 4.00». Добавьте детальное объяснение причины.
Периоды простоя. Отметьте ситуации, когда простой сервиса не зависит от вас и время неработоспособности сервиса может возрасти. Например:
- недоступность каналов связи и оборудования, которые находятся вне вашей зоны ответственности;
- негативное влияние на сервис приложений клиента, которые не контролируются вами;
- форс-мажорные обстоятельства (стихийные бедствия и пр.).
Время поддержки. Учтите период, в который вы не сможете поддерживать сервис, — к примеру, в нерабочее время и в выходные. Тогда согласованное время поддержи можно указать так: «8×5 (10:00-18:00, Пн-Пт)».
Задержка со стороны клиента. Иногда, чтобы правильно обработать запрос, от клиента требуется дополнительная информация. Если клиент по какой-либо причине не предоставляет эту информацию, временные метрики могут быть нарушены. В этом случае отклонения от целевых показателей — в первую очередь, времени решения — можно квалифицировать как допустимые.
Сделайте SLA измеримыми
Метрики, на которые ориентируется служба поддержки и которые предоставляются клиенту, должны недвусмысленно показывать, было ли достигнуто SLA. Это возможно при соблюдении нескольких условий.
- Конкретика. Все пункты SLA должны быть конкретным и достаточно подробными. Так клиент будет знать, что именно ожидать от услуги. Поставщик же будет четко понимать свои обязательства, требования к их выполнению и сроки.
- Прозрачность. У клиента должна быть возможность отслеживать фактические результаты работы службы поддержки и понимать, соответствуют ли они описанным в SLA. Во многих современных ITSM-системах это одна из базовых функций. Если процесс соблюдения показателей SLA не автоматизировать, службе поддержки сложно будет контролировать его и тем более отчитываться перед клиентом.
- Достижимость. SLA должно быть реалистичным и выполнимым. Если сотрудникам поддержки ставят недостижимые цели, мотивация у них пропадает.
- Релевантность. Соглашение должно быть связано с конкретной услугой, с ее целевыми показателями, количественными и качественными характеристиками. Чем больше в SLA абстрактных определений и не связанных с услугой сущностей, тем труднее его соблюдать.
- Своевременность. В SLA должны быть прописаны все временные рамки, которые должен соблюдать поставщик сервиса — от времени реакции до согласованного времени работоспособности (СВР).
Быстрый старт Service Desk
Развёртывание и запуск ITSM-системы в сжатые сроки. Настройка платформы и обучение сотрудников
Узнать больше
Сделайте отдельные метрики для каждого уровня поддержки
Help Desk и Service Desk обычно многоуровневые службы. У каждого уровня определенные специфика, сложность задач и KPI. Это нужно учитывать при согласовании в SLA времени реакции и времени решения проблем.
Возьмем для примера техподдержку ITSM-системы. Help Desk такой системы чаще всего включает три линии обслуживания.
Первая линия обрабатывает запросы пользователей и решает простые проблемы — ей на это требуется в среднем один-два часа.
Вторая решает более сложные проблемы — от нескольких часов до суток.
Третья линия, например разработчики, может отрабатывать тикеты до нескольких дней, а то и недель.
Рассчитывайте временные метрики в SLA индивидуально для каждой линии техподдержки. Метрики должны быть реалистичными: если проблема требует сложных работ с привлечением третьей линии поддержки, ее невозможно решить за сутки.
Объясните клиенту, почему у разного типа инцидентов и запросов на обслуживание разные сроки решения, и от чего они зависят.
Учитывайте ожидания клиента
В SLA указываются не просто цифры, а достоверные показатели, которые отражают фактические желаемые результаты для клиента. Важно, чтобы клиент понимал каждый целевой показатель и ограничения поставщика.
Если уровень гарантированной доступности сервиса 99,9%, ему позволено «лежать» суммарно 43 минуты в месяц. Сценарии могут быть разными. Например — четыре некритичных инцидента ночью с простоем по 10 минут каждый. Либо 40 минут днем, в час пиковой нагрузки, когда простой сервиса приведет к многомиллионным убыткам. Формально поставщик не нарушит SLA, но вряд ли клиент будет удовлетворен качеством услуги.
Согласуйте свои возможности и ожидания клиента. Если для клиента критичен простой даже в 10 минут, можно организовать бесперебойную работу сервиса — например, за счет резервирования канала связи. И вам, и клиенту такой уровень доступности будет стоить дороже, но зато SLA будет реалистичным.
Избегайте общего SLA для клиентов с географически распределенной структурой
Бывают заказчики с филиалами в разных городах. При этом у одного и того же запроса на обслуживание сроки решения могут отличаться в зависимости от филиала.
Вы обслуживаете офисную компьютерную технику компании с несколькими филиалами. Заказчик просит, чтобы сломавшийся ноутбук заменяли не позднее, чем до обеда следующего за обращением рабочего дня. Для головного офиса, который находится в крупном городе, это реалистичные сроки. В филиале, который расположен в удаленном райцентре, — чаще всего нереалистичные. Потому что время решения зависит от скорости работы службы доставки и, возможно, от других факторов. В таком случае единый SLA работать не будет.
Составляйте SLA для каждого удаленного подразделения клиента, где срочность, приоритеты и время решения будут рассчитываться с учетом локальных особенностей.
