Договор с IT-аутсорсером: какие SLA прописать, чтобы не остаться без поддержки в аврал

За двенадцать лет в IT-аутсорсинге я видел десятки договоров — и своих, и чужих, которые мне присылали клиенты «на сверку» перед подписанием. Процентов восемьдесят из них написаны так, что в момент реальной аварии владелец бизнеса остаётся один на один с упавшим сервером и вежливым письмом «ваша заявка принята, ожидайте». Расскажу, какие пункты реально спасают, а какие — просто красивые слова для презентации.

«Оперативно решим любые вопросы» — фраза, которая ничего не стоит

Открываю типовой договор небольшого IT-подрядчика. Там написано: «Исполнитель обязуется оперативно реагировать на обращения Заказчика и обеспечивать бесперебойную работу IT-инфраструктуры». Красиво. И абсолютно бесполезно, потому что «оперативно» — не термин, а настроение. Если завтра у вас в пятницу вечером ляжет 1С перед отгрузкой, а подрядчик ответит через три часа, вы не сможете предъявить ему ничего. Формально он же не нарушил договор — там просто нет цифр.

У меня был случай с бухгалтерской фирмой на 18 рабочих мест — не буду называть, но они до нас три года сидели на договоре именно с такой формулировкой. В последний день сдачи отчётности слетел RDP-доступ к терминальному серверу. Заявку подрядчику отправили в 9:40 утра. Ответ пришёл в 15:20. «Оперативно» на языке того подрядчика означало пять с половиной часов. Бухгалтерия сидела без работы весь день, а вечером ещё и штраф от налоговой получила за просрочку.

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

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

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

У нас в «АйТи-Фреш» это выглядит так: критичный инцидент (сервер лёг, 1С недоступна для всех, нет доступа в интернет у всего офиса) — реакция 15 минут, решение или обходной путь — 2 часа. Средний приоритет (не печатает один принтер, тормозит одна рабочая станция) — реакция 2 часа, решение — 8 рабочих часов. Низкий приоритет (установить программу, проконсультировать по Excel) — реакция 4 часа, решение — 2 рабочих дня. Все цифры — в приложении к договору, не в теле самого текста, чтобы их можно было пересматривать без переподписания всего документа.

Отдельно советую прописать, что считается «реакцией»: не автоответ бота из тикет-системы, а именно сообщение живого специалиста с диагнозом или запросом уточнений. Иначе вам будут присылать автоматическое «заявка №4521 принята в обработку» и формально уложатся в SLA, а по факту никто пальцем не пошевелит ещё три часа.

Зоны ответственности — где заканчивается подрядчик и начинается всё остальное

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

В договоре нужен конкретный список: серверное оборудование (какое именно — по инвентарным номерам или хотя бы по типам), рабочие станции, сетевое оборудование, 1С и её обновления, лицензии Windows Server и КриптоПро, резервное копирование через Veeam, антивирус, взаимодействие с провайдером интернета и хостером. И отдельно — что НЕ входит: например, разработка нового функционала в 1С сверх типового, ремонт физически повреждённого железа, восстановление данных при отсутствии бэкапа по вине заказчика.

Я всегда советую клиентам прописывать отдельный пункт про эскалацию к третьим лицам. То есть даже если поломка формально не наша зона — мы обязаны минимум за 30 минут сделать диагностику и подсказать, куда бежать, а не просто отфутболить. Это недорого для подрядчика и критично важно для клиента в моменте аварии.

Как классифицировать инциденты, чтобы не спорить в моменте аврала

Самое неприятное происходит не когда нарушают сроки, а когда во время аврала начинается спор — а это критичный инцидент или нет. У меня был клиент — производственное предприятие в Одинцово, 35 рабочих мест — где старый подрядчик считал критичным только полную остановку сервера. А если тормозила 1С у половины бухгалтерии в день закрытия месяца — это, по их мнению, «средний приоритет», подождёт до завтра. Юридически они правы, потому что критерии критичности нигде не были прописаны.

Правильный подход — заранее, на берегу, прописать таблицу приоритетов с конкретными примерами. У нас четыре уровня. P1 — критичный: недоступна 1С или почта для всей компании, не работает интернет в офисе целиком, взлом или подозрение на шифровальщик. P2 — высокий: не работает подсистема для отдела (например, склад), недоступен сервер для части пользователей. P3 — средний: проблема у одного сотрудника, не блокирующая работу отдела. P4 — низкий: консультации, установка ПО, плановые задачи.

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

