SLA в IT-аутсорсинге: что должно быть в договоре и какие пункты — красные флаги

Service Level Agreement — соглашение об уровне сервиса. На бумаге у всех подрядчиков есть «SLA 99,9%», на практике этот пункт работает только в одном из трёх договоров. Ниже — что отличает работающий SLA от декларативного, как читать его до подписания и какие пункты делают любые цифры бесполезными.

Зачем нужен SLA и почему он часто декларативен

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

Декларативным SLA становится, когда в нём:

• цифры не привязаны к конкретным сервисам;
• нет описания методики измерения;
• отсутствует финансовая ответственность за нарушение;
• не определён порядок эскалации;
• категория «форс-мажор» сформулирована так, что под неё попадает почти всё.

Такой SLA — это страница в договоре, которая ни на что не влияет. Удалить её — ничего не изменится.

Uptime в часах: таблица 99% / 99,9% / 99,99% / 99,999%

Перевод процентов в часы простоя — первое, что нужно сделать при чтении SLA.

Разница между 99,9% и 99,99% — это 7 часов 54 минуты простоя в год. Для торговой компании с онлайн-каналом это разница между «один рабочий день потерь» и «час неудобств».

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

Ключевые термины: MTTR, RTO, RPO, MTBF

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

MTTR (Mean Time To Repair) — среднее время восстановления после инцидента. От момента подтверждения инцидента до момента возврата сервиса в норму. Нормальный показатель для корпоративной инфраструктуры — не более 4 часов по основным сервисам, не более 1 часа по критическим. Если в договоре MTTR не указан или указан «в разумные сроки» — это пожелание, не SLA.

RTO (Recovery Time Objective) — целевое максимальное время восстановления конкретного сервиса. RTO задаётся бизнесом: насколько долго мы готовы жить без этого сервиса? Для CRM торговой компании RTO может быть 1 час. Для архивной системы — 8 часов или сутки. RTO должен быть прописан по каждому критичному сервису отдельно, а не одной строкой «по всей инфраструктуре».

RPO (Recovery Point Objective) — допустимая потеря данных в случае инцидента. Если RPO = 1 час, значит резервные копии делаются хотя бы раз в час, и при катастрофе мы потеряем максимум час работы. RPO нужен в SLA для систем хранения и баз данных.

MTBF (Mean Time Between Failures) — среднее время между сбоями. Метрика производителей оборудования и иногда сервисов. В обслуживании используется реже, но иногда фигурирует в маркетинговых материалах.

Что должно быть в SLA, чтобы он работал

Восемь пунктов, без которых SLA — формальность.

1. Перечень сервисов и приоритетов. Конкретный список с указанием уровня критичности. Не «инфраструктура», а «почтовый сервер, CRM, файловое хранилище, корпоративный портал — критичность 1; принтеры, гостевой Wi-Fi — критичность 3».

2. Метрики по каждому сервису. Uptime, MTTR, RTO, RPO — для каждого сервиса свои значения, согласованные с бизнес-требованиями.

3. Методика измерения. Чем измеряется uptime: пингом, HTTP-запросом, проверкой доступности по логике приложения. Кто фиксирует начало и конец инцидента. Как разбираются спорные ситуации (журналы мониторинга, сторонняя система контроля).

4. Время реакции по приоритетам. Сколько времени проходит от регистрации инцидента до начала работ. Обычно — отдельно для P1, P2, P3, P4.

5. Финансовая ответственность. Чёткая формула компенсации за нарушение SLA. Не «приложит все усилия», а «1% от месячной абонентской платы за каждый час простоя сверх SLA, но не более 30%».

6. Порядок эскалации. Кто принимает решение, если инцидент не закрыт в срок. Имена, роли, контакты — со стороны подрядчика и заказчика. Срок эскалации каждого уровня.

7. Исключения из SLA. Что не покрывается: запланированные регламентные работы (с оговоренным окном), форс-мажор (с конкретным закрытым перечнем), изменения, внесённые заказчиком без согласования. Перечень должен быть закрытым.

8. Регулярная отчётность. Подрядчик ежемесячно предоставляет отчёт: количество инцидентов, фактическое значение метрик, нарушения SLA с указанием причин. Без отчётности SLA никто не контролирует.

Финансовая ответственность: как формулировать компенсацию

Стандартные подходы к компенсации.

Вариант 1. Перерасчёт абонентской платы. За каждый час простоя сверх SLA — возврат 1/720 месячной платы (часовая стоимость услуги). Просто, но компенсация символическая.

Вариант 2. Кратный штраф. За каждый час сверх SLA — 2–5 часовых стоимостей услуги. Применяется как стимул для подрядчика. Лимит — обычно 20–30% месячной платы.

Вариант 3. Многоуровневая шкала. Чем дольше нарушение, тем выше ставка компенсации. Например: первые 2 часа — 2x ставка, 2–4 часа — 4x, более 4 часов — 8x. Стимулирует не только реагирование, но и быстрое закрытие инцидента.

