SLA на поддержку: что должно быть в договоре, чтобы он работал

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

Категории обращений

Основа регламента — классификация. Без неё любое обращение имеет одинаковый приоритет, то есть приоритета нет вообще. Мы используем четыре категории и определяем их через последствия для бизнеса, а не через техническую сложность.

Что ещё должно быть в регламенте

• Часы поддержки: рабочие часы с оговорками про аварии или круглосуточное дежурство отдельной строкой
• Каналы обращения и главный из них: задачи, пришедшие в личные сообщения, теряются
• Кто со стороны заказчика имеет право ставить категорию «авария»
• Порядок эскалации: к кому обращаться, если срок нарушен
• Что не входит в поддержку: новые разделы, редизайн, работы в сторонних системах
• Порядок учёта часов и что происходит с неиспользованными

Пункт про границы важнее, чем кажется. Большинство конфликтов в поддержке возникает не из-за сроков, а из-за разного понимания того, что вообще относится к обслуживанию. «Добавьте, пожалуйста, ещё один отчёт» — это доработка, а не исправление, и лучше договориться об этом заранее.

Как считать соблюдение

Соглашение, которое никто не измеряет, ничего не гарантирует. Учёт должен идти в системе задач, а не в переписке: время поступления, время первого ответа, время закрытия, категория. Из этого раз в месяц собирается отчёт.

select
  t.severity,
  count(*) as total,
  -- Считаем только рабочее время: ночь и выходные
  -- не должны попадать в срок реакции по обычным задачам
  sum(case when t.first_response_minutes <= s.reaction_minutes
           then 1 else 0 end) as in_time,
  round(100.0 * sum(case when t.first_response_minutes <= s.reaction_minutes
                         then 1 else 0 end) / count(*), 1) as percent
from tickets t
join sla_targets s on s.severity = t.severity
where t.created_at >= date_trunc('month', now()) - interval '1 month'
  and t.created_at <  date_trunc('month', now())
group by t.severity, s.reaction_minutes
order by s.reaction_minutes;

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

На что смотреть в чужом договоре

1. 01Есть ли определение аварии и кто его применяет
2. 02Различаются ли время реакции и время решения
3. 03Указаны ли часы поддержки и режим выходных
4. 04Прописан ли доступ к вашим серверам, репозиторию и аккаунтам на вашей стороне
5. 05Что происходит при расторжении: передача кода, документации, паролей
6. 06Есть ли отчётность по соблюдению сроков

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