SLA: что это простыми словами и как прописать его в договоре

SLA это соглашение об уровне услуг: часть договора, где заказчик и исполнитель записывают измеримые обещания. Как быстро исполнитель отвечает на обращение, за какой срок устраняет сбой, сколько времени сервис должен работать без перерывов и что будет, если обещание нарушено. Хороший SLA помещается на одну-две страницы, опирается на цифры, которые обе стороны могут проверить, и делит обращения по важности. Тогда «сайт лежит» и «поменяйте картинку в шапке» не ждут в одной очереди.

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

SLA (Service Level Agreement) переводится как «соглашение об уровне сервиса». Это обещание исполнителя, выраженное в цифрах, с понятными последствиями при нарушении. Без SLA договор на поддержку обычно звучит как «исполнитель оказывает услуги своевременно», и спорить о слове «своевременно» можно бесконечно.

Где SLA встречается в малом бизнесе:

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

Рядом с SLA часто встречаются похожие слова. Их легко перепутать, поэтому коротко о разнице.

Термин	Между кем	Что фиксирует	Есть ли последствия
SLA	Исполнитель и заказчик	Сроки реакции и решения, доступность, порядок измерения	Да, прописаны в договоре
OLA	Отделы внутри исполнителя	Внутренние сроки, без которых не выполнить SLA: например, дежурный передаёт сбой разработчику за 15 минут	Внутренние, без штрафов клиенту
KPI	Компания и сотрудник или команда	Показатель эффективности работы	Влияет на премии и оценку, не на договор с клиентом
Регламент	Внутри компании	Порядок действий и сроки в процессе	По трудовым правилам компании

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

SLA, SLO и SLI: в чём разница

SLI это то, что измеряют, SLO это цель по этому измерению, а SLA это обещание клиенту с последствиями за невыполнение. Так их разводят в книге Google по надёжности сервисов (Site Reliability Engineering), откуда эти термины и разошлись по рынку.

Термин	Вопрос	Пример для поддержки сайта
SLI, Service Level Indicator	Что и как мы измеряем?	Доля обращений, на которые ответили в срок, по журналу заявок за месяц
SLO, Service Level Objective	Какой уровень считаем хорошим?	Не меньше 95% обращений с ответом в срок
SLA, Service Level Agreement	Что обещаем клиенту и что будет при нарушении?	Если в срок ответили меньше чем на 90% обращений, исполнитель даёт скидку на следующий месяц

Обратите внимание: цель внутри команды (95%) строже, чем обещание в договоре (90%). Запас нужен, чтобы команда замечала проблему раньше, чем наступят последствия по договору. В той же книге Google есть простое правило: если за нарушение цели ничего не наступает, перед вами SLO, а не SLA.

Время реакции и время решения: что считать

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

В договоре важно записать не только цифры, но и правила отсчёта:

• Точка старта. Время регистрации обращения в системе заявок или на почте поддержки, а не сообщение в личный мессенджер сотрудника.
• Что считается реакцией. Ответ с пониманием проблемы и планом действий. Автоответ «ваше обращение принято» реакцией не считается.
• Что считается решением. Работа восстановлена, заказчик подтвердил или не ответил за оговорённый срок.
• Рабочее или календарное время. «4 часа» в пятницу в 17:00 при рабочем времени до 18:00 закончатся в понедельник. Это нормально, если записано.
• Пауза. Пока исполнитель ждёт от заказчика доступы, тексты или решение, часы останавливаются.

Приоритеты: почему одного срока на всё мало

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

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

Приоритет	Что сюда относится	Реакция (пример)	Решение или обход (пример)
P1, авария	Сайт не открывается, не работает оплата или форма заявки	1 рабочий час	4 рабочих часа
P2, серьёзно	Сломан важный раздел, заявки не доходят в CRM, ошибка в ценах	4 рабочих часа	1 рабочий день
P3, обычное	Неудобство без потери заявок: съехала вёрстка, не грузится картинка	В течение рабочего дня	5 рабочих дней
P4, доработка	Новая страница, новая функция, изменение логики	Оценка за 2 рабочих дня	По согласованному плану

Пропишите, кто присваивает приоритет. Обычно его ставит исполнитель по описанию из договора, а заказчик может оспорить. Иначе каждое обращение станет «срочным».

Доступность: что на самом деле значат 99,9%

Доступность показывает, какую долю времени сервис работал, и почти всегда считается за месяц. Проценты выглядят одинаково высокими, но разница между ними большая. В месяце из 30 дней 43 200 минут, поэтому каждая десятая доля процента это 43 минуты.

Три вещи, без которых процент доступности ничего не значит:

1. Как измеряют. Например, внешний сервис мониторинга раз в минуту открывает главную страницу и форму заявки. Если ответа нет две проверки подряд, это простой.
2. Что исключено. Плановые работы с предупреждением за сутки, сбои по вине заказчика, проблемы у провайдеров, которые исполнитель не выбирал.
3. Чья это зона. Если сайт стоит на хостинге, который оплачивает заказчик, разработчик не может обещать 99,9%. Он может обещать реакцию на падение и работу с хостингом.

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

Что прописать в договоре: разделы SLA

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

1. Описание услуги. Что входит в поддержку и что нет. Например, исправление ошибок входит, а новые разделы оцениваются отдельно.
2. Каналы обращений. Куда писать и звонить, что считается зарегистрированным обращением.
3. Рабочее время. Дни, часы, часовой пояс, праздники. Отдельно: есть ли дежурство по авариям вне рабочего времени.
4. Приоритеты. Определения с примерами и правило, кто их присваивает.
5. Сроки. Реакция и решение по каждому приоритету, правила отсчёта и паузы.
6. Показатели и порядок измерения. Где хранится журнал обращений, как считается доля в срок, кто делает отчёт.
7. Обязанности заказчика. Доступы, контактное лицо, сроки ответов на вопросы исполнителя.
8. Исключения. Плановые работы, форс-мажор, сбои внешних сервисов, изменения, сделанные заказчиком без согласования.
9. Последствия нарушения. Скидка, неустойка, право расторгнуть договор при систематических нарушениях.
10. Отчётность и пересмотр. Отчёт раз в месяц, пересмотр условий раз в полгода или год.

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

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

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

Какие бывают варианты:

• Скидка на следующий месяц (в облачных сервисах это называют сервисными кредитами). Например, 5% от месячной платы, если доля обращений в срок ниже обещанной.
• Неустойка: штраф или пеня. По статье 330 ГК РФ это сумма, установленная договором, которую должник платит при неисполнении или просрочке. Кредитору не нужно доказывать убытки, но нужно, чтобы нарушение было по вине исполнителя.
• Право расторгнуть договор без штрафа для заказчика, если SLA нарушается несколько месяцев подряд.

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

Пример: SLA на сопровождение сайта и IT-подписку

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

Пункт	Формулировка (пример)
Предмет	Поддержка сайта, CRM и интеграций между ними, исправление ошибок, мелкие доработки в пределах плана месяца
Канал	Обращение считается зарегистрированным, когда оно создано в системе заявок или пришло на почту поддержки
Рабочее время	Пн–Пт, 10:00–19:00 по Москве, кроме праздничных дней
Базовый срок ответа	Ответ в течение рабочего дня на любое обращение; для аварий P1 отдельный срок
Мониторинг	Проверка главной страницы и формы заявки каждые 5 минут, оповещение исполнителю и заказчику
Отчёт	Раз в месяц: сколько обращений, сколько в срок, что сделано, какие риски
Последствия	Если доля обращений в срок ниже 90% за месяц, скидка на следующий месяц
Пересмотр	Раз в 6 месяцев по итогам отчётов

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

Как проверять, что SLA соблюдают

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

• Один журнал обращений. Время создания, приоритет, первый ответ, решение, паузы.
• Таймеры и предупреждения. Система напоминает о сроке до того, как он истёк, а не после.
• Месячный отчёт. Доля в срок по каждому приоритету, самые долгие обращения и их причины.
• Разбор нарушений. Не поиск виноватых, а вопрос «что поменять, чтобы не повторилось».

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

Нужен ли SLA, если подрядчик один человек

Нужен, и даже больше, чем с большой студией. У одного исполнителя бывают отпуск, болезнь и другие клиенты, а у вас в этот момент может остановиться форма заявки. Короткий SLA заставляет заранее ответить на неудобные вопросы.

• Кто подменяет исполнителя, если он недоступен, и как этот человек получит доступы.
• Какие сроки действуют в отпуск и праздники.
• Где хранятся доступы, резервные копии и описание систем, чтобы с ними мог работать другой специалист.

Если честный ответ на первый вопрос «никто», пропишите хотя бы мониторинг с оповещением вам напрямую и инструкцию, как вернуть сайт из резервной копии.

Чек-лист: готов ли SLA к подписанию

Пройдитесь по пунктам перед тем, как подписывать договор с исполнителем или отправлять свой SLA клиенту.

Типичные ошибки

• Один срок на всё. Мелкие правки и аварии ждут в общей очереди.
• Нет правил отсчёта. Непонятно, с какого момента идут часы и останавливаются ли они.
• Обещание без измерения. В договоре есть сроки, но нет журнала, из которого их можно проверить.
• Доступность без методики. Записано 99,9%, но не сказано, кто, как и что измеряет.
• Штраф вместо системы. Большие санкции есть, а мониторинга и отчёта нет.
• Нет обязанностей заказчика. Исполнитель ждёт доступы неделю, а срок формально горит.
• SLA пишут один раз. Бизнес вырос, заявок стало больше, а условия остались прежними.