SLA — это соглашение о том, какой уровень сервиса предоставляет компания. Обычно этот термин используется в IT и телекоммуникациях.
В отличие от обычных договоров оказания услуг, Service Level Agreement предлагает очень подробное описание качества услуг, режима работы, времени реагирования на обращение и других параметров.
Соглашение об уровне сервиса обычно обладает следующими характеристиками:
В соглашении указывают сроки устранения неисправностей и решения других проблем. Также описываются возможные компенсации, которые может получить клиент, если компания не выполнит заявленные метрики.
Соглашение не всегда должно быть огромным. Главное, чтобы оно в понятных формулировках описывало основные параметры работы сервиса. Например, SLA S3 (один из сервисов AWS) — это одна страница текста. Здесь указаны ежемесячные проценты безотказной работы и размер компенсации, которую получает клиент, если сервис не укладывается в эти границы.
Выше мы привели пример SLA от Amazon Web Services. Это не стандарт, а лишь один из вариантов, который учитывает специфику конкретного сервиса.
В SLA для IT часто расписывают следующие пункты:
В соглашении также может быть указан срок его действия. В некоторых случаях стороны подробно расписывают порядок добавления новых требований к функциональности или доступности сервисов.
При описании качества сервиса также раскрываются его параметры. Обычно это:
В соглашение может быть также указана метрика часов работы.
При описании порядка оплаты услуг может быть указана модель (например, оплата по факту использования ресурсов, фиксированный тариф и так далее). Если предусмотрены штрафы — то ситуации, в которых провайдер их выплачивает. Если клиент может рассчитывать на компенсацию, то в SLA тоже расписывают соответствующие ситуации и порядок выплат.
Параметры SLA — это метрики, которые можно измерить. В соглашении не пишут, что любые проблемы устранят быстро, а вы «глазом не успеете моргнуть». Это пример нечетких формулировок, которые мешают всем участникам выстраивать нормальные рабочие процессы.
Например, метрика режима работы. В ней должно быть четко прописано, в какое время и для каких групп пользователей доступна техническая поддержка.
Допустим, компания делит всех клиентов на несколько групп. Первой группе гарантируют круглосуточную поддержку по телефону и в чате. Второй — поддержку по телефону и в чате, но только по будням. Третьей — поддержку только в чате и только по будням.
Метрики нужны для того, чтобы все участники соглашения понимали, какие услуги, когда и в каком объеме они получат. Отсюда следуют несколько характеристик:
При установке метрик важно не ставить слишком жесткие требования. Это приводит к значительному увеличению стоимости работ.
Например, есть проблема, которую средний специалист может решить за 4 часа. Эксперт более высокого уровня решает ту же проблему за 2 часа. Писать в SLA значение метрики 2 часа — не лучший выбор. Это приведет к тому, что работа эксперта моментально подорожает. Если написать 1 час, то к затратам на работу эксперта добавятся еще высокие риски нарваться на штрафы за несоблюдение договоренностей.
Кроме часов работы могут быть и другие важные метрики. Например, время отклика специалиста поддержки на заявку клиента. Значения могут быть разными в зависимости от статуса заказчика услуги и критичности проблемы.
Допустим, компания предоставляет IT-услуги на аутсорсе. У нее есть группа пользователей, которая оплачивает премиум-тариф, и группа пользователей на базовом тарифе. Время реакции на инцидент может быть разным в зависимости от группы. Например, клиенты из первой группы получают ответ в течение 15 минут. А клиенты из второй группы могут ждать до суток. Все это должно быть четко отражено в SLA.
Кроме времени отклика на заявку есть также время решения инцидента. Логика регулирования этого параметра такая же. Даже если клиент очень важный, его запросы могут обрабатываться с разной скоростью в зависимости от их критичности.
Допустим, у клиента перестала работать локальная сеть в офисе и все процессы остановились. Устранением такой проблемы нужно заниматься в первую очередь. В SLA можно прописывать конкретные ситуации и время работы над ними. Допустим, проверка и настройка локальной сети — не более 5 часов.
Тот же самый клиент может прийти с менее важной проблемой. Например, с локальной сетью все в порядке, нужно просто добавить в нее пару устройств для новых сотрудников. Здесь время решения вопроса может занимать несколько часов или даже рабочих дней.
Время отклика на вызов клиента и время решения проблемы в совокупности составляют время простоя.
Эти и другие параметры должны быть описаны в SLA и приняты всеми сторонами до начала сотрудничества. Такой подход позволяет снизить количество конфликтов. Каждый понимает, чего ждать от другой стороны.
Для провайдеров одним из самых важных параметров соглашения об уровне сервиса является доступность услуги. Обычно она измеряется в днях, часах, минутах в оговоренный промежуток времени. Например, провайдер гарантирует, что услуга облачного хранилища данных будет доступна 99,99% времени в течение года.
В абсолютных числах кажется, что между SLA 99 и SLA 100 нет заметной разницы. Но если переложить эти значения на год, то отличия будут существенными. При 99% вы соглашаетесь на то, что серверы могут простаивать до 4 дней в год. При 100% простоя не должно быть вообще. Но такого не гарантирует ни одна компания. В SLA-соглашении всегда вписывают девятки, незначительно разбавленные другими цифрами после запятой.
Например, на timeweb.cloud доступность по SLA — 99,98%. Соглашение гарантирует, что простой сервисов не превысит 1 часа 45 минут в год.
Провайдеры могут обещать и пять девяток — 99,999% или не более 15 минут простоя сервисов в год. Но это не всегда лучшее решение. Есть как минимум две вещи, которые стоит иметь в виду:
Смотреть стоит не только на количество девяток, но и на время, которое провайдер указывает для контроля. По умолчанию в договор SLA вписывают показатели за год. Например, вам обещают, что сервисы будут доступны 99,95% времени. Простой — не более 4,5 часов в год.
Если в договоре прямо не указано, что в качестве единицы времени берется год, обязательно уточните это значение. Некоторые провайдеры пытаются схитрить и выдать месячные значения за годовые.
Еще один важный момент — совокупная доступность. Она равна наименьшему показателю.
Подписание и соблюдение SLA выгодно обеим сторонам.
Компания фиксирует свои обязанности и ограждает себя об неожиданных требований клиентов — например, срочно исправить некритичную проблему посреди ночи.
Есть и другие плюсы. Провайдер с помощью соглашения об уровне сервиса может упорядочить не только внешние, но и внутренние процессы. Например, ввести несколько уровней поддержки в зависимости от критичности сервиса и важности клиентов.
Клиенты, подписывая соглашение, видят, на какие услуги они могут рассчитывать, в какие сроки и в каком порядке их оказывают. Это помогает планировать свою основную деятельность.
SLA также можно рассматривать в качестве индикатора удовлетворенности пользователей. Высшее значение — 100%, низшее — 0%.
Добиться абсолютной удовлетворенности (100%) невозможно — так же, как нельзя гарантировать, что по SLA server всегда будет доступен. Поэтому при выборе конкретных метрик рекомендуют смотреть на продукт реалистично и выбирать посильные значения.
Например, если нет сотрудников для круглосуточной поддержки, то и обещать ее не стоит. Когда команда станет больше, вы можете изменить условия соглашения и обрадовать клиентов тем, что теперь они могут решать свои проблемы, не беспокоясь о рабочих часах.
Чтобы отслеживать уровень сервиса внутри компании, придумали еще одну систему — SLO. Это те значения метрик, которые поставщик услуг хотел бы достичь (objectives).
Берем тот же пример с технической поддержкой. Допустим, текущие возможности — обработка 50 обращений в течение рабочего дня, график — с 9:00 до 18:00 пять дней в неделю. Эти метрики компания фиксирует в SLA и показывает клиентам.
Параллельно составляется еще один документ — SLO. Это основа, на которой выстраивается управление уровнем услуг. В SLO учитываются текущие метрики, закрепленные в SLA, но дополнительно есть цель: например, увеличить количество обработанных обращений в течение рабочего дня до 75 или сделать поддержку круглосуточной. От этого зависит будущий IT-service level.
Начинать следует с описательной части. Обычно она включает глоссарий, описание системы, роли участников — пользователей, специалистов поддержки. Здесь же можно определить границы действия: территорию, время, функциональность.
Следующий раздел — описание услуг, которые предоставляются на сервисе. Эта часть должна давать полное представление о том, на что может рассчитывать клиент, который заключает соглашение с поставщиком.
После такого широкого определения начинается основная часть, в которой и описывается уровень сервиса. Здесь указаны:
Закончить SLA можно ссылками на другие документы, которые описывают и регламентируют процессы предоставления услуг.
На всех этапах подготовки SLA важно помнить, что это регулирующий документ. Его основная цель — контроль. Чем больше контроля над процессом, тем лучше SLA. Если контроля нет, то в существовании такого соглашения нет никакого смысла.
Если вы не подписываете SLA, а сами составляете его, чтобы предложить клиентам, обратите внимание на следующие пункты:
Соглашение об уровне сервиса — это документ, о появлении или изменении которого необходимо оповестить всех пользователей, вне зависимости от уровня привилегий и критичности сервиса.
SLA — технология управления, которая постоянно меняется. Вы можете увидеть на практике, что текущие параметры качества вредят бизнес-процессам или не отвечают требованиям пользователей, которые со временем возросли. В таком случае менеджмент принимает решение об оптимизации процессов или улучшении услуг.
Главная цель показателей SLA service — не заманить пользователей, а обеспечить открытый диалог с ними. Каждый участник соглашения принимает его и обязуется соблюдать условия. Нарушение SLA — это повод потребовать возмещения убытков и прекратить сотрудничество.