SLA в ИТ-поддержке часто воспринимают как формальный документ, который нужен только для подписания договора. На практике ситуация обратная: именно SLA определяет, насколько предсказуемо и эффективно будет работать поддержка. Если документ составлен поверхностно, любая проблема превращается в затяжной спор между заказчиком и подрядчиком. Если SLA проработан грамотно — процессы становятся прозрачными, а инциденты решаются по понятным правилам.
Что такое SLA
SLA (Service Level Agreement) — это соглашение об уровне сервиса, в котором фиксируются условия оказания ИТ-услуг: сроки реакции, параметры качества, правила обработки инцидентов и ответственность сторон.
Главная задача SLA — убрать неопределенность. Без четких договоренностей заказчик ожидает максимально быстрого решения, а подрядчик трактует сроки и приоритеты по-своему. В результате появляются претензии, конфликты и постоянные обсуждения того, кто и что должен был сделать.
Почему большинство SLA не работают
Основная проблема — размытые формулировки. Фразы вроде «оперативная поддержка» или «быстрое устранение неисправностей» выглядят убедительно только на бумаге. На практике они ничего не измеряют.
Рабочий SLA всегда строится на конкретных показателях: времени реакции, сроках решения, уровнях приоритета и правилах эскалации. Если метрики нельзя проверить, значит контролировать качество поддержки тоже невозможно.
Что обязательно должно быть в SLA
Первое, с чего начинается любой SLA, — система приоритизации инцидентов. Важно оценивать не саму проблему, а ее влияние на бизнес. Остановка ключевой системы и локальная ошибка у одного сотрудника не могут обрабатываться одинаково.
Обычно инциденты делят на несколько уровней: критические, высокие, средние и низкие. Для каждого уровня отдельно задаются сроки реакции и устранения. Без этого любая приоритизация становится субъективной.
Следующий важный параметр — время реакции. Это интервал между регистрацией обращения и фактическим началом работы специалиста. Многие подрядчики считают реакцией обычный ответ на письмо, хотя реальная работа еще не началась. Поэтому в SLA необходимо четко определить, что именно считается реакцией.
Не менее важен показатель Resolution Time — время решения инцидента. Здесь важно фиксировать не только целевые сроки, но и условия, при которых SLA может быть приостановлен. Например, если подрядчик ожидает доступы или информацию от заказчика.
Также стоит разделять временное восстановление сервиса и полное устранение причины проблемы. Без этого стороны часто по-разному оценивают момент закрытия инцидента.
Отдельный раздел SLA должен описывать каналы обращения. Поддержка не может строиться на сообщениях в мессенджерах или устных запросах. Все обращения должны фиксироваться через определенные каналы: Service Desk, email, телефон или портал поддержки. Это необходимо для учета, контроля сроков и формирования отчетности.
Еще один критически важный блок — график оказания поддержки. SLA должен однозначно отвечать на вопрос, когда именно подрядчик обязан реагировать на инциденты. Это может быть стандартный режим 8×5 или круглосуточная поддержка 24×7. При этом необходимо учитывать различия между рабочим и нерабочим временем, а также наличие дежурной смены для критических ситуаций.
Эскалация и контроль
Во многих компаниях инциденты затягиваются не из-за сложности проблемы, а из-за отсутствия понятной процедуры эскалации. Если заявка слишком долго остается на одном уровне поддержки, она должна автоматически передаваться старшему специалисту или другой команде.
В SLA обычно фиксируют условия эскалации, сроки подключения следующего уровня и ответственных сотрудников. Это позволяет избежать ситуаций, когда проблема «теряется» внутри процесса.
Не менее важна отчетность. SLA без измерений фактически не существует. Для контроля качества обычно используют показатели соблюдения SLA, среднее время реакции, среднее время решения и статистику по инцидентам разных приоритетов.
Регулярная отчетность помогает не только контролировать подрядчика, но и видеть слабые места инфраструктуры.
Ответственность сторон
Одна из самых частых ошибок — SLA, в котором обязанности есть только у подрядчика. На практике выполнение SLA зависит от обеих сторон.
Подрядчик отвечает за соблюдение сроков, качество поддержки и ведение отчетности. Заказчик обязан предоставлять доступы, назначать ответственных сотрудников и соблюдать правила подачи заявок. Если эти обязанности не зафиксированы, SLA быстро становится формальностью.
Также важно заранее определить исключения: форс-мажор, проблемы внешних провайдеров, плановые работы и действия третьих сторон. Без таких оговорок почти любой сложный инцидент становится причиной конфликта.
Почему важно учитывать запросы на изменения
Во многих SLA подробно описаны только инциденты, но полностью отсутствуют service requests — запросы на обслуживание и изменения. Хотя именно такие задачи часто занимают значительную часть работы поддержки.
Установка программ, настройка доступов, изменение конфигураций и доработка систем тоже должны иметь понятные сроки и правила обработки. Иначе этот поток задач быстро выходит из-под контроля.
Как понять, что SLA действительно работает
Рабочий SLA легко определить по нескольким признакам. Инциденты обрабатываются предсказуемо, критические проблемы решаются в согласованные сроки, а между заказчиком и подрядчиком практически не возникает споров о зоне ответственности.
Если каждая проблема сопровождается конфликтами и обсуждением базовых правил работы, значит SLA либо составлен неправильно, либо фактически не используется.
SLA — это не приложение к договору и не формальность для тендера. Это инструмент управления ИТ-поддержкой, который определяет скорость реакции, прозрачность процессов и уровень ответственности сторон.
Грамотно выстроенный SLA снижает простои, делает поддержку управляемой и помогает бизнесу быстрее восстанавливать работу сервисов. Поверхностный SLA, наоборот, создает только иллюзию контроля и не решает ни одной реальной проблемы.