Штрафы — и как сделать так, чтобы они реально работали

Штрафные санкции в договоре — это не про то, чтобы наказать подрядчика деньгами, а про то, чтобы у него была мотивация не срывать сроки. Тут тоже есть нюанс: если штраф символический — условные 500 рублей за час просрочки при абонентке в 60 тысяч — подрядчику будет откровенно всё равно, дешевле заплатить, чем нанимать дополнительного инженера в штат на подхват.

Работающая модель, которую я видел у грамотных заказчиков и которую сам предлагаю новым клиентам: за превышение времени реакции по критичному инциденту — фиксированный штраф, например 3-5% от месячной абонентской платы за каждый факт нарушения, но не более определённого потолка в месяц, чтобы не разорить подрядчика на пустом месте и не спровоцировать его на разрыв договора. За превышение времени решения — штраф прогрессивный, растущий с каждым часом простоя, потому что час простоя бухгалтерии в последний день квартала и час простоя в обычный вторник — это две разные истории по деньгам для заказчика.

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

Второй контакт и эскалация — страховка на случай, если сам подрядчик «просел»

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

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

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

Пример из практики: как выглядит авария с хорошим SLA и без него

Расскажу историю без прикрас. Клиент — медицинская клиника на 40 рабочих мест, к нам перешла полтора года назад именно после провала с прежним подрядчиком. У прежних в договоре не было ни времени реакции, ни зон ответственности — просто абонентка 45 тысяч в месяц «за обслуживание». Летом у них упал сервер с базой пациентов в пятницу вечером. Заявку отправили в 18:10. Ответ получили в понедельник в 9 утра. Клиника два рабочих дня работала на бумаге, потеряла часть записей, испортила отношения с постоянными пациентами.

После перехода к нам мы прописали в договоре: критичный инцидент вроде падения сервера с медицинской базой — реакция 15 минут круглосуточно, решение или переключение на резервную копию через Veeam — 4 часа максимум, штраф за превышение — 8% от абонентки за каждый час сверх лимита. В марте этого года у них был похожий сбой — сгорел блок питания на сервере в ночь на субботу. Дежурный инженер отреагировал за 9 минут, поднял виртуальную машину из бэкапа за 2 часа 40 минут, клиника открылась утром в штатном режиме, никто из пациентов вообще не заметил проблему.

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

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

Сколько стоит поддержка с нормальным SLA — это сильно дороже?
Разница между договором с расплывчатыми формулировками и договором с чёткими SLA обычно составляет 15-25% к стоимости абонентки, потому что подрядчику приходится держать резервных инженеров и круглосуточное дежурство. Для компании на 20-40 рабочих мест это чаще всего плюс 8-15 тысяч рублей в месяц — и это несопоставимо дешевле одного дня простоя в аврал.

Можно ли требовать SLA у подрядчика, если у нас всего 5-10 компьютеров?
Можно и нужно, просто пропорции другие — не круглосуточное дежурство, а реакция в рабочие часы за 30-60 минут вместо 15. Маленький бизнес страдает от простоя сервера ничуть не меньше крупного, а часто даже больше, потому что нет запасных людей и процессов на подхвате.

Что делать, если подрядчик отказывается прописывать конкретные штрафы в договоре?
Это тревожный звонок сам по себе — значит, подрядчик изначально не готов брать на себя обязательства и рассчитывает работать «на доверии». Я бы на месте заказчика в такой ситуации либо настоял на цифрах, либо поискал другого подрядчика — рынок IT-аутсорсинга в Москве конкурентный, и адекватные компании соглашаются на конкретику без проблем.

Как проверить, что подрядчик реально соблюдает прописанный SLA, а не просто красиво пишет в договоре?
Просите ежемесячный отчёт по заявкам с фактическим временем реакции и решения по каждой — это должно быть в договоре отдельным пунктом. Нормальные компании ведут такую статистику в тикет-системе и присылают её без проблем; если подрядчик не может показать цифры за прошлый месяц, скорее всего, никакого SLA по факту нет.