SLA в договоре ИТ-аутсорсинга: что важно прописать

SLA (Service Level Agreement) — это раздел договора ИТ-аутсорсинга, который отвечает на два главных вопроса: «как быстро вы поможете» и «что будет, если не поможете вовремя». Без SLA обслуживание превращается в помощь «по возможности», а ответственность подрядчика размывается. В этой статье разберём, из каких параметров состоит качественный SLA, какие формулировки реально защищают заказчика, как устроены санкции и что обязательно проверить до подписания договора.

Что такое SLA и почему без него нельзя

Service Level Agreement — соглашение об уровне сервиса. По сути это числовые обязательства подрядчика: за какое время он отреагирует на заявку, за какой срок устранит проблему, в какие часы доступен и какую доступность систем гарантирует. Если в договоре есть только общая фраза «обязуемся оказывать услуги качественно и своевременно», то заказчик остаётся без рычагов: качество и своевременность не измерить, а значит, и предъявить претензию не по чему.

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

Важно понимать, что SLA — это не отдельный документ-декларация, а приложение к договору. Именно связка «состав работ + параметры SLA + санкции» делает договор рабочим. Если вы планируете передать обслуживание ИТ-инфраструктуры на ИТ-аутсорсинг, SLA стоит обсуждать на этапе коммерческого предложения, а не после подписания.

Из каких параметров состоит SLA

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

• Время реакции — интервал от регистрации заявки до первого ответа специалиста (звонок, сообщение, комментарий в тикет-системе). Измеряется в минутах или часах и, как правило, зависит от критичности инцидента.
• Время решения — срок полного устранения проблемы или предоставления обходного решения. Здесь важно уточнить, идёт ли речь о рабочем времени подрядчика или о календарных часах: при аварии в пятницу вечером это принципиальная разница.
• Часы обслуживания — режим работы линии поддержки: 9:00–18:00 по будням, расширенный 8:00–20:00 или круглосуточно 24/7. От этого напрямую зависит цена договора.
• Доступность систем (uptime) — процент времени, в течение которого сервис должен быть работоспособен: например, 99,5% или 99,9%. Для 24/7-критичных сервисов это ключевой показатель.
• Порядок эскалации — что происходит, если инцидент не решается: когда подключается старший инженер, когда — руководитель проекта, в какой момент информируют заказчика.
• Состав обслуживаемых систем — перечень серверов, рабочих мест, баз 1С, сетевого оборудования и программ, на которые распространяется SLA. Без этого пункта стороны будут спорить, входит ли конкретная проблема в договор.
• Отчётность — формат, состав и периодичность отчётов о выполнении SLA, а также методика расчёта метрик.

Хорошая практика — не просто перечислить параметры, а зафиксировать методику их расчёта. Например, считать время реакции от момента регистрации заявки в тикет-системе, а не от момента, когда её «заметили». Иначе метрика теряет смысл.

Уровни критичности и матрица времени

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

Уровень	Описание	Время реакции	Время решения
Критичный (P1)	Полная остановка бизнес-процесса: упал сервер 1С, не работает касса, нет сети во всём офисе	до 30–60 минут	до 2–4 часов
Высокий (P2)	Серьёзное ограничение работы: недоступна часть пользователей, сбой отдельного сервиса	до 1–2 часов	до 8 рабочих часов
Средний (P3)	Некритичный сбой, есть обходной путь: проблемы у одного сотрудника, замедление работы	до 4 часов	1–2 рабочих дня
Низкий (P4)	Запросы и плановые задачи: настройка учётной записи, установка ПО, консультация	до 8 рабочих часов	по согласованию, 3–5 рабочих дней

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

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

Санкции: как прописать штрафы и бонусы

Санкции — это то, что превращает SLA из декларации в рабочий инструмент. Без них параметры обслуживания остаются пожеланием. В практике ИТ-аутсорсинга используют несколько моделей ответственности.

• Сервис-кредит (скидка). За каждый факт нарушения или за снижение достигнутого уровня сервиса начисляется скидка на следующий период. Например, нарушение времени реакции по критичному инциденту — скидка 5% от ежемесячного платежа, по некритичному — 2%.
• Бонусные часы. Вместо денег подрядчик предоставляет бесплатные часы работ сверх договора. Удобно, когда нарушение не привело к прямым убыткам, но доставило неудобства.
• Фиксированный штраф. Конкретная сумма за конкретное нарушение. Подходит для разовых событий, но требует честной методики учёта.
• Право на расторжение. При систематическом нарушении — например, три критичных инцидента с нарушением времени реакции в течение месяца — заказчик вправе расторгнуть договор без штрафных санкций со своей стороны.

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

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

