SLA в договоре на ИТ-обслуживание: что это и 7 пунктов, которые защищают компанию от простоя

13 октября 2026, 15:21

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

Руководитель звонит в поддержку, пока работа офиса стоит из-за сбоя

SLA: что это такое и чем он отличается от обычного договора

SLA (расшифровка: Service Level Agreement, на русском соглашение об уровне обслуживания) отвечает на простой вопрос: что исполнитель обещает письменно. Если объяснять простыми словами, обычный договор говорит «мы обслуживаем вашу ИТ-инфраструктуру», а SLA говорит «за сколько минут мы реагируем, за сколько часов возвращаем работу и что вы получите, если мы этого не сделали». По определению IBM, SLA описывает услугу, ожидаемый уровень качества, способ измерения и последствия, если уровень не выдержан. Google в книге Site Reliability Engineering формулирует ещё короче: это договорённость с пользователями, в которой есть последствия за нарушение.

Обычно SLA оформляют разделом договора или приложением к нему. Как управлять уровнем услуг, описывают практики ITIL и международный стандарт ISO 20000 (полное название ISO/IEC 20000), но для собственника важнее не название стандарта, а конкретные цифры в вашем документе. Шаблон из интернета здесь не спасёт: значения придётся подгонять под ваши системы, часы работы и допустимую цену простоя. Типовой образец годится как список вопросов, а не как готовый текст.

Рядом с SLA часто встречается сокращение SLO (в некоторых документах SLT). Так называют целевое значение одного показателя, например «восстановление за четыре часа». SLA собирает такие цели в договор и добавляет последствия за их срыв.

Проверка пунктов SLA в договоре на ИТ-обслуживание перед подписью

7 пунктов SLA в договоре на ИТ-обслуживание, на которые стоит смотреть до подписи

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

Объём услуг: что входит и что нет

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

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

Часы обслуживания и время реакции

Цена простоя выше, чем принято думать, и не только у крупных компаний. По данным, которые приводит опрос ITIC о стоимости часа простоя, затраты на простой высоки и для малого и среднего бизнеса с числом сотрудников от 11 до 200: лишь 4 % респондентов оценили час остановки дешевле 100 000 долларов, причём 93 % из них были микрокомпании до 10 человек. Это оценки самих опрошенных, а не измерения, и для украинской компании цифры будут другими, но направление понятно: час простоя почти всегда дороже, чем кажется.

Сначала зафиксируйте часы. Режим 8×5 означает восемь часов в день пять дней в неделю, 24×7 означает круглосуточно и без выходных, и разница в цене между ними заметная. Если у вас смены, склад или продажи по выходным, режим «по будням с 9 до 18» не подходит, сколько бы реакции ни обещали. Отдельно пропишите праздники и то, как считается начало отсчёта: от момента обращения через портал или телефон, а не от «когда инженер увидел».

Затем пропишите сроки по приоритетам. Нормальная таблица выглядит примерно так (значения условные, это пример, а не норма):

Приоритет

Пример ситуации

Реакция

Восстановление

Критичный

не работает учётная система или интернет во всём офисе

15 минут

4 часа

Высокий

не работает рабочее место сотрудника или принтер отдела

1 час

8 часов

Обычный

вопрос по настройке, новая учётная запись

4 часа

2 рабочих дня

Время восстановления, а не только реакции

Реакция означает «взяли в работу», восстановление означает «работает». Исполнитель, который отвечает за пять минут и чинит три дня, формально выполняет SLA, если в нём есть только время реакции. Поэтому просите оба числа по каждому приоритету.

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

Доступность в процентах и в минутах

«Доступность 99,9 %» звучит солидно, пока не перевести её в время. Расчёт простой: в 30-дневном месяце 43 200 минут, и процент от них показывает допустимый простой.

Доступность

Допустимый простой в месяц

Кому обычно подходит

99 %

7 ч 12 мин

второстепенные системы

99,5 %

3 ч 36 мин

офисная работа в рабочее время

99,9 %

43 мин

учёт, почта, важные сервисы

99,99 %

4 мин

немногие критичные системы

Подключение сетевого оборудования: работы, которые стоит перечислить в договоре на обслуживание

Это то, что называют «четырьмя девятками»: 99,99 % оставляет около четырёх минут сбоя в месяц, и, по тому же исследованию ITIC, 90 % опрошенных организаций требуют не меньше этого уровня. Но речь там о серверах и сетях. Для офиса на 50 человек закладывать такую планку во весь договор обычно избыточно и заметно дороже, а вот 99,5 или 99,9 % в рабочее время уже можно требовать и проверять.

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

Резервные копии: RPO и RTO

Здесь два показателя, которые часто путают. RPO отвечает на вопрос «сколько данных мы готовы потерять»: час работы или сутки. RTO отвечает на вопрос «за какое время вернём работу после серьёзного сбоя»: час, четыре часа, день. Для бухгалтерской базы потеря суток может означать несколько дней восстановления вручную, и это тоже стоит посчитать заранее.

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

Отчёты и эскалация

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

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

У самого исполнителя тоже есть внутренние договорённости, их называют OLA: например, за сколько минут диспетчер передаёт заявку выездному инженеру. Видеть OLA вам не обязательно, но стоит спросить, на кого исполнитель опирается сам: если часть работ делают его субподрядчики, их сроки должны укладываться в те, что обещаны вам.

Компенсация и выход из договора

Чаще всего нарушение SLA компенсируется скидкой на следующий счёт, так называемым сервисным кредитом. Хороший пример публичных цифр дают условия SLA на облачные серверы Amazon EC2: если доступность за месяц ниже 99,99 %, в счёт будущих платежей засчитывается 10 % месячного счёта, ниже 99 % уже 30 %, ниже 95 % весь счёт. Заметьте масштаб: это скидка в пределах стоимости самой услуги, а не компенсация ваших убытков от остановки.

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

Сколько стоит ваш час простоя: простая формула

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

Допустим, встали 30 человек и склад не отгружает: к зарплатам этих людей добавляется то, что не отгружено и не оплачено. Подставьте свои цифры, получите сумму за час и сравните с разницей в цене между 99,5 и 99,9 % доступности. Если один час простоя стоит больше, чем годовая разница в тарифе, экономить на классе доступности не стоит.

Чего SLA не гарантирует

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

Есть и обратная сторона. Как правило, исполнитель не отвечает за сбой, если вы не оплатили счёт, не дали доступ или самовольно изменили настройки. Это нормально, если такие случаи перечислены в договоре заранее, а не придуманы после инцидента.

Итог

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

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

Что такое SLA простыми словами?

Это раздел договора, где исполнитель письменно обещает конкретные сроки реакции и восстановления, уровень доступности и компенсацию за срыв. Он превращает общее «мы обслуживаем» в измеримые обязательства.

Какую доступность просить для офиса на 50 человек?

Для офисных систем обычно обсуждают от 99,5 до 99,9 % в рабочее время, а 99,99 % нужен немногим сервисам и стоит заметно дороже. Выбор лучше проверить расчётом стоимости вашего часа простоя.

Вернёт ли исполнитель деньги за простой по SLA?

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

Можно ли взять образец договора SLA из интернета?

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

Поделиться:
Присоединяйтесь к нам:

Похожие статьи

Все статьи

Популярные статьи

Все статьи

Комментарии

Чтобы добавить комментарий, войдите или зарегистрируйтесь.