Что такое SLA и договор ИТ-обслуживания: простое объяснение

Что такое SLA простыми словами

SLA (Service Level Agreement) — соглашение об уровне обслуживания между заказчиком и ИТ-подрядчиком. Это приложение к договору, в котором чётко прописано: за какое время подрядчик реагирует на заявку, за какое время решает проблему, какой процент доступности систем гарантирует. SLA превращает абстрактное «мы вас поддерживаем» в измеримые обязательства с конкретными цифрами и штрафными санкциями.

Ключевые метрики SLA

Время реакции (Response Time)

Время от момента регистрации заявки до первого ответа инженера. Не путать с временем решения — реакция означает, что специалист взял заявку в работу, диагностировал проблему и сообщил ориентировочные сроки. Типичные значения: 15 минут для критических инцидентов, 30-60 минут для высокого приоритета, 2-4 часа для стандартных запросов.

Время решения (Resolution Time)

Время от регистрации заявки до полного устранения проблемы. Зависит от приоритета и сложности: критический инцидент (сервер недоступен, вся компания стоит) — 2-4 часа, высокий приоритет (не работает ПО у группы сотрудников) — 4-8 часов, стандартный запрос (настройка, подключение) — 1-2 рабочих дня.

Доступность (Uptime)

Доступность показывает долю времени, когда согласованный контур работает. Визард-АйТи публикует показатель 99,9%, а способ расчёта, границы и исключения фиксирует в SLA конкретного договора.

Типичные уровни SLA

Базовый

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

Стандартный

Если авария остановила важный бизнес-процесс, реакция может составлять до 15 минут. Для остальных уровней отдельно задаются влияние на бизнес, реакция, цель решения и эскалация.

Премиум

Для критичных систем стороны отдельно согласуют условия SLA: реакцию на P1 до 15 минут, мониторинг 24/7, окна реакции и восстановления. Такой формат нужен компаниям, где простой напрямую влияет на выручку, производство или обязательства перед клиентами.

Что должно быть в договоре ИТ-обслуживания

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

Обязательно проверьте: что считается «рабочим временем» (только будни или 24/7), входят ли выезды в абонентскую плату или оплачиваются отдельно, есть ли лимит на количество заявок в месяц, порядок расторжения и передачи инфраструктуры.

Финансовая ответственность

Финансовая ответственность делает SLA реальным обязательством. Один из типичных вариантов — уменьшение ежемесячного платежа на 5–10% за каждый час превышения срока решения критического инцидента или компенсация за недоступность систем сверх согласованного уровня. Размер, способ расчёта, границы и исключения записывают в договоре. Финансовая ответственность должна быть симметричной: заказчик также отвечает за своевременное предоставление доступов и согласование работ.

Как контролировать выполнение SLA

Контроль начинается с тикет-системы: каждая заявка фиксируется с таймстампами регистрации, реакции и решения. Ежемесячный отчёт от подрядчика должен включать: количество заявок по приоритетам, фактическое время реакции и решения, процент соблюдения SLA, список инцидентов с превышением нормативов.

Если подрядчик не предоставляет прозрачную отчётность или не использует тикет-систему — это первый признак того, что SLA существует только на бумаге.

Хотите договор ИТ-обслуживания с реальным SLA? Узнайте условия — покажем нашу тикет-систему, отчётность и метрики, которые фиксируются в договоре.

Отдельно проверьте, работает ли у вас шкала приоритетов. В разборе потока заявок группы компаний 96% обращений шли с приоритетом по умолчанию, а 27 из 31 заявки со словами «срочно» и «блокирует работу» тоже стояли как «Средний»: очередь держалась на неявной приоритизации службы, на которую нельзя сослаться при споре о сроке. Как разделить ответственность — заказчик оценивает влияние, служба назначает класс события и срок — разобрано в статье о приоритетах заявок и ответственности заказчика.