SLA с ИТ-аутсорсером: как прописать требования в договоре и не переплатить

За более чем 15 лет в ИТ-аутсорсинге я видел десятки договоров с красивым разделом «SLA», который на практике не значил вообще ничего. Директор подписывает, довольный — вроде бы защитился. А через полгода сервер лежит третий час, бухгалтерия не может закрыть период, а в ответ на претензию подрядчик присылает пункт 4.7, из которого неясно вообще ничего. Расскажу, как я сам формулирую SLA для клиентов «АйТи-Фреш» и что бы я потребовал, если бы сам нанимал подрядчика.

SLA — это не про доверие, это про деньги и нервы

Соглашение об уровне обслуживания придумали не юристы для красоты. Это способ перевести обещания в цифры, которые можно проверить. «Мы быстро реагируем» — не SLA, это маркетинг. «Реакция на критичную заявку не более 30 минут, решение — не более 4 часов, иначе перерасчёт 10% от месячного платежа» — уже SLA, и по нему можно судиться, а можно и просто ткнуть пальцем при следующем звонке.

У меня был клиент — юрфирма на 18 рабочих мест, до нас их обслуживала компания, у которой в договоре было написано «оперативное реагирование на заявки». Всё. Ни цифр, ни разбивки по приоритетам. Когда у них упал терминальный сервер в пятницу вечером, реакция пришла в понедельник утром. Формально подрядчик ничего не нарушил — он же не обещал конкретных сроков. Юристы потом две недели решали, есть ли основания хоть на что-то претендовать. Итог: почти нет.

Время реакции и время решения — это два разных параметра

Вот на чём чаще всего ловят директоров. В договоре пишут одно число — «время реагирования 1 час» — и все довольны. Но реагирование и решение проблемы это совершенно разные вещи. Реагирование — это когда инженер взял заявку в работу, написал «принято, разбираюсь». Решение — это когда 1С снова открывается, а не висит с ошибкой блокировки базы.

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

Поэтому в договоре нужны обе цифры отдельно, и обе — с конкретными часами, а не словами «в кратчайшие сроки» или «максимально оперативно». Для критичной заявки (упал сервер, не работает 1С у всей бухгалтерии, недоступна касса) я прописываю клиентам: реакция — 30 минут, начало работ — 1 час, целевое время устранения — 4 часа в рабочее время. Для некритичной (у одного сотрудника глючит принтер) — реакция 4 часа, решение — до конца следующего рабочего дня.

Без градации приоритетов SLA — пустая бумажка

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

У нас в «АйТи-Фреш» три уровня. Critical — простой критичной инфраструктуры для всей компании или её значительной части: сервер, 1С, интернет-канал, касса, CRM. High — не работает что-то важное у одного человека или группы, но остальные трудятся. Low — косметика, вопросы, консультации, установка софта по запросу. И у каждого уровня свои цифры реакции и решения, прописанные в приложении к договору, а не размыто в теле контракта.

Совет для директора: требуйте, чтобы в договоре было явно написано, кто определяет приоритет заявки. Если это решает сам подрядчик — есть соблазн занижать критичность, чтобы не попадать под жёсткие сроки. У нас право финальной эскалации приоритета — за клиентом, это прописано отдельным пунктом. Обходится дороже для нас, но зато клиент не доказывает через суд, что у него всё-таки был Critical.

Доступность в процентах — красивое число, которое почти ничего не значит без контекста

Все любят писать в SLA «доступность инфраструктуры 99,5%». Звучит солидно. Только 99,5% в месяц — это почти 3,6 часа простоя, который допустим без всяких санкций. А 99,9% — это уже 43 минуты. Для клиники, где касса и МИС должны работать без сбоев в приёмные часы, 3,6 часа простоя за месяц могут означать сорванный день записи и десятки недовольных пациентов.

Ещё важный момент — что именно считается простоем и в какое время. У производственного клиента, который работает в одну смену с 8 до 17, ночной простой сервера для регламентного обслуживания в SLA не считается — мы это прямо прописываем и заранее согласовываем окна. А вот у клиента с работой 24/7 (склад с отгрузками ночью) любая минута простоя учитывается, и цена вопроса совсем другая — соответственно, и тариф обслуживания выше процентов на 30-40.

Мой совет: не гонитесь за красивым числом 99,9%, если у вас типовая офисная инфраструктура на Windows Server и локальном 1С без резервирования каналов. Это число физически недостижимо без второго интернет-провайдера, резервного сервера и ИБП с генератором, а значит либо подрядчик врёт, либо вы платите за инфраструктуру, которая вам не нужна.

«Бесплатные консультации» и другие фразы, за которыми прячется недоделанный SLA

