Что такое SLA в договоре на поддержку ПО
Основы3 минРедакция Innovialabs
Коротко
SLA — это часть договора, где измеримо прописано, как быстро подрядчик реагирует на проблемы, в какой срок их устраняет и какую доступность системы гарантирует. Без чисел и определений SLA превращается в пустое обещание.
Коротко: что такое SLA
SLA (Service Level Agreement, соглашение об уровне сервиса) — раздел договора или отдельное приложение, где подрядчик фиксирует измеримые обязательства по поддержке: как быстро отвечает, как быстро чинит, сколько времени система должна работать и что будет, если обещания нарушены.
Хороший SLA отвечает на четыре вопроса:
- Что считается инцидентом и какой он критичности.
- Когда подрядчик обязан среагировать и устранить проблему.
- Как измеряется выполнение.
- Что происходит при нарушении.
Время реакции и время решения
Это два разных показателя, и их часто путают.
- Время реакции (response time) — сколько проходит от вашего обращения до того, как специалист подтвердил, что взял задачу в работу. Автоответ робота обычно не считается.
- Время решения (resolution time) — сколько проходит до устранения проблемы или до запуска временного обходного решения (workaround).
Обещание «ответим за 15 минут» без срока решения мало что гарантирует: ответить можно быстро, а чинить неделю.
Уровни критичности
Сроки зависят от того, насколько серьёзна проблема. Обычно выделяют три-четыре уровня:
| Уровень | Что это значит | Пример |
|---|---|---|
| Критический | Система недоступна или остановлен ключевой процесс | Не принимаются заказы или платежи |
| Высокий | Важная функция работает с ошибками, обходного пути нет | Не формируются отчёты для бухгалтерии |
| Средний | Проблема есть, но можно работать | Медленно грузится один раздел |
| Низкий | Мелкие недочёты и пожелания | Опечатка в интерфейсе |
Важно, кто определяет уровень. Лучше, если критерии прописаны в договоре, а спорные случаи решаются по понятному правилу, а не по усмотрению одной стороны.
Uptime: доступность системы
Uptime — доля времени, когда система работает. В SLA его указывают в процентах за период, обычно за месяц. Чем больше «девяток», тем меньше допустимого простоя и тем дороже инфраструктура и дежурства.
На что смотреть:
- Как считается доступность и кто её измеряет — внешний мониторинг или логи подрядчика.
- Что исключается: плановые работы, сбои у хостинга или стороннего сервиса, проблемы на стороне заказчика.
- Окна плановых работ: когда они проходят и за сколько вас предупреждают.
Часы поддержки
Уточните, в какое время действуют сроки: круглосуточно, в рабочие часы или по схеме «критические — 24/7, остальные — в рабочее время». И в каком часовом поясе. Срок «4 часа» в режиме рабочего дня может означать ответ только на следующее утро.
Штрафы и компенсации
Обычно это сервисные кредиты — скидка на следующий период поддержки за каждое нарушение или за недостигнутый uptime. Проверьте:
- есть ли верхний предел компенсации;
- нужно ли заказчику самому заявить о нарушении и в какой срок;
- что считается систематическим нарушением и даёт ли оно право расторгнуть договор.
Примеры формулировок, которые стоит искать
Хорошие формулировки конкретны:
- «Время реакции исчисляется с момента регистрации обращения в системе заявок до назначения ответственного специалиста».
- «Для инцидентов критического уровня поддержка оказывается круглосуточно, включая выходные и праздничные дни».
- «Доступность рассчитывается по данным внешнего мониторинга с проверкой не реже одного раза в минуту».
- «О плановых работах Исполнитель уведомляет Заказчика не позднее чем за [N] рабочих дней».
Тревожные формулировки размыты: «в разумные сроки», «по возможности», «оперативно», «приложим все усилия».
Частые ошибки
- Принять SLA без определения уровней критичности.
- Не указать каналы обращения: куда писать ночью, если сломалось всё.
- Не предусмотреть отчётность — ежемесячный отчёт по заявкам и доступности.
- Требовать максимальные показатели для некритичной системы и переплачивать.