Договор ИТ-аутсорсинга без SLA — это оплата за обещания вместо результата. «Реагируем быстро», «поддержка 24/7», «всё под контролем» — пока нет конкретных цифр, эти формулировки не стоят бумаги, на которой написаны. Если подрядчик не готов зафиксировать время реакции, uptime и штрафы за нарушение — он не готов нести ответственность.

В этой статье — 7 пунктов, которые должны быть в каждом SLA, реальные примеры метрик по пяти направлениям ИТ-обслуживания, красные флаги в договорах и чеклист из 15 пунктов для проверки перед подписанием. Всё из практики IT For Prof — мы включаем SLA в каждый договор ИТ-аутсорсинга и публикуем метрики, потому что не боимся проверки.

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

Без SLA договор ИТ-аутсорсинга превращается в договор на «мы постараемся». Три проблемы, которые возникают:

• Нет ответственности. Сервер лежит 8 часов — подрядчик говорит «мы работали над проблемой». Без зафиксированного времени восстановления невозможно предъявить претензию.
• Нет предсказуемости. Заявки решаются «по мере возможности» — это может быть 15 минут или 3 дня. Бизнес не может планировать, если не знает, когда инфраструктура вернётся в строй.
• Нет инструмента для расторжения. Если SLA не прописан — формально подрядчик ничего не нарушает. Расторгнуть договор по причине «плохой сервис» без измеримых критериев — юридически сложно.

Договор ИТ-аутсорсинга с SLA превращает абстрактные обещания в конкретные обязательства с финансовыми последствиями за невыполнение.

1. Время реакции по приоритетам

Инциденты не равны между собой. Упавший сервер с 1С, на котором работают 50 человек, — не то же самое, что запрос на создание почтового ящика. В SLA должна быть таблица приоритетов:

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

«Время реакции» — это не время решения. Реакция = подрядчик принял заявку и приступил к диагностике. Время решения (восстановления) — отдельный параметр.

2. Время восстановления сервиса

Сколько часов допустимо на полное восстановление работоспособности после инцидента. Для P1-инцидентов обычный ориентир — 4 часа. Для P2 — 8 часов. Для P3 — 3 рабочих дня.

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

3. Гарантированная доступность (uptime)

Процент времени, в течение которого сервис доступен. Разница между цифрами неочевидна, но критична:

99% uptime звучит хорошо — пока не посчитаешь, что это почти четверо суток простоя в год — более 10 рабочих дней. Для серверной инфраструктуры стандарт — 99.9%. Для корпоративного мессенджера допустимо 99.5%.

Как измерять uptime: в SLA должен быть зафиксирован способ измерения — внешний мониторинг (Zabbix, UptimeRobot) или данные провайдера. Без согласованной методики стороны будут спорить о том, было ли нарушение. Плановое обслуживание обычно исключается из расчёта uptime, но только если проведено в согласованное окно обслуживания и с предварительным уведомлением.

4. Перечень обслуживаемого оборудования и ПО

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

Что фиксировать: hostname, IP-адрес, роль (почтовый сервер, контроллер домена, файловый сервер), операционная система, критичность (высокая/средняя/низкая). При добавлении нового оборудования — дополнительное соглашение.

Чтобы инвентаризацию не составлять вручную — используйте сканирование сети. IVRE за один запуск покажет все хосты в сети, открытые порты, версии ОС и сервисов — готовая база для приложения к договору.

5. Регламент обновлений и резервного копирования

Два вопроса, которые должны быть закрыты:

• Обновления безопасности: в какой срок устанавливаются критические патчи? Стандарт — до 72 часов для критических уязвимостей (для активно эксплуатируемых — до 24 часов), 30 дней для остальных. Без регламента подрядчик может откладывать обновления месяцами.
• Резервное копирование: частота (ежедневно), правило хранения (3-2-1: три копии, два типа носителей, одна удалённая), RPO (максимально допустимая потеря данных — обычно 24 часа), RTO (время восстановления из бэкапа — 4 часа для критических систем). Обязательно: тестирование восстановления не реже раза в квартал.

6. Ответственность сторон при нарушении SLA

SLA без штрафных санкций — декларация о намерениях, не обязательство. Стандартная схема компенсаций:

• Превышение времени реакции P1 более чем на 1 час — компенсация 5% месячного платежа за каждый час сверх нормы
• Uptime ниже гарантированного — компенсация пропорционально простою
• Потеря данных из-за отсутствия бэкапа — полная компенсация стоимости восстановления
• Максимальная компенсация за месяц — от 20-30% (рыночный стандарт) до 100% месячного платежа (подрядчик, уверенный в качестве, согласится на повышенный потолок)

Штрафы должны быть симметричными: не только для исполнителя, но и для заказчика (например, за непредоставление доступа к оборудованию, задержку согласований).

7. Эскалация и отчётность

Кому звонить, когда первая линия не справляется? Матрица эскалации:

• 0-15 минут: заявка принята инженером первой линии
• 15-60 минут: если не решено — эскалация на старшего инженера, уведомление менеджера
• 1-4 часа: подключение руководителя направления
• 4+ часов: уведомление руководства обеих сторон

