Service Level Management: SLA, OLA и UC — три уровня соглашений

SLA, OLA и UC: кто кому что обещает

Три типа соглашений отличаются сторонами, между которыми они заключены:

SLA (Service Level Agreement) — между IT-службой и заказчиком/бизнесом. «Инциденты P1 восстанавливаем за 4 часа в рабочее время». Это то, что видит пользователь.
OLA (Operational Level Agreement) — внутренние договорённости между командами одной организации. «Отдел сети берёт эскалацию в течение 1 часа», «администраторы БД восстанавливают за 2 часа». OLA не видны заказчику, но именно они обеспечивают SLA.
UC (Underpinning Contract) — договор с внешним подрядчиком: интернет-провайдер, вендор СХД, облако. Юридически обязывающий, с собственными метриками и штрафами.

Простой образ: SLA — это обещание клиенту, OLA — обещания коллег внутри, UC — обещания поставщиков. Все три должны «сходиться» по времени.

Почему SLA не может быть быстрее своих OLA

Самая частая ошибка SLM — пообещать заказчику время, которое физически недостижимо из-за внутренних звеньев. Разложим SLA «восстановление P1 за 4 часа» на цепочку:

SLA: восстановить за 4ч
  ├─ L1 диагностика и эскалация ......... 30 мин
  ├─ OLA с отделом сети: реакция ........ 60 мин
  ├─ UC с провайдером: замена канала .... 3 часа  ← !
  └─ L1 проверка и закрытие ............. 15 мин
Итого в худшем случае: ~4ч 45мин > SLA

Если UC с провайдером допускает 3 часа на восстановление канала, обещать заказчику 4 часа на инцидент, завязанный на этот канал, — значит закладывать гарантированное нарушение. SLM требует считать SLA снизу вверх: сначала фиксируются реальные OLA и UC, и только потом из них собирается обещание заказчику с запасом.

Цикл Service Level Management

SLM — это не разовое подписание документа, а непрерывный цикл:

Определить услуги и их ценность. Нельзя дать SLA на «всё IT» — только на конкретные услуги из каталога.
Согласовать целевые уровни. С бизнесом — по реальной потребности (не «99.99% всему», а там, где это нужно и оплачено).
Выстроить OLA и UC под SLA. Проверить, что внутренние и внешние звенья выдерживают обещанное.
Мониторить и отчитываться. Регулярный SLA-отчёт: % соблюдения, тренды, нарушения с причинами.
Пересматривать (Service Review). Раз в квартал — встреча с заказчиком: что меняем в целях, где SLA избыточен, где не хватает.

Этот цикл — частный случай непрерывного улучшения: SLA не высекают в камне, его подгоняют под меняющуюся реальность.

Типичные ошибки и как считать достижимость

Что чаще всего ломает SLM:

SLA без OLA. Обещание заказчику есть, а внутренние команды о нём не знают и не обязаны реагировать в нужное время.
Единый SLA на инциденты и запросы. См. почему дедлайны должны быть разные.
Игнор рабочего календаря. «4 часа» в режиме 8×5 и 24×7 — это совершенно разные обязательства. Часы SLA должны останавливаться в нерабочее время, если услуга не круглосуточная.
SLA как KPI оператора. Приводит к манипуляциям приоритетами вместо реального улучшения.

Достижимость SLA проверяется простым расчётом доступности из availability management: если суммарное время простоя звеньев в цепочке превышает целевое — SLA недостижим математически, и его нужно либо смягчать, либо усиливать звенья (новый UC, резервирование, доп. персонал на L2).

Попробуйте TIQQET в деле

On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.

Посмотреть демо

Частые вопросы

В чём разница между SLA, OLA и UC?

SLA — соглашение с заказчиком (внешнее обещание). OLA — внутренние договорённости между командами организации. UC — договор с внешним подрядчиком. Все три должны быть согласованы по времени, чтобы SLA был выполним.

Можно ли обещать SLA, если нет OLA?

Технически да, но это обещание в вакууме. Без зафиксированных OLA внутренние команды не обязаны реагировать в нужное время, и SLA будет нарушаться без видимой причины.

Как понять, что SLA вообще достижим?

Разложить его на цепочку звеньев (L1, OLA с командами, UC с подрядчиками) и сложить максимальное время каждого. Если сумма больше целевого SLA — он недостижим математически и нуждается в пересмотре.

Нужно ли учитывать рабочий календарь в SLA?

Обязательно. SLA «4 часа» в режиме 8×5 и 24×7 — разные обязательства. Часы SLA должны останавливаться в нерабочее время, если услуга не круглосуточная.

Как часто пересматривать SLA?

Регулярный Service Review — раз в квартал с заказчиком: где SLA избыточен, где не хватает, что изменилось в бизнес-потребности. SLA — живой документ, а не разовое подписание.