Как выбрать SLA с ИТ‑подрядчиком, чтобы не остаться без поддержки в нужный момент

Что такое SLA и почему это не формальность

Проблема в том, что многие компании подписывают договор с ИТ‑подрядчиком, ориентируясь на общее впечатление от переговоров и цену, а раздел SLA пролистывают как техническое приложение.

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

Какие сроки реакции считаются нормальными

Первое, что стоит проверить в SLA: конкретное время реакции на обращение и отдельно время решения проблемы. Это два разных показателя, и подмена одного другим стала частым способом подрядчиков создавать иллюзию высокой скорости работы.

Время реакции: период от момента обращения до подтверждения специалиста, что задача взята в работу.

Для критичных проблем, из‑за которых бизнес полностью останавливается, разумным ориентиром считается реакция в течение 15–30 минут. Время решения, совсем другой показатель, отвечает на вопрос, сколько потребуется, чтобы проблему устранить полностью.

Для серьезных инцидентов адекватный срок обычно составляет от одного до четырех часов, в зависимости от сложности ситуации.

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

Как SLA должен различать критичность проблем

Не все обращения одинаково важны для бизнеса, и грамотный SLA это учитывает через градацию приоритетов.

Обычно выделяют три‑четыре уровня: критичный инцидент, при котором полностью встает работа компании, например падение сервера или отказ доступа к основной учетной системе; высокий приоритет, когда проблема серьезно мешает работе, но не блокирует ее полностью; и низкий приоритет для рутинных задач вроде настройки нового рабочего места или консультации.

Для каждого уровня в договоре должны быть свои сроки реакции и решения. Если в SLA все обращения описаны одной строкой без разделения по приоритету, у подрядчика появляется формальное право заниматься мелкими задачами наравне с критичными, просто в порядке очереди.

Что подрядчики прячут в мелком шрифте

Помимо самих сроков, важно обращать внимание на исключения и оговорки, которые снижают реальную ценность заявленных цифр.

Часто встречающаяся формулировка: «время реакции и решения указано для рабочих часов». Если поддержка работает с 9 до 18 по будням, а сервер падает в субботу ночью, формально подрядчик ничего не нарушает, откладывая решение до понедельника, хотя для бизнеса это может означать двое суток простоя.

Стоит уточнять отдельно, распространяется ли SLA на нерабочее время и выходные, и если да, то на каких условиях.

Еще один момент: расчет доступности инфраструктуры. Если в договоре указано «99% доступности в месяц», это звучит внушительно, но на практике означает почти 7,3 часа возможного простоя ежемесячно, которые формально укладываются в условия договора.

Для критичных для бизнеса систем стоит обсуждать показатели ближе к 99,9%, что сокращает допустимый простой до считаных минут в месяц.

Как проверить SLA на практике, а не только на бумаге

Написанные в договоре цифры мало что значат, если их никто не измеряет. Хороший подрядчик предоставляет доступ к статистике обращений: сколько заявок поступило, сколько уложились в оговоренные сроки, сколько заняло решение в среднем.

Если такой отчетности нет и подрядчик предлагает верить на слово, это повод спросить прямо, почему.

Полезная практика на старте сотрудничества: договориться о пробном периоде с обязательным разбором первых нескольких обращений. Не обязательно дожидаться серьезной аварии: можно намеренно создать некритичную заявку и засечь реальное время реакции, чтобы сравнить его с тем, что прописано на бумаге.

Что делать, если подрядчик нарушает договоренности

Конкретные механизмы обычно включают перерасчет стоимости услуг за период, в течение которого сроки были нарушены, фиксированную компенсацию за простой сверх оговоренного лимита и право компании расторгнуть договор без штрафных санкций при систематических нарушениях.

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

Грамотно составленный SLA не гарантирует, что сбоев не будет вообще. Но он превращает абстрактное обещание «оперативной поддержки» в конкретные цифры, которые можно проверить, потребовать и, если нужно, отстоять.