SLA на поддержку информационных систем: какие метрики закладывать в договор

В SLA на техническую поддержку входят пять величин: доступность, время реакции, время восстановления или обходного решения, процент соблюдения нормативов за расчётный период и режим обслуживания. Обязательством любая из них становится только вместе с источником данных и порядком фиксации нарушения. Без этого — декларация. Доступность 99,9% при базе 730 часов в месяц даёт 43,8 минуты простоя, 99,99% — уже 4,4 минуты. Но спорить стороны будут не о процентах. Спорить будут о том, чей журнал считать первоисточником.

Ключевые факты и их основания

Что такое SLA и почему это не то же самое, что договор на поддержку

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

Определение. SLA (Service Level Agreement, соглашение об уровне обслуживания) — документированное соглашение двух и более сторон, определяющее гарантированные значения показателей качества услуги в соответствии с уровнем обслуживания, порядок взаимодействия и ответственность сторон. Приведено по ГОСТ Р 55389-2012 (утв. 27.12.2012).

Норматив. ГОСТ Р 55389-2012 задаёт термины, ГОСТ Р 55390-2012 — базовую структуру и состав: предмет, перечень услуг, показатели качества, порядок контроля, ответственность.

Оговорка, которую пропускает почти вся выдача по теме. Оба стандарта входят в систему национальных стандартов в области качества услуг связи. К сопровождению корпоративных ИС они применимы по аналогии, как источник терминологии. Отдельного ГОСТа на SLA для поддержки информационных систем не существует, так что тезис «SLA обязателен по ГОСТу» — миф, кочующий по статьям и коммерческим предложениям.

Официальный глоссарий ITIL 4 описывает то же понятие как соглашение между поставщиком услуги и клиентом об ожидаемом уровне услуги, но добавляет два смежных уровня: OLA (Operational Level Agreement) — между подразделениями поставщика, и Underpinning Contract (UC) — договор с субподрядчиком.

Простая проверка на прочность: если договор поставщика с ЦОДом даёт реакцию за 8 часов, обещанные вам 4 часа не обеспечены ничем.

Минимальный набор метрик: пять показателей, без которых договор пустой

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

1. Доступность — доля времени работоспособности в процентах за расчётный период.

2. Время реакции — от регистрации обращения до подтверждения приёма и назначения исполнителя.

3. Время восстановления или обходного решения — до возврата сервиса в строй.

4. Процент соблюдения нормативов — доля заявок, закрытых в срок. Встречается 90–95% по каждому приоритету, но это предмет переговоров, а не константа.

5. Режим обслуживания — окно, в котором нормативы вообще тикают.

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

Доступность сервиса: почему спор всегда о том, что не считается

Формула простая: (Общее время − Время простоя) / Общее время × 100%. Сложность не в арифметике, а в определениях — что считать простоем и что общим временем. Пересчёт процентов в минуты при базе 730 часов в месяц (8 760 часов в году ÷ 12):

Шаг от 99,9% к 99,99% режет бюджет простоя примерно в десять раз. За 4,4 минуты инженер не успеет даже принять инцидент — вопрос переходит из плоскости поддержки в архитектуру: резервирование, автопереключение, отсутствие единой точки отказа. Требовать четыре девятки от системы без кластера бессмысленно, сколько бы инженеров ни дежурило.

Показатели SLA по доступности не работают без закрытого перечня исключений. Из расчёта простоя обычно выпадают:

1. плановые работы в согласованном окне;

2. простой по вине заказчика;

3. форс-мажор;

4. отказ внешних сервисов вне зоны ответственности поставщика;

5. ожидание ответа заказчика по заявке.

Расчётный период — отдельный пункт. Пятичасовая авария разрушает месячный норматив 99,9%, но в квартальном окне может уложиться в допуск.

Формулировка для договора (пример). «Плановые работы не учитываются при расчёте доступности при условии уведомления Заказчика не позднее чем за 5 рабочих дней и проведения работ в окне 00:00–06:00 МСК; суммарно не более 8 часов в месяц».

Время реакции и время восстановления: две метрики, которые путают

Реакция — подтверждение того, что обращение принято, классифицировано и передано исполнителю. Восстановление — возврат сервиса в рабочее состояние, в том числе через обходное решение (workaround), если устранение причины требует релиза. В договоре нужны обе.

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

Отраслевая практика, не норматив. Распространённая градация: P1 (критическая ошибка) — реакция 15 минут, восстановление 4 часа; P2 (серьёзная неполадка) — 30 минут и 8 часов; P3 (минорная ошибка) — реакция 4 часа. Это ориентир из типовых договоров, а не требование стандарта. Реальные значения зависят от критичности системы, режима и цены услуги.