Отдельно хочу предупредить про формулировки-ловушки. «Регулярное обслуживание» без указания частоты — раз в неделю или раз в квартал, решает подрядчик, и обычно решает в пользу минимума. «Резервное копирование выполняется» — без указания, куда, как часто и главное, проверяется ли восстановление из бэкапа. У меня было три случая за карьеру, когда клиенты приходили с историей «бэкапы вроде делались, а восстановиться не смогли» — потому что архивы просто копились на тот же диск, что и рабочие данные, а никто ни разу не пробовал развернуть их обратно.

Требуйте в договоре: частоту бэкапов (для активной бухгалтерской базы 1С — не реже раза в сутки, а лучше каждые 4-6 часов), место хранения (обязательно не там же, где рабочий сервер — у нас это либо Veeam на отдельный NAS, либо облако), и периодичность тестового восстановления — раз в квартал минимум, с актом, что база реально поднялась и открылась.

То же самое с антивирусной защитой и обновлениями безопасности — если в SLA просто «поддержание системы безопасности», это ничего не значит. Пишите конкретно: обновления критичных патчей Windows Server — в течение 5 рабочих дней после выхода, антивирус актуален всегда, отчёт о статусе — ежемесячно клиенту на почту.

Штрафы: как сделать так, чтобы они действительно работали, а не просто красиво звучали

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

Практическая схема, которую я предлагаю клиентам: все заявки идут через тикет-систему с автоматическими таймстампами (у нас это тесно завязано на Planfix), время создания и время закрытия фиксируются системой, а не словами инженера. Раз в месяц клиенту приходит отчёт: сколько заявок, средняя реакция, средний срок решения, сколько случаев вышло за SLA. Если вышло — автоматический перерасчёт, без переговоров и уговоров.

По деньгам: разумная вилка — 5-15% от месячного платежа за каждый случай серьёзного нарушения Critical-заявки, но не более 30-50% от суммы месяца суммарно, иначе подрядчик просто разорится на одном плохом месяце и перестанет вас обслуживать вообще. Штраф должен быть чувствительным, но не убийственным — цель не наказать, а замотивировать не косячить.

Чек-лист: что должно быть в SLA, прежде чем вы подпишете договор

Соберу всё в один список, который можно распечатать и пройтись по нему на переговорах с подрядчиком. Первое — раздельные сроки реакции и решения по каждому приоритету заявок, в часах, не в словах. Второе — кто присваивает приоритет заявке, с правом клиента на эскалацию. Третье — часы покрытия: рабочее время с 9 до 18 или 24/7, и отдельный тариф за работу вне графика.

Четвёртое — конкретика по резервному копированию: частота, место хранения, периодичность тестового восстановления с актом. Пятое — численное значение доступности с указанием, что и как считается простоем, и в какое время суток. Шестое — механизм фиксации нарушений: тикет-система с таймстампами, а не «на слово поверим». Седьмое — размер и механизм штрафа за нарушение, с разумным потолком.

И последнее, самое важное: попросите у подрядчика реальный отчёт по SLA за последние три месяца с любым текущим клиентом (с обезличенными данными, разумеется). Если такого отчёта не существует — значит, метрики никто не считает, и весь красивый раздел договора существует только на бумаге. Мы своим клиентам присылаем такой отчёт каждый месяц уже который год — и, честно скажу, это одна из причин, почему от нас редко уходят: цифры дисциплинируют нас самих не меньше, чем клиента.

Частые вопросы

Сколько стоит нормальный SLA с жёсткими сроками — это сильно дороже обычного обслуживания?
По моему опыту, разница между расплывчатым «оперативным реагированием» и прописанным SLA с приоритетами и штрафами — 15-25% к стоимости абонентского обслуживания. Это цена за то, что подрядчик держит резерв инженеров и следит за метриками, а не просто разгребает заявки по мере сил.

Можно ли требовать SLA от разового мастера или маленькой ИТ-компании из двух человек?
Формально можно прописать что угодно, но по факту если у подрядчика один-два инженера без подмены, ни о каком гарантированном времени реакции 24/7 речи быть не может — заболел человек, и всё встало. Для серьёзного SLA нужна команда минимум из 4-5 инженеров с распределением нагрузки, иначе договор — фикция.

Что делать, если подрядчик отказывается прописывать конкретные цифры и штрафы?
Это тревожный звоночек сам по себе. Если компания уверена в своей работе, ей нечего бояться цифр в договоре — наоборот, это конкурентное преимущество перед теми, кто прячется за общими фразами. Отказ от конкретики почти всегда означает, что метрики нигде не считаются и подрядчик не готов за них отвечать.

Нужен ли отдельный SLA на резервное копирование, если основной SLA уже есть?
Да, обязательно выделяйте бэкапы отдельным блоком, а не растворяйте в общих формулировках про поддержку. Именно бэкапы — та часть, где расплывчатость обходится дороже всего: узнаёте о проблеме не в момент сбоя, а через полгода, когда восстановиться уже не из чего.