Вариант 4. Прямая компенсация убытков. Применяется в крупных договорах. Подрядчик возмещает заказчику документально подтверждённые убытки от простоя в пределах согласованного лимита (обычно — 1–3 месячных абонентских платы).

В большинстве договоров среднего бизнеса работает комбинация: перерасчёт по факту простоя + штрафная компенсация при систематических нарушениях.

Порядок эскалации: имена, роли, контакты

В работающем SLA эскалация описана пошагово.

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

Три красных флага в договоре

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

Красный флаг 1. SLA только для каналов связи, без управляемых сервисов. Часто встречающаяся ситуация: SLA 99,9% есть на канал в интернет, но за работу VPN, почтового сервера, резервного копирования никто формально не отвечает. Если эти сервисы — часть обслуживания, SLA должен покрывать их отдельно.

Красный флаг 2. Нет конкретной формулы компенсации. Формулировки «несёт ответственность в соответствии с законодательством РФ» или «по соглашению сторон» — это отсутствие ответственности. По общему правилу для возврата убытков нужно их доказывать в суде. Без формулы возврат компенсации без судебного разбирательства невозможен.

Красный флаг 3. Нет порядка передачи дел при расторжении. Если в договоре нет пункта «при прекращении сотрудничества подрядчик передаёт заказчику документацию, конфигурации, пароли в течение N дней» — вы в зависимости. Замена подрядчика после такого договора займёт месяцы и обойдётся в дополнительные сотни тысяч рублей.

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

12 пунктов, по которым стоит пройтись с юристом и техническим специалистом до подписания.

1. Перечень сервисов с указанием критичности — есть и согласован.
2. По каждому критичному сервису указан целевой uptime в процентах.
3. По каждому сервису указан MTTR.
4. По системам хранения данных указан RPO.
5. Описана методика измерения метрик.
6. Указано время реакции на инциденты по приоритетам.
7. Финансовая ответственность за нарушение SLA — конкретной формулой.
8. Лимит компенсации указан явно (обычно 20–30% месячной платы).
9. Перечень исключений (форс-мажор, плановые работы) — закрытый.
10. Порядок эскалации с именами и контактами L1–L4 — есть.
11. Подрядчик предоставляет ежемесячный отчёт по SLA.
12. Прописан порядок передачи документации при расторжении.

12 «да» — SLA рабочий. 8–11 — требуется доработка. 7 и менее — переговоры с подрядчиком или поиск альтернативы.

FAQ

Какой uptime реально достижим для среднего офиса? Для офиса с одним каналом и базовым обслуживанием — 99,5–99,8%. С резервным каналом и активным мониторингом — 99,9%. С полным резервированием (двойные каналы, кластер серверов, NOC 24/7) — 99,95–99,99%. Подробнее об инфраструктуре под высокий SLA — в материале «7 ошибок при построении корпоративной сети».

Как считать uptime, если простой произошёл по вине заказчика (например, выключили сервер по ошибке)? Такие случаи относятся к исключениям из SLA. Они должны быть прописаны в договоре отдельным пунктом, чтобы у обеих сторон не было разночтений.

Можно ли получить компенсацию за репутационные убытки или упущенную выгоду? В большинстве договоров — нет, такие убытки явно исключены. Получить можно только прямые документально подтверждённые потери и компенсацию по формуле SLA.

Что считается «началом инцидента»? В рабочем SLA — момент регистрации в системе тикетов или фиксации алерта в мониторинге. Спорные случаи разрешаются по журналам мониторинга, к которым у заказчика есть доступ.

Что важнее — высокий uptime или быстрый MTTR? Зависит от бизнеса. Для систем с непрерывным циклом (онлайн-торговля) важнее uptime. Для систем, где допустим короткий простой (бухгалтерия, документооборот), важнее MTTR. В большинстве случаев в SLA фиксируются обе метрики.

Что делать, если подрядчик систематически нарушает SLA? В рабочем договоре прописано право расторжения по факту систематических нарушений (обычно — 3 нарушения подряд или 5 в течение полугода) с возвратом аванса.

Можно ли договориться о SLA жёстче рыночного? Можно, но это меняет стоимость обслуживания. Каждая «девятка» в uptime после 99,9% удорожает сервис в 1,5–3 раза за счёт необходимого резервирования и сменной работы инженеров.

Что в итоге

Хороший SLA защищает обе стороны: заказчик получает измеримые гарантии и компенсацию при их нарушении, подрядчик — чёткое определение ответственности. Перед подписанием договора попросите подрядчика показать пример реального инцидент-репорта по действующему клиенту (с обезличенными данными). Качество этого документа говорит о зрелости процессов больше, чем любые цифры в презентации. Наш стандартный договор включает SLA 99,99%, MTTR до 4 часов, выезд инженера в течение 2 часов и финансовую ответственность за каждый час сверх норматива. Шаблон высылаем до подписания.

Калькулятор стоимости · Связаться с нами