Что такое SLA и зачем оно
SLA (Service Level Agreement) — соглашение об уровне услуги между поставщиком и заказчиком: что входит в услугу, с какими сроками и в какое время она поддерживается, как измеряется качество и что происходит при нарушении. SLA защищает обе стороны: заказчик понимает, на что рассчитывать, поставщик — за что отвечает (а за что нет).
Важно различать три уровня: SLA — с внешним/внутренним заказчиком; OLA (Operational Level Agreement) — между внутренними командами, которые вместе обеспечивают SLA; UC (Underpinning Contract) — с внешними подрядчиками. Подробно — в материале Service Level Management: SLA, OLA, UC.
Структура SLA-соглашения
Рабочий SLA содержит как минимум следующие разделы:
- Стороны и предмет — кто поставщик, кто заказчик, какая услуга.
- Описание услуги — что входит и, не менее важно, что НЕ входит (out of scope).
- Время поддержки — рабочий календарь (например, 8×5 или 24×7), часовой пояс, исключения (праздники).
- Приоритеты и их определение — как классифицируются обращения (критичность × срочность).
- Целевые метрики — время реакции и решения по каждому приоритету.
- Правила пауз — когда таймер SLA останавливается (ожидание ответа заказчика, согласование).
- Эскалация — кому и когда передаётся при риске нарушения.
- Отчётность — как и с какой периодичностью измеряется выполнение.
- Ответственность — последствия нарушения (если применимо).
Метрики и таблица сроков
Ядро SLA — таблица сроков по приоритетам. Пример для услуги поддержки 8×5:
| Приоритет | Описание | Время реакции | Время решения |
|---|---|---|---|
| Критический (P1) | Услуга недоступна, затронуты все | 15 минут | 4 часа |
| Высокий (P2) | Серьёзное ограничение, обход есть | 30 минут | 8 часов |
| Средний (P3) | Частное неудобство | 2 часа | 2 рабочих дня |
| Низкий (P4) | Вопрос, запрос на изменение | 4 часа | 5 рабочих дней |
Различайте время реакции (первый осмысленный ответ/взятие в работу) и время решения (услуга восстановлена). Это разные метрики с разными сроками — см. FRT vs resolution time.
Как считать время: календарь и паузы
Главный источник споров — как именно течёт таймер. Без рабочего календаря и пауз цифры будут неверными:
Поэтому SLA-движок системы должен поддерживать рабочий календарь (часы, праздники, часовой пояс) и автоматические паузы при переходе заявки в статус «ожидает ответа». Считать SLA «по календарным часам» — прямой путь к ложным нарушениям и конфликтам.
Типичные ошибки
- Нет раздела «не входит». Без явного out of scope заказчик считает, что входит всё.
- Один срок на все обращения. Критический сбой и вопрос «как сменить пароль» не могут иметь один SLA — нужны приоритеты.
- SLA по календарным часам. Без рабочего календаря заявка, пришедшая в пятницу вечером, «нарушается» к утру понедельника.
- Нет пауз. Если таймер не встаёт на ожидании ответа заказчика, поставщик отвечает за чужую задержку.
- Реакция = решение. Смешение двух метрик в одну строку запутывает обе стороны.
- Метрики, которые никто не измеряет. Если в системе нет отчёта по SLA — соглашение не работает.
В TIQQET SLA настраивается по дереву услуг с наследованием, поддерживает рабочий календарь, паузы на ожидание ответа и многоуровневую эскалацию — то есть считает сроки так, как описано в этом шаблоне, а не «по календарю».
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Частые вопросы
Чем SLA отличается от OLA и UC?
SLA — соглашение с заказчиком (внешним или внутренним). OLA — между внутренними командами, которые вместе обеспечивают SLA. UC — договор с внешним подрядчиком. Все три должны быть согласованы: нельзя обещать заказчику срок жёстче, чем позволяют OLA и UC.
Как считать время SLA — по календарным или рабочим часам?
По рабочим часам с учётом календаря, праздников и часового пояса, и с паузами на ожидание ответа заказчика. Расчёт по календарным часам приводит к ложным нарушениям (например, для заявок, пришедших в нерабочее время).
Сколько приоритетов нужно в SLA?
Обычно достаточно 3–4 (критический, высокий, средний, низкий) с чётким определением каждого через критичность и срочность. Меньше — теряется гибкость, больше — операторы путаются при классификации.
Нужно ли прописывать штрафы за нарушение SLA?
Для внешних коммерческих SLA — часто да (сервисные кредиты, скидки). Для внутренних SLA штрафы обычно заменяют отчётностью и эскалацией. Главное — чтобы последствия были измеримыми и реалистичными.