SLA — это соглашение о том, какой уровень сервиса предоставляет компания. Обычно этот термин используется в IT и телекоммуникациях. 

В отличие от обычных договоров оказания услуг, Service Level Agreement предлагает очень подробное описание качества услуг, режима работы, времени реагирования на обращение и других параметров.

Основные характеристики SLA

Соглашение об уровне сервиса обычно обладает следующими характеристиками:

• Максимально возможная прозрачность всех процессов и взаимодействий между поставщиком услуг и клиентом. При составлении договора стараются избегать размытых формулировок, которые можно трактовать двояко в ту или иную сторону. 
• Понятные всем участникам соглашения права и обязанности. Например, провайдер обязуется обеспечить доступность сервисов в 99,9% времени и оплатить компенсацию при зафиксированном меньшем значении, а клиент имеет право запросить эту компенсацию.
• Управление ожиданиями. Например, клиент ожидает, что поддержка будет круглосуточной и очень быстрой даже по самым незначительным вопросам, а провайдер не может предоставить такую услугу. В таком случае клиенты стоит либо понизить свои ожидания, либо заключить договор с другим провайдером. Может быть и третий вариант — провайдер повысит уровень сервиса, если это принесет пользу его бизнес-процессам.

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

Соглашение не всегда должно быть огромным. Главное, чтобы оно в понятных формулировках описывало основные параметры работы сервиса. Например, SLA S3 (один из сервисов AWS) — это одна страница текста. Здесь указаны ежемесячные проценты безотказной работы и размер компенсации, которую получает клиент, если сервис не укладывается в эти границы.

Что обычно указывают в SLA

Выше мы привели пример SLA от Amazon Web Services. Это не стандарт, а лишь один из вариантов, который учитывает специфику конкретного сервиса.

В SLA для IT часто расписывают следующие пункты:

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

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

При описании качества сервиса также раскрываются его параметры. Обычно это:

• Доступность самого сервиса.
• Время реакции на возникшую проблему.
• Время устранения неисправностей.

В соглашение может быть также указана метрика часов работы. 

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

Ключевые параметры 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,99%. Соглашение гарантирует, что простой сервисов не превысит 52 минут в год. 

Провайдеры могут обещать и пять девяток — 99,999% или не более 15 минут простоя сервисов в год. Но это не всегда лучшее решение. Есть как минимум две вещи, которые стоит иметь в виду:

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

Смотреть стоит не только на количество девяток, но и на время, которое провайдер указывает для контроля. По умолчанию в договор SLA вписывают показатели за год. Например, вам обещают, что сервисы будут доступны 99,95% времени. Простой — не более 4,5 часов в год.

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

Еще один важный момент — совокупная доступность. Она равна наименьшему показателю.

Плюсы SLA

Подписание и соблюдение SLA выгодно обеим сторонам. 

Компания фиксирует свои обязанности и ограждает себя об неожиданных требований клиентов — например, срочно исправить некритичную проблему посреди ночи. 

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

Клиенты, подписывая соглашение, видят, на какие услуги они могут рассчитывать, в какие сроки и в каком порядке их оказывают. Это помогает планировать свою основную деятельность. 

SLA и SLO: в чем разница

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, а сами составляете его, чтобы предложить клиентам, обратите внимание на следующие пункты:

• Пользователи. В больших системах рекомендуется разделять пользователей на группы и работать с ними отдельно. Это помогает эффективнее распределить ресурсы и не разрываться между запросами разных групп клиентов.
• Сервисы. Здесь важна критичность сервиса для конкретной группы клиентов. Например, вы предлагаете CRM торговым компаниям. Если они не смогут ей пользоваться, то понесут убытки и придут с претензиями. Поэтому у такого сервиса самый высокий уровень критичности. Условная замена принтера или создание новой учетной записи для сотрудника на этом фоне может подождать до завтра.
• Параметры качества сервисов. Они должны соотноситься с бизнес-целями компании и потребностями клиентов. Стандартный пример — время и порядок устранения инцидентов. Например, компания может гарантировать круглосуточную поддержку или решать проблемы только по будням с 9:00 до 18:00.

Соглашение об уровне сервиса — это документ, о появлении или изменении которого необходимо оповестить всех пользователей, вне зависимости от уровня привилегий и критичности сервиса.

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

Главная цель показателей SLA service — не заманить пользователей, а обеспечить открытый диалог с ними. Каждый участник соглашения принимает его и обязуется соблюдать условия. Нарушение SLA — это повод потребовать возмещения убытков и прекратить сотрудничество.