MTTR, MTBF, FCR: когда их стоит вносить в договор, а когда нет

Эти три метрики описывают сервис в среднем, и место им в отчётности, а не в основании для санкций. Среднее по выборке смещается структурой заявок: примите десяток простых обращений — и MTTR за месяц красиво просядет, хотя критичная авария чинилась сутки.

На числах. Три сбоя длительностью 1 час, 4 часа и 0,5 часа дают MTTR = (1 + 4 + 0,5) / 3 = 1,83 часа. Если из 1 000 обращений 700 закрыты при первом контакте, FCR = 70%. Разница принципиальная: обязательства считаются по каждой заявке, отчётные показатели SLA — по выборке за период.

Приоритеты инцидентов: как разделить P1–P4, чтобы не спорить в момент аварии

Приоритет определяет влияние на бизнес, а не сложность починки. Опечатка в запросе, из-за которой не проходят платежи, — это P1. Гонка потоков в отчётном модуле для двух аналитиков — P3, при том что чинить её на порядок труднее. Основа — матрица «влияние × срочность»: сколько пользователей и процессов затронуто и как быстро последствия становятся необратимыми.

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

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

Уровни поддержки SLA — вторая ось, которую регулярно путают с приоритетами. Линии (L1 — приём и типовые решения, L2 — диагностика, L3 — код и данные) отвечают на вопрос, кто работает над заявкой. Приоритет — на вопрос, как быстро.

Режим поддержки: 8×5, 24×7 и что происходит в новогодние праздники

Режим обслуживания — окно, в котором идёт отсчёт нормативов. Вне окна счётчик стоит. Разница в цене между 8×5 и 24×7 кратная, отсюда гибридные схемы: круглосуточно только по P1 и только по критичной системе. Вопрос, который SLA на техническую поддержку обязан закрыть явно, звучит так: часы норматива рабочие или календарные.

Пример расчёта. Режим 8×5, окно 09:00–18:00 МСК, понедельник — пятница. Норматив восстановления по P2 — 4 рабочих часа. Обращение зарегистрировано в пятницу 20 февраля 2026 года в 17:30.

• До закрытия окна остаётся 30 минут — израсходовано 0,5 часа из четырёх.

• Суббота и воскресенье вне окна, счётчик стоит.

• Понедельник 23 февраля — нерабочий праздничный день, счётчик стоит.

• Вторник 24 февраля, окно открывается в 09:00, остаётся 3,5 часа.

• Срок истекает во вторник 24 февраля в 12:30.

Календарно проходит 91 час против «четырёх часов» из договора. И норматив при этом не нарушен. В режиме 24×7 срок истёк бы в 21:30 той же пятницы.

Отсюда три пункта, которые прописывают явно:

1. Календарь. По какому производственному календарю считаются рабочие дни и укорачивается ли окно в предпраздничный день. Новогодние каникулы растягивают норматив P3 на полторы недели.

2. Дежурная смена. Кто принимает обращение вне окна и с какого момента стартует отсчёт.

3. Каналы. Заявка в обход согласованного канала не считается зарегистрированной. Звонок инженеру в мессенджер — не заявка.

Ответственность: штрафы, сервисные кредиты и почему они редко работают

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

Пример из практики рынка, не норматив. Встречается ступенчатая шкала сервисных кредитов: при доступности 99,0–99,5% — скидка 10% на следующий месяц обслуживания, при 98,0–99,0% — 20%. Там же попадается «ознакомительный период»: санкции начисляются с третьего месяца оказания услуг, пока команда принимает систему и настраивает мониторинг. Обе конструкции — предмет переговоров, а не отраслевая норма.

Штрафы за нарушение SLA не взыскиваются по одной типовой причине. Документ не отвечает на четыре вопроса:

1. Чей мониторинг источник истины. Расхождение показаний — норма, точки замера разные.

2. Что считается началом простоя.

3. Кто оформляет факт и в какой срок.

4. Что берётся базой суммы.

Формулировка для договора (пример). «Источником данных о доступности Сервиса является система мониторинга Исполнителя. Заказчик вправе вести независимый контроль. При расхождении показаний более чем на 0,1 процентного пункта за расчётный период Стороны проводят совместный разбор в течение 5 рабочих дней; до его завершения нарушение считается неподтверждённым».

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

Когда SLA обязателен, а не желателен

Закона, прямо требующего заключать соглашение об уровне сервиса с ИТ-подрядчиком, в России нет. Обязанность приходит с другой стороны — через требования к надёжности самого заказчика: Положение Банка России № 850-П от 13.01.2025 для кредитных организаций и НФО и Постановление Правительства РФ № 676 от 06.07.2015 (ред. от 18.03.2025) для государственных информационных систем.

Кредитные организации и НФО. Положение Банка России № 850-П от 13.01.2025 устанавливает требования к операционной надёжности, реализовать их нужно с 1 октября 2025 года. Организация определяет сигнальное и контрольное значения допустимой доли деградации технологического процесса, опираясь на статистику не менее чем за 12 календарных месяцев. Следствие для договора прямое: нормативы поддержки увязываются с этими значениями, а отчётность подрядчика должна давать данные в пригодном для статистики виде. И отдельно — Положение № 787-П от 12.01.2022 утратило силу 03.05.2025, ссылки на него в чужих шаблонах встречаются до сих пор.

Государственные информационные системы. Постановление Правительства РФ № 676 от 06.07.2015 (ред. от 18.03.2025) задаёт требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации ГИС. Обязательства подрядчика проверяют на соответствие ему.

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

Семь ошибок в SLA, которые всплывают на первой же аварии

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

1. Метрика без источника данных. «Доступность 99,9%» без указания, чей мониторинг считается, превращается в спор двух графиков. Нарушение не подтверждается, санкция не начисляется.

2. Реакция вместо решения. Указан только норматив отклика. Формально всё соблюдено, система лежит вторые сутки.

3. Единый норматив на все системы. Кадровый портал и биллинг получают одинаковые 4 часа. Заказчик переплачивает за некритичное, подрядчик закладывает риск в цену.

4. Нет исключений из расчёта доступности. Плановое окно и авария у стороннего оператора идут в общий простой — поставщик отказывается подписывать отчёт.

5. Нет OLA внутри заказчика. Подрядчик трое суток ждёт доступ от службы безопасности, а норматив тикает. Нарушение без вины исполнителя.

6. Нет процедуры изменения документа. Нагрузка выросла втрое, метрики SLA остались от версии двухлетней давности, пересмотр делается в аврале.

7. Штраф без порядка фиксации. Сумма прописана, механизма подтверждения нет. Взыскание не проходит.

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

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

• Системы и модули перечислены поимённо, а не «информационные системы Заказчика».

• Нормативы различаются для систем разной критичности.

• Есть определение доступности с формулой и расчётным периодом.

• Список исключений из расчёта простоя закрытый.

• Назван источник данных и порядок действий при расхождении показаний.

• Время реакции и время восстановления заданы отдельно.

• Критерии P1–P4 описаны через влияние на бизнес; есть срок оспаривания.

• Режим задан явно: окно, часовой пояс, календарь, рабочие или календарные часы.

• Перечислены каналы обращений и указано, какая заявка считается зарегистрированной.

• Механика ответственности связана с порядком фиксации; есть база расчёта суммы.

• Определены состав, формат и срок отчётности.

• Есть процедура пересмотра показателей и порядок выхода из договора.

Частые вопросы об SLA на поддержку

1. Чем SLA отличается от OLA?

   SLA — внешний документ между поставщиком услуги и заказчиком, он же основание для претензии. OLA (Operational Level Agreement) — внутренний, между подразделениями поставщика, например между первой и второй линиями. Оба термина в этом значении определены в глоссарии ITIL 4. Без внутренних сроков внешний норматив в 4 часа не собирается.

2. Время реакции считается в рабочих или календарных часах?

   Так, как записано в документе: в режиме 24×7 обычно в календарных, в 8×5 — в рабочих, внутри согласованного окна. Без такой формулировки спор гарантирован. Обращение в пятницу вечером при нормативе 4 рабочих часа переносит срок на утро понедельника, а при празднике в понедельник — на вторник.

3. Можно ли прописать в SLA время решения любой проблемы?

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

4. Кто фиксирует нарушение SLA — заказчик или подрядчик?

   Тот, кто назван в договоре, и по описанной там процедуре. Рабочая схема: расчёт делает поставщик по итогам расчётного периода, заказчик проверяет и вправе вести независимый контроль. Без названного источника данных и порога допустимого расхождения претензия перспектив почти не имеет.

5. Обязателен ли SLA по российскому законодательству?

   Прямого требования заключать такое соглашение при сопровождении информационных систем нет, и ГОСТ Р 55389-2012 здесь не аргумент — он относится к услугам связи. Обязанность возникает косвенно: Положение Банка России № 850-П от 13.01.2025 требует от кредитных организаций управлять операционной надёжностью, включая процессы у подрядчиков, с реализацией требований с 01.10.2025. Для государственных информационных систем порядок эксплуатации задаёт ПП РФ № 676 от 06.07.2015 (ред. от 18.03.2025).