Что такое SLA и зачем он нужен
SLA — это соглашение между поставщиком сервиса (IT-подразделение или внешний подрядчик) и потребителем (бизнес, сотрудники, клиенты), в котором зафиксированы измеримые параметры качества услуги. В контексте технической поддержки SLA обычно включает:
- Время реакции (First Response Time, FRT) — через сколько минут после создания обращения оператор обязан ответить.
- Время решения (Time to Resolve, TTR) — через сколько часов или минут обращение должно быть решено.
- Часы обслуживания — рабочее окно службы поддержки (например, 9:00–18:00 по будням, или 24/7 для критичных услуг).
- Приоритеты — градация обращений (низкий / средний / высокий / критичный) с разными сроками для каждого приоритета.
- Порядок эскалации — когда и кому передаётся обращение при угрозе просрочки.
- Метрики соответствия — целевой процент выполнения SLA (например, «не менее 95% обращений в срок»).
SLA часто путают с OLA и UC. OLA (Operational Level Agreement) — соглашение между внутренними командами IT (например, 1-я линия и 2-я линия). UC (Underpinning Contract) — договор с внешним подрядчиком. Все три документа взаимосвязаны: SLA не может быть короче, чем OLA или UC, лежащие в его основе.
Виды SLA
SLA классифицируют по нескольким осям. Самое практичное деление — по предмету соглашения:
- Service-based SLA — единый SLA для конкретной услуги, одинаковый для всех потребителей. Пример: «SLA для услуги «Электронная почта»: восстановление в течение 4 часов в рабочее время».
- Customer-based SLA — разные SLA для разных клиентов. Пример: VIP-подразделение получает дедлайн 2 часа, остальные — 8 часов.
- Multi-level SLA — трёхуровневая структура: корпоративный уровень (общие для компании), уровень заказчика (специфика подразделения), уровень услуги (параметры конкретной услуги).
На практике большинство компаний останавливаются на service-based SLA — это самый простой и прозрачный вариант. Кастомизация под конкретных клиентов усложняет администрирование и оправдана только при наличии реальных бизнес-причин.
Как рассчитать реалистичный SLA
Главная ошибка — ставить SLA «с потолка» или копировать цифры у конкурентов. Разумный подход выглядит так:
Шаг 1. Соберите исторические данные
Посмотрите, сколько времени у вас фактически занимает решение обращений за последние 3–6 месяцев. Разделите выборку по приоритетам и типам. Посчитайте медиану и 90-й перцентиль. Если у вас ещё нет системы учёта — это повод её установить: без объективных данных SLA-цели становятся выдумкой.
Шаг 2. Определите узкие места
Разложите среднее время решения на этапы: ожидание в очереди, диагностика, выполнение, тестирование, закрытие. Где больше всего времени уходит? Часто оказывается, что 70% срока — это ожидание, пока заявка «висит» в статусе «новая».
Шаг 3. Оцените ёмкость команды
SLA должен быть достижимым с текущим штатом. Если вы видите, что для выполнения цели нужно решать 50 заявок в день, а команда физически справляется с 30 — либо расширяйте команду, либо корректируйте SLA, либо разгружайте через автоматизацию и самообслуживание.
Шаг 4. Привяжите приоритеты к реальному impact
Типовая матрица приоритетов строится по двум осям: Impact (влияние — количество пострадавших пользователей или критичность бизнес-процесса) и Urgency (срочность — скорость, с которой проблема нарастает).
| Impact низкий | Impact средний | Impact высокий | |
|---|---|---|---|
| Urgency низкая | Низкий (TTR 5 раб. дней) | Средний (TTR 2 раб. дня) | Высокий (TTR 8 часов) |
| Urgency средняя | Средний (TTR 2 раб. дня) | Высокий (TTR 8 часов) | Критичный (TTR 4 часа) |
| Urgency высокая | Высокий (TTR 8 часов) | Критичный (TTR 4 часа) | Критичный (TTR 2 часа) |
Рабочий календарь: почему это критично
Одна из самых распространённых ошибок — считать SLA в астрономическом времени. Заявка создана в пятницу в 17:50 с дедлайном 4 часа — и к понедельнику утром она «просрочена». На самом деле команда поддержки в это время не работала, и формальная просрочка никого не интересует.
Правильный расчёт — только в рабочее время, с учётом:
- Часов обслуживания услуги (например, 9:00–18:00, Пн–Пт)
- Государственных праздников и переносов рабочих дней
- Локального календаря услуги (если услуга работает 24/7 или, наоборот, только в определённые часы)
- Пауз SLA (когда заявка в статусе «ждёт пользователя» или «на согласовании», таймер приостанавливается)
В нашей системе каждая услуга может иметь собственный график и календарь исключений, а SLA автоматически ставится на паузу при переходе в статусы ожидания. Это избавляет от ручных пересчётов и споров «а у нас праздник был, не считается».
Паузы SLA: когда таймер должен остановиться
Если пользователь не ответил на уточняющий вопрос оператора, вина не лежит на службе поддержки. Логично в этот момент остановить SLA-таймер. Типичный список статусов, при которых SLA приостанавливается:
- Ожидает пользователя — нужна информация или подтверждение от автора обращения.
- На согласовании — ждём подписи руководителя по рабочему процессу.
- Отложено — пользователь попросил вернуться к задаче позже, или ждём поставки оборудования.
- У подрядчика — обращение эскалировано внешнему партнёру, на которого у вас есть отдельный UC.
При переходе в такой статус фиксируется момент паузы. При возврате в активный статус — рассчитывается, сколько времени таймер не работал, и на это время продлевается дедлайн.
Метрики соответствия SLA
Соблюдение SLA измеряют процентом обращений, уложившихся в срок. Типовые уровни:
- 99% — премиальный уровень (критичные продакшн-сервисы с финансовыми SLA-штрафами)
- 95% — стандарт для коммерческой поддержки
- 90% — приемлемо для внутренней IT-службы среднего размера
- <85% — сигнал, что SLA нереалистичен или команда недоукомплектована
Отдельно измеряют SLA по реакции и SLA по решению — это разные метрики, и качественная команда может держать 98% по реакции и только 87% по решению (если сложные задачи требуют эскалации в разработку). Подробнее о KPI поддержки — в статье о 12 метриках.
Пять типовых ошибок при внедрении SLA
- SLA без согласования с бизнесом. IT-отдел сам себе назначает сроки — бизнес узнаёт о них только когда начинаются штрафы. Правильно: SLA — это соглашение, оно обсуждается и утверждается совместно.
- Одинаковые сроки для всех приоритетов. Убивает саму идею приоритизации. Критичный инцидент, который валит продакшн, и запрос на замену мыши в переговорке — это разные вселенные.
- Расчёт в астрономическом времени. Таймер SLA должен учитывать рабочее время, праздники и паузы. Иначе статистика врёт.
- Нет эскалаций. SLA без автоматической эскалации — это бумажка. Система должна сама поднимать тревогу, когда до дедлайна осталось 20% времени.
- Штрафы без разбора причин. Формальный подход «просрочил = минус премия» демотивирует сильнее, чем помогает. Сначала разбираем почему, потом решаем что с этим делать.
SLA во внешних договорах
Если вы — ИТ-подрядчик и SLA вынесен в коммерческий договор, дополнительно прописываются:
- Финансовые санкции за каждый час просрочки (обычно % от ежемесячного платежа)
- Исключения и форс-мажоры (работы у провайдера, DDoS-атаки, действия заказчика)
- Порядок фиксации инцидента (только через согласованные каналы)
- Периодичность отчётности (ежемесячный отчёт о выполнении SLA)
- Процедура пересмотра SLA (раз в 6 или 12 месяцев)
Если вы — заказчик, проверьте: в договоре подрядчика чётко описан момент начала отсчёта SLA (от создания тикета в их системе или от отправки письма с вашей стороны). Разница в трактовке может превратить «4 часа на решение» в 4 часа плюс сутки на регистрацию.
Вывод
SLA — это не юридический документ, а инструмент управления ожиданиями и загрузкой команды. Чтобы он работал, нужно три вещи: реалистичные цифры на основе исторических данных, корректный расчёт с учётом рабочего времени и автоматические эскалации, предупреждающие о риске просрочки заранее.
Без системы учёта заявок построить такой SLA практически невозможно — вы просто не увидите реальную картину. Если вы сейчас ведёте поддержку в Excel или почте, начните с внедрения полноценной системы управления IT-обращениями, а уже на её данных выстраивайте SLA.
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Посмотреть демоЧастые вопросы
Чем SLA отличается от KPI?
SLA — это обязательство перед клиентом (целевой уровень сервиса). KPI — показатель для оценки работы команды или процесса. Одна и та же метрика (например, время решения) может быть одновременно и SLA-параметром в договоре, и KPI для оценки операторов. Но логически это разные вещи: SLA отвечает «что мы должны делать», KPI — «насколько хорошо мы это делаем».
Что делать, если SLA постоянно нарушается?
Сначала разберите причины. Распространённые варианты: нереалистичный SLA (скорректировать), нехватка штата (расширить команду или внедрить автоматизацию), плохая маршрутизация (настроить правила), большая доля «ожидания пользователя» (улучшить формулировки уточняющих вопросов). Формальное «накажем виновных» редко помогает.
Нужно ли указывать SLA в публичной оферте?
Если вы продаёте услугу, где уровень сервиса — часть ценности (поддержка, хостинг, SaaS), — да. Это повышает доверие и снимает часть вопросов на этапе продажи. Наш пример — публичная оферта TIQQET.
Какой процент соответствия SLA считается нормальным?
Для внутренней корпоративной поддержки — 90–95%. Для коммерческой — 95–99%. Ниже 85% — симптом проблем в процессах или ресурсах. Выше 99% — часто значит, что SLA слишком мягкий и не мотивирует улучшать скорость.
Можно ли автоматизировать контроль SLA?
Да, и это обязательное условие для работы с SLA на масштабе больше нескольких десятков заявок в месяц. Система должна сама рассчитывать дедлайны в рабочем календаре, показывать заявки на грани просрочки, автоматически эскалировать и строить отчёты по соответствию. Подробнее про механизм SLA в TIQQET.
Обязательно ли привязывать SLA к ITIL?
Нет. SLA — самостоятельное понятие, оно существовало до ITIL и используется вне него. ITIL просто систематизирует практики вокруг SLA (каталог услуг, управление уровнем сервиса, отчётность) в рамках общей модели управления IT-услугами. Подробнее про ITIL — в нашей статье.