Отчётность: ежемесячный отчёт с количеством инцидентов по приоритетам, фактическим временем реакции и восстановления, процентом uptime за период. Для клиентов с мониторингом на базе Zabbix — доступ к дашборду в реальном времени.

Абстрактные метрики обретают смысл, когда привязаны к конкретным сервисам. Вот как SLA работает для пяти направлений ИТ-аутсорсинга.

Серверная инфраструктура

Администрирование серверов — ядро ИТ-аутсорсинга. Типичный SLA:

• Uptime: 99.9% (не более 43 минут простоя в месяц)
• Реакция на P1: 15 минут, восстановление: 4 часа
• Бэкапы: ежедневно по правилу 3-2-1, тест восстановления ежеквартально
• Обновления безопасности: критические — 72 часа, остальные — 30 дней
• Мониторинг: CPU, RAM, диск, сеть — пороги оповещения настроены индивидуально

Корпоративная почта

Почтовый сервер — сервис, простой которого заметен мгновенно. SLA фокусируется на доставляемости:

• Uptime почтового сервера: 99.9%
• Доставляемость: ≥98% писем доходят без попадания в спам
• Время устранения проблем с доставкой: до 4 часов
• Мониторинг SPF/DKIM/DMARC: автоматический, оповещение при отклонении
• Бэкап почтовых ящиков: ежедневный, хранение 30 дней

Мониторинг

Мониторинг сам по себе является инструментом контроля SLA. Его собственные метрики:

• Время обнаружения инцидента: до 5 минут (проверки каждые 60 секунд)
• Оповещение: SMS + Telegram + email в течение 1 минуты
• Покрытие: CPU, RAM, диск, сеть, SSL-сертификаты, доступность HTTP/HTTPS
• Ложные срабатывания: не более 2% от общего числа алертов

Удалённые рабочие столы

Для удалённых рабочих столов критична непрерывность доступа:

• Доступность терминальных серверов: 99.5%
• Время подключения: до 30 секунд
• Реакция на невозможность подключения: до 15 минут
• Плановое обслуживание: ночь выходного дня, уведомление за 48 часов

Корпоративный мессенджер

Для корпоративного мессенджера на базе Matrix/Element:

• Uptime: 99.5% (не более 3 часов 39 минут простоя в месяц)
• Доставка сообщений: до 3 секунд внутри сервера
• Восстановление после сбоя: до 2 часов
• Бэкап переписки: ежедневный, зашифрованный, хранение 90 дней

Пять формулировок в договоре ИТ-аутсорсинга, которые должны насторожить:

• «Реакция в разумные сроки» — без конкретных цифр. Разумные сроки для подрядчика и для бизнеса, у которого стоит 1С, — разные вещи. Всегда требуйте цифру: 15 минут, 2 часа, 8 часов.
• «Услуги оказываются по мере возможности» — означает «когда нам удобно». Это не SLA, а отказ от обязательств. Если подрядчик не готов гарантировать сроки — он не уверен в своих процессах.
• Штрафы только для заказчика — в договоре прописаны пени за просрочку оплаты, но нет компенсации за нарушение SLA. Договор должен быть симметричным.
• Нет раздела про передачу дел — при расторжении подрядчик не обязан передавать пароли, документацию и доступы. Заказчик становится заложником. Передача дел с 30-дневным параллельным периодом — обязательный пункт.
• «Стоимость дополнительных работ определяется по согласованию» — без прейскуранта. Нужен прайс-лист на типовые работы за рамками SLA или хотя бы потолок стоимости часа работ.

1. Время реакции по приоритетам — P1/P2/P3 с конкретными цифрами в минутах/часах
2. Время восстановления сервиса — отдельно от времени реакции, для каждого приоритета
3. Uptime — процент с расшифровкой допустимого простоя в часах
4. Перечень оборудования и ПО — точный список с hostname и IP, не «серверы заказчика»
5. Регламент обновлений — сроки установки критических патчей и плановых обновлений
6. Регламент бэкапов — частота, правило хранения, RPO, RTO, периодичность тестов
7. Штрафные санкции — компенсации за нарушение каждого пункта SLA
8. Матрица эскалации — кто, кому, через сколько, контакты
9. Режим поддержки — 8×5, 12×5, 24×7 с указанием часового пояса
10. Передача дел при расторжении — пароли, документация, схемы, параллельный период
11. NDA и 152-ФЗ — обработка персональных данных, конфиденциальность
12. Отчётность — перечень отчётов, периодичность, формат
13. Масштабирование — порядок добавления/удаления оборудования и пользователей
14. Плановые работы — окна обслуживания, срок уведомления, учёт в uptime
15. Форс-мажор — что считается, как влияет на SLA-обязательства

Если в вашем текущем договоре ИТ-аутсорсинга отсутствуют три и более пунктов из этого списка — договор защищает подрядчика, не вас.

Три сценария и план действий для каждого:

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

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

SLA есть, но в нём нет конкретных метрик

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

SLA нет вообще

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

Ответы на часто задаваемые вопросы по теме статьи.