Короткий ответ: SLA в IT-поддержке должен фиксировать перечень услуг, часы поддержки, приоритеты заявок, сроки реакции и восстановления, правила эскалации, окна плановых работ, исключения и отчетность. Если в документе есть только общая фраза про быстрый ответ, это не рабочий SLA.
Что проверить в первую очередь
| Блок SLA | Что должно быть прописано | Зачем это нужно |
|---|---|---|
| Состав услуг | Пользователи, рабочие места, серверы, сеть, backup, офисные сервисы | Чтобы не спорить, входит ли задача в регулярную поддержку |
| Часы поддержки | Рабочее время, аварийные окна, выходные, праздники | Чтобы ожидания совпадали с реальным режимом команды |
| Приоритеты | Критерии P1-P4 или аналогичная шкала влияния | Чтобы авария всей компании не стояла в одной очереди с мелкой настройкой |
| Реакция | Когда заявка принята и назначен ответственный | Чтобы пользователь видел, что обращение не потерялось |
| Восстановление | Целевой срок обходного решения или возврата сервиса | Чтобы SLA был связан с результатом, а не только с первым ответом |
| Эскалация | Кто подключается при превышении срока или высоком влиянии | Чтобы проблема не зависала на первой линии |
| Отчетность | Заявки, аварии, повторяющиеся причины, просрочки, план действий | Чтобы руководитель видел состояние поддержки, а не только счет |
1. Начните с перечня поддерживаемых услуг
SLA не работает отдельно от состава услуг. В документе должно быть видно, какие системы и задачи входят в регулярную поддержку: рабочие места, почта, серверы, сеть, VPN, резервное копирование, офисная периферия, учетные записи, мониторинг.
Отдельно фиксируются задачи вне SLA: крупные миграции, закупки, внедрения, разработка, перенос 1С, монтаж сети, работы сторонних подрядчиков. Это не значит, что подрядчик ими не занимается. Это значит, что сроки и бюджет для проектных работ согласуются отдельно.
2. Опишите приоритеты через влияние на бизнес
Приоритет должен зависеть не от громкости обращения, а от масштаба влияния. Хорошая шкала понятна пользователям и не требует технического спора в каждом инциденте.
- P1, авария: остановлен критичный сервис или большая часть компании не может работать.
- P2, высокий: затронута важная группа пользователей, филиал или процесс с ограниченным обходным вариантом.
- P3, обычный: проблема одного пользователя или некритичного сервиса, есть временный обход.
- P4, плановый: консультация, настройка, доступ, изменение без срочного влияния.
3. Разделите реакцию и восстановление
Срок реакции показывает, как быстро подрядчик увидел заявку, назначил ответственного и начал разбор. Срок восстановления показывает, когда сервис вернулся в рабочее состояние или появился согласованный обходной вариант.
Если SLA обещает только реакцию, подрядчик может формально отвечать быстро, но проблема останется нерешенной. Если обещан только срок устранения без условий, документ будет нереалистичным: часть аварий зависит от провайдера, оборудования, лицензий или внешнего сервиса.
4. Зафиксируйте эскалацию
В SLA нужно указать, что происходит при превышении срока, повторной аварии или высоком влиянии на бизнес. Эскалация должна включать технического ответственного, менеджера, контакт со стороны клиента и порядок привлечения внешнего поставщика.
Для аварий полезно фиксировать короткий статус: что затронуто, что уже проверено, есть ли обходной путь, когда следующий контрольный апдейт. Это снижает хаос в чатах и помогает руководителю принимать решения.
5. Определите окна плановых работ
Обновления серверов, перезагрузка оборудования, изменение правил firewall, перенос сервисов и тест восстановления нельзя проводить в случайное время. SLA должен отделять аварийные действия от плановых работ и указывать, кто согласует окно обслуживания.
Для малого офиса достаточно простого правила: критичные изменения выполняются вне пиковой нагрузки, с предварительным уведомлением, понятным планом проверки и способом отката.
6. Укажите исключения без мелкого шрифта
Исключения нужны не для ухода от ответственности, а для честного управления ожиданиями. Например, подрядчик не может гарантировать срок восстановления внешнего интернет-канала, если авария у провайдера, но может контролировать обращение, переключение на резерв и коммуникацию.
Хороший SLA прямо разделяет зоны: подрядчик, клиент, провайдер, вендор, облачный сервис, владелец бизнес-приложения. Чем меньше серых зон, тем быстрее решаются инциденты.
Что включить в ежемесячный SLA-отчет
- количество заявок по приоритетам и направлениям;
- аварии и причины, если они подтверждены;
- просрочки реакции или восстановления с объяснением;
- повторяющиеся обращения, которые стоит устранить системно;
- плановые работы и изменения за период;
- состояние backup, мониторинга и критичных сервисов;
- рекомендации на следующий месяц с приоритетом и риском.
Типовые ошибки
- Один срок на все заявки. Так авария сервера и настройка принтера получают одинаковое ожидание.
- Нет границ услуг. В регулярную поддержку начинают попадать проекты, закупки и внешние подрядчики без отдельного согласования.
- Нет восстановления, только реакция. Формально ответ быстрый, но бизнес не понимает, когда сервис вернется.
- Нет отчета. Руководитель видит только отдельные обращения, а не качество процесса.
- Приоритет ставит пользователь. Срочность должна проверяться по влиянию на работу компании.
Итог: рабочий SLA помогает не наказать подрядчика, а управлять поддержкой. В нем должны быть услуги, приоритеты, реакция, восстановление, эскалация, окна работ, исключения и регулярный отчет.