Как проверить SLA компании по IT-обслуживанию: 7 критических показателей времени реакции и восстановления

Типовой SLA в договорах на IT-аутсорс часто является декларативным документом, который не работает в критической ситуации. Реальная разница между «качественным сервисом» и «имитацией поддержки» кроется в разрыве между временем реакции (Response Time) и временем восстановления (Resolution Time), который в недобросовестных компаниях может достигать 48 часов при заявленных 4 часах.

Response Time vs Resolution Time: ловушка определений

Главная ошибка клиента — путать время реакции с временем решения проблемы. Response Time — это всего лишь подтверждение получения заявки («Мы увидели ваш тикет»), что может занимать от 15 до 60 минут. Resolution Time — это фактическое устранение аварии. Если в SLA указано «Реакция 30 минут», но нет жесткого срока восстановления, бизнес может стоять сутки, пока инженер «анализирует проблему».

Кейс: В компании на 20 рабочих мест упал сервер 1С. Подрядчик отреагировал за 15 минут (отправил e-mail), но сервер подняли через 8 часов. Формально SLA по реакции соблюден, фактически — компания потеряла рабочий день. Экспертный вывод: Требуйте фиксации Resolution Time для каждой категории инцидентов, иначе Response Time бесполезен.

Критичность инцидентов: градация и нормативные сроки

Профессиональный SLA делит проблемы на уровни (Priority). Для МСБ нормами считаются следующие показатели: Критический (P1 — остановка бизнеса, например, падение сервера) — восстановление за 2–4 часа; Высокий (P2 — работа одного отдела нарушена) — до 8 часов; Средний (P3 — единичные сбои) — до 24–48 часов. Если подрядчик предлагает единый срок для всех заявок («все исправим за 24 часа»), он либо не понимает специфику вашего бизнеса, либо перегружен.

Пример: При падении основного шлюза интернета время восстановления более 4 часов для офиса из 15 человек ведет к прямым убыткам в размере одного рабочего дня ФОТ (в среднем 15 000 – 40 000 руб. за день простоя). Экспертный вывод: Оптимальный вариант — жесткий лимит 4 часа для P1 и 8 часов для P2, всё остальное вторично.

Регламент выездной поддержки и время прибытия

Удаленная поддержка решает до 80% проблем, но оставшиеся 20% требуют физического присутствия. Важно различать время реакции на заявку и время прибытия инженера в офис. В Москве и крупных городах нормой считается прибытие специалиста в течение 2–4 часов для критических инцидентов. Если срок выезда составляет более 6 часов, риск простоя инфраструктуры становится неприемлемым.

Нюанс: Проверьте, входит ли время дороги в SLA или оно считается «после принятия заявки в работу». Правильный регламент выездной поддержки должен четко определять точку отсчета. Экспертный вывод: Для бизнеса с физическим документооборотом или локальными серверами выбирайте подрядчика с гарантированным выездом до 4 часов.

Доступность сервисов (Uptime) и штрафные санкции

Показатель Uptime для серверов и сети должен быть не ниже 99,7% (допустимый простой — около 2 часов в месяц). Если подрядчик обещает «100% доступности» — это ложь, так как даже оборудование Enterprise-класса имеет окна обслуживания или риск отказа. Реальный контроль качества осуществляется через финансовые штрафы: снижение абонентской платы на 5–10% за каждое нарушение SLA по критическим инцидентам.

Мини-кейс: Клиент внедрил штраф 2000 руб. за каждый час простоя сервера сверх SLA. Результат: время восстановления сократилось с 6 до 3 часов за два месяца, так как компания-подрядчик пересмотрела приоритеты своих инженеров. Экспертный вывод: SLA без штрафных санкций — это просто пожелание, а не обязательство.

Контроль через KPI и отчетность

Объективная оценка работы невозможна без ежемесячного отчета, где зафиксированы: количество тикетов, среднее время закрытия и процент соблюдения SLA. Если вам присылают отчет в духе «Все работало стабильно», вы не видите реальной картины. Требуйте выгрузку из системы тикетов (Help Desk) с указанием точного времени создания и закрытия каждой задачи.

Статистика: В компаниях, где внедрены KPI для оценки эффективности IT-компании, стоимость владения инфраструктурой (TCO) снижается на 15–20% за год за счет устранения повторяющихся ошибок. Экспертный вывод: Отсутствие прозрачной отчетности по времени реакции — главный признак того, что подрядчик скрывает низкое качество сервиса.

Вывод

Чтобы IT-обслуживание не стало статьей бессмысленных расходов, откажитесь от «гибких» договоров в пользу жесткого SLA. Начинайте с аудита текущего состояния, затем фиксируйте Resolution Time (не Response!) с разбивкой по приоритетам P1–P3 и внедряйте систему штрафов за простой. Избегайте компаний, которые не используют Help Desk-систему для логирования времени — без цифр вы не сможете доказать нарушение обязательств и будете зависеть от настроения инженера.