Сценарии «а если…»: формулировки, которые защищают

Большинство конфликтов вокруг SLA возникает не из-за злого умысла, а из-за ситуаций, которые не были прописаны заранее. Пройдитесь по сценариям ниже и проверьте, есть ли на них ответ в вашем договоре.

1. «А если авария ночью или в выходной?» — Договор должен чётко разделять стандартные часы и расширенный режим. Если 24/7 вам нужно, это должно быть прописано отдельной строкой с отдельной ценой.
2. «А если упал не наш сервер, а провайдер или облако?» — Сформулируйте, что считается «вне зоны ответственности» подрядчика: сбои интернет-провайдера, отключение электричества, аварии у внешних вендоров. При этом подрядчик обязан зафиксировать факт и помочь с взаимодействием с третьей стороной.
3. «А если подрядчик не отвечает на заявку?» — Определите контрольную точку: если реакции нет дольше N часов, заявка автоматически эскалируется руководителю проекта, а заказчик получает уведомление.
4. «А если заявка зарегистрирована, но её „взяли в работу“ формально?» — Разделите время реакции (первый отклик) и время решения (закрытие). Иначе подрядчик может ставить «принято», а проблему не решать неделями.
5. «А если мы хотим сменить подрядчика?» — Пропишите порядок выхода: передача доступов, документации, паролей и архивов заявок в течение фиксированного срока, например 10 рабочих дней, без блокировки со стороны исполнителя.
6. «А если инцидент длится больше суток?» — Для затяжных аварий задайте ритм информирования: промежуточный статус каждые 2 часа, план восстановления и прогноз сроков. Тишина во время аварии хуже самой аварии.

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

Пункты, которые чаще всего забывают

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

1. Плановые работы. Обновления, профилактика, перезагрузка серверов — входят ли они в SLA и как согласуются окна обслуживания? Если обновление 1С «упало» в рабочее время и остановило бухгалтерию, кто отвечает?
2. Резервное копирование. SLA должен описывать не только «починить», но и «не потерять данные»: регламент бэкапов, периодичность, проверку восстановимости и целевое время восстановления (RTO/RPO).
3. Передача доступов. Кто владеет учётными записями, как хранятся пароли, что происходит при смене подрядчика. Доступы должны оставаться у заказчика или передаваться по акту — иначе вы рискуете оказаться в заложниках.
4. Состав обслуживаемых систем. Конкретный перечень: сколько серверов, сколько рабочих мест, какие базы 1С, какое сетевое оборудование. Без списка любой новый сервис превращается в предмет торга.
5. Неустранимые причины и форс-мажор. Что считается невыполнением SLA, а что — объективным форс-мажором (отключение электричества, авария у провайдера, действия вендора). И как это фиксируется документально.
6. Методика замера метрик. По каким данным считается время реакции: по таймстампам тикет-системы, по журналу звонков или «по факту». Источник данных должен быть один и понятный обеим сторонам.
7. Порядок изменения SLA. Инфраструктура растёт, требования меняются. Пропишите, как пересматривается SLA: по итогам квартала, по заявке заказчика, с пересчётом стоимости.

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

Отчётность и прозрачность работы подрядчика

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

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

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

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

Чек-лист вопросов перед подписанием

Соберите ответы на эти вопросы до того, как поставить подпись. Если хотя бы часть остаётся без чёткого ответа — договор стоит доработать.

1. Какое время реакции и решения установлено для каждого уровня критичности, и в рабочих или календарных часах оно считается?
2. Какой режим обслуживания входит в цену: 9:00–18:00, расширенный или 24/7? Сколько стоит расширение?
3. Как фиксируется момент поступления заявки и кто присваивает ей приоритет?
4. Какие системы и оборудование входят в состав обслуживания, а какие нет?
5. Как устроена эскалация: кто, когда и каким способом подключается к нерешённому инциденту?
6. Какие санкции предусмотрены за нарушение и по каким данным они считаются?
7. Что входит в ежемесячный отчёт и в каком виде он предоставляется?
8. Как оформлен порядок выхода из договора и передачи доступов при смене подрядчика?
9. Как учитываются плановые работы, обновления и резервное копирование?
10. При каких условиях договор можно расторгнуть в одностороннем порядке?

Мы описываем SLA и состав работ в договоре на обслуживание — подробнее в разделе ИТ-аутсорсинг. Задать вопросы по условиям и запросить пример договора можно через контакты.

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