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

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

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

Что такое SLA и где он находится

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

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

Рядом с SLA в сервисной практике существуют ещё два документа, и их полезно различать. OLA (operational level agreement) — внутреннее соглашение между подразделениями одного поставщика: служба поддержки, инженеры, дежурная смена. UC (underpinning contract) — договор поставщика с его собственными подрядчиками: оператором связи, производителем оборудования, вендором системы. Логика простая: нормативы в SLA не могут быть жёстче, чем в UC. Если подрядчик обещает восстановить канал связи за два часа, а его договор с оператором даёт четыре, обещание держится на честном слове.

Отраслевая рамка в России — ГОСТ Р ИСО/МЭК 20000-1-2021 «Информационные технологии. Менеджмент сервисов», идентичный международному ISO/IEC 20000-1:2018. Он действует с 30 апреля 2022 года и заменил редакцию 2013 года. Обязательным для коммерческого договора он не является, но на его терминологию опираются и подрядчики, и аудиторы.

Обязательный минимум пунктов, без которых SLA не работает:

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

Область действия: сервисы, а не оборудование

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

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

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

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

Решение

Аудит ИТ-инфраструктуры

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

Классификация обращений: влияние и срочность

Приоритет обращения — основа всех последующих нормативов, и присваивать его «на глаз» нельзя. В сервисной практике приоритет выводится из двух независимых характеристик: влияния (сколько пользователей и процессов затронуто) и срочности (насколько быстро последствия становятся критичными).

Влияние	Высокая срочность	Средняя срочность	Низкая срочность
Сервис недоступен для всей компании или подразделения	Приоритет 1	Приоритет 1	Приоритет 2
Сервис работает с ограничениями, затронута группа пользователей	Приоритет 1	Приоритет 2	Приоритет 3
Затронут один пользователь, обходное решение есть	Приоритет 2	Приоритет 3	Приоритет 4

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

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

Метрики: что именно измеряется

Это ядро документа. Каждая метрика описывается тремя элементами: что считается, по какой формуле, из какого источника берутся данные. Норматив без формулы — это пожелание.

Время реакции и время принятия в работу

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

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

Обходное решение и полное восстановление

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

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

Доступность

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

Доступность	Допустимый простой за месяц	Допустимый простой за год
99%	7 часов 12 минут	около 3,7 суток
99,5%	3 часа 36 минут	около 1,8 суток
99,9%	43 минуты	около 8,8 часа
99,95%	21 минута	около 4,4 часа
99,99%	4 минуты	около 53 минут

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

Доля обращений, закрытых в срок

Отдельная метрика, которая часто отсутствует, хотя именно она описывает массовую поддержку. Норматив по каждому обращению — это обязательство по единичному случаю; доля обращений в срок показывает, выдерживается ли норматив системно.

Здоровая формулировка — не 100%, а целевой процент по каждому приоритету: например, не менее 95% обращений приоритета 1 и не менее 90% приоритета 3, закрытых в пределах норматива, за календарный месяц. Требование «100% обращений в срок» выглядит жёстче, но на практике приводит к тому, что подрядчик начинает управлять статистикой: закрывать обращения досрочно, переоткрывать их новыми номерами, дробить одну проблему на несколько заявок.

Средние значения против перцентилей

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

Правильная формулировка опирается не на среднее, а на долю обращений в пределах норматива — то есть на перцентиль. «Не менее 95% обращений приоритета 2 закрыты в пределах 8 рабочих часов» означает, что хвост ограничен, и из статистики его не спрятать. Если в предложенном SLA метрики заданы средними значениями, это первое, что стоит попросить переписать.

Календарь обслуживания и остановка отсчёта

Нормативы без календаря не считаются. В SLA фиксируется режим покрытия по каждому сервису: 8×5 (рабочие часы рабочих дней), 12×5, 24×7, либо нестандартный график под смены заказчика. Отдельно указываются выходные и праздники, порядок работы в них и ставка за работы вне окна покрытия.

Здесь прячется частая подмена: круглосуточный приём обращений выдаётся за круглосуточное обслуживание. Диспетчер принимает звонок в три часа ночи, регистрирует обращение, а отсчёт норматива начинается в девять утра. Это допустимая схема, если она так и описана, и обман, если в коммерческом предложении написано «поддержка 24×7».

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

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

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

«Правило, которое экономит больше всего споров: остановка таймера считается только с момента, когда подрядчик письменно запросил у заказчика конкретную вещь, и возобновляется в момент её получения. Не „мы ждали ответа", а зафиксированный в системе запрос с временем. Без этого в отчёте за месяц половина просрочек оказывается ожиданием заказчика», — Станислав Гуляев, ведущий технический эксперт ОБИТ.

Как SLA измеряется и кто считает

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

Источник данных

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

Отчёт за период и порядок оспаривания

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

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

Исключения из расчёта

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

Проверять нужно две вещи. Перечень должен быть закрытым, без формулировок «и в иных случаях». И каждое исключение должно требовать подтверждения: авария у оператора связи подтверждается справкой оператора, а не словами инженера подрядчика.

Санкции за нарушение нормативов

SLA без санкций — это описание намерений. Распространённый механизм — снижение абонентской платы за период нарушения, в сервисной практике это называется service credits.

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

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

Типовые дыры: формулировки, которые ничего не значат

Большинство нерабочих SLA составлены не из ошибок, а из формулировок, выглядящих как обязательство. Вот те, что встречаются чаще всего.

Формулировка в SLA	Почему не работает	Рабочая замена
«Реакция на обращение — в кратчайшие сроки»	срок не назван, нарушить нельзя	конкретное время по каждому приоритету и отдельный норматив принятия в работу
«Доступность сервисов — не менее 99,9%» без методики	неизвестно, что такое недоступность, чем подтверждается и что исключается	формула, отчётный период, источник данных и закрытый перечень исключений
«Приоритет обращения определяет исполнитель»	любая авария превращается в рядовой сбой	матрица влияния и срочности, присвоение при регистрации, срок на оспаривание
«Поддержка 24×7» без разделения приёма и обслуживания	ночью обращение регистрируется, а отсчёт идёт с утра	режим покрытия по каждому сервису отдельно от режима приёма обращений
«Время решения — 8 часов» без календаря	непонятно, рабочие это часы или астрономические	привязка к режиму покрытия: «8 рабочих часов в режиме 8×5»
«Отсчёт приостанавливается при ожидании третьих лиц»	открытый список оснований закрывает любую просрочку	закрытый перечень оснований и фиксация остановки в системе с причиной и временем
«Отчёт предоставляется по запросу заказчика»	отчётности фактически нет	форма отчёта, срок предоставления, связь с подписанием акта
«За нарушение исполнитель уплачивает неустойку 0,1% от стоимости услуг»	санкция ниже стоимости нарушения	прогрессивная шкала с потолком и отдельный предел ответственности по критичным сервисам

Порядок пересмотра соглашения

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

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

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

Коротко о главном

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

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