SLA — что это такое: соглашение об уровне сервиса простыми словами

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

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

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

SLA (Service Level Agreement) — это соглашение об уровне сервиса: документ, в котором исполнитель и заказчик фиксируют, какой именно сервис оказывается, как быстро исполнитель реагирует на проблемы, за сколько их устраняет, как это измеряется и что происходит, если обещанный уровень не выдержан.

Если совсем коротко, SLA — это правила игры, записанные до первой аварии. Без них каждая сторона понимает «хорошую поддержку» по-своему: для владельца интернет-магазина «быстро» — это 15 минут, для подрядчика — «в течение рабочего дня». Обе стороны искренне считают, что правы, и выясняют это в самый неудобный момент.

Важно понимать юридическую сторону. В Гражданском кодексе РФ нет отдельного вида договора «SLA». На практике соглашение оформляют приложением к договору возмездного оказания услуг (глава 39 ГК РФ) или прописывают разделом прямо в нём. Санкции за нарушение уровня сервиса — это обычная договорная неустойка (статья 330 ГК РФ), поэтому формулировать их нужно так же аккуратно, как любую другую ответственность.

SLA, SLO, SLI и OLA: чем отличаются

В переписке с подрядчиком могут всплыть смежные аббревиатуры. Разница между ними простая:

• SLI (Service Level Indicator) — сама метрика, которую можно измерить: доля успешных проверок доступности, время ответа сервера, время первого ответа на заявку.
• SLO (Service Level Objective) — целевое значение этой метрики: «доступность не ниже 99,5% за месяц», «ответ на критичный инцидент — до 30 минут».
• SLA — внешнее обязательство перед заказчиком с последствиями: если SLO не выполнено, срабатывают компенсации.
• OLA (Operational Level Agreement) — внутреннее соглашение между подразделениями исполнителя, например между поддержкой и админами. Заказчику оно напрямую не нужно, но показывает зрелость процессов.

Для заказчика главное — SLA. Но полезно знать, что хороший подрядчик держит внутренние цели жёстче внешних обязательств: если в договоре обещано 99,5%, внутри команда целится в 99,8%, чтобы иметь запас.

Из чего состоит SLA на поддержку сайта

Структура соглашения зависит от услуги, но для поддержки сайта набор разделов почти всегда одинаковый:

Ключевые метрики SLA

Время реакции

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

Время восстановления и время решения

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

Доступность (uptime)

Доля времени, когда сайт работает, за период — обычно календарный месяц. Считается просто: (общее время − время простоя) / общее время × 100%. Сложность в другом: нужно договориться, что считать простоем. Главная открывается, но корзина выдаёт ошибку — это работа или простой? Для интернет-магазина честный ответ — простой, и это нужно закрепить формулировкой вроде «недоступность главной страницы, каталога, корзины или оформления заказа».

Доля заявок, закрытых в срок

Сводная метрика качества: сколько процентов обращений за месяц уложились в свои сроки. Нормальная цель — от 90–95%. Она страхует от ситуации, когда каждый отдельный срыв выглядит мелким, а в сумме поддержка работает плохо.

99,9% доступности — это сколько минут простоя

Проценты доступности обманчивы: разница между 99% и 99,9% выглядит косметической, а на деле это семь часов против сорока минут. Расчёт для месяца в 30 дней (43 200 минут) и года в 365 дней:

Каждая следующая «девятка» стоит заметно дороже: нужны резервные серверы, отказоустойчивая база, дежурная смена ночью и в выходные. Для большинства сайтов малого и среднего бизнеса разумная цель — 99,5–99,9%. Требовать 99,99% от подрядчика, когда сайт живёт на одном виртуальном сервере, бессмысленно: такой уровень невозможен физически, и подрядчик либо откажется, либо подпишет обещание, которое не сможет выполнить.

Приоритеты инцидентов P1–P4

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

• P1 — критический. Сайт недоступен целиком, не работает оформление заказа или оплата, признаки взлома или утечки данных. Бизнес теряет деньги каждую минуту.
• P2 — высокий. Сломана важная функция, но сайт работает: не уходят заявки с одной из форм, отвалилась выгрузка из 1С, не работает один способ оплаты, страницы грузятся больше 5–10 секунд.
• P3 — средний. Некритичная ошибка, есть обходной путь: не работает фильтр каталога, сломан вывод отзывов, ошибка в мобильной вёрстке одного раздела.
• P4 — низкий. Косметика и плановые задачи: опечатка, замена баннера, мелкая правка текста или стилей.

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

Пример таблицы SLA для поддержки сайта

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

Обратите внимание на колонку «Режим». Фраза «реакция 4 часа» без уточнения, календарные это часы или рабочие, означает совсем разное: заявка, поданная в пятницу в 17:30 при режиме 9×5, по рабочим часам должна быть взята в работу только в понедельник днём. Для P1 это неприемлемо, для P4 — нормально.

Если вы выбираете формат обслуживания, посмотрите, как устроена поддержка сайтов с фиксированными сроками реакции: обычно пакеты различаются именно режимом (9×5 или 24×7) и временем реакции на критичные инциденты, а не только количеством часов.

Штрафы, сервисные кредиты и исключения

Как считать компенсацию

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

• фактическая доступность ниже обещанных 99,9%, но не ниже 99,0% — скидка 10% от месячной платы;
• ниже 99,0%, но не ниже 98,0% — 25%;
• ниже 98,0% — 50%;
• каждый P1-инцидент с нарушением срока восстановления — дополнительно 5%.

Почти всегда ставится потолок — например, не более 50–100% месячной платы. Это нормально: исполнитель не может отвечать своей выручкой за всю упущенную прибыль заказчика, иначе поддержка стоила бы как страховой полис. Если кредиты выглядят слишком мягкими, лучше обсудить более жёсткие сроки для P1 или право расторгнуть договор после нескольких серьёзных нарушений подряд, чем раздувать штрафы.

Что обычно исключают из SLA

• Плановые работы — обновления CMS, серверного ПО, миграции. Нормальная практика: заранее уведомлять (за 24–72 часа) и проводить в ночное окно, а сами окна ограничивать по длительности.
• Сбои внешних сервисов — платёжного шлюза, службы доставки, API маркетплейса, CRM. Подрядчик должен быстро диагностировать и сообщить, что проблема не у вас, но устранить её не может.
• Хостинг и DNS, если серверы арендует сам заказчик у стороннего провайдера.
• Действия заказчика и третьих лиц — правки в админке, плагины, которые поставил штатный сотрудник, изменения другого подрядчика.
• Форс-мажор и DDoS-атаки — DDoS выше согласованного объёма, если защита от них не входит в услугу. Сам по себе DDoS форс-мажором обычно не признаётся, поэтому его стоит прописать отдельным пунктом.

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

Как измерять выполнение SLA

Метрика без источника данных — повод для спора. В соглашении стоит прямо указать:

• Чем меряется доступность. Внешний мониторинг, который проверяет сайт снаружи с интервалом 1–5 минут, а не «по данным нашего сервера». Заказчику полезно иметь собственный доступ к мониторингу — например, в бесплатном внешнем сервисе мониторинга аптайма с уведомлениями.
• Что проверяется. Не только главная страница, но и ключевые сценарии: каталог, корзина, отправка формы.
• С какого момента идёт отсчёт. С регистрации тикета, с сообщения в оговорённый канал или со срабатывания мониторинга — что наступило раньше.
• Где хранится история. Тикет-система с отметками времени. Устные звонки без фиксации в системе для SLA не существуют.
• Отчёт. Ежемесячно: доступность, список инцидентов с приоритетами, фактические сроки реакции и восстановления, причины и принятые меры.

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

Типичные ошибки при согласовании SLA

1. Одна цифра на всё. «Время реакции — 2 часа» без приоритетов. В итоге либо авария ждёт, либо вы переплачиваете за скорость на мелочах.
2. Реакция вместо восстановления. В договоре есть только время реакции. Подрядчик формально ответил за 15 минут, а сайт чинили двое суток — и нарушения нет.
3. Не указаны часы. Непонятно, рабочие это часы или календарные и в каком часовом поясе. Подрядчик в другом регионе работает по своему времени.
4. Нет определения простоя. Главная открывается — значит, «сайт работает», хотя оплата не проходит уже три часа.
5. Нереальные цифры. 99,99% на одном сервере без резервирования или реакция 5 минут за скромную абонентскую плату. Такое обещание будет нарушено, и компенсация не вернёт потерянные заказы.
6. Размытые исключения. «Иные обстоятельства» и «сбои у третьих лиц» без перечня.
7. Нет обязанностей заказчика. Подрядчику не дали доступы к серверу или никто со стороны заказчика не отвечает ночью — а срок идёт.
8. Доработки в общей очереди. Задачи на развитие смешаны с инцидентами, и «поменять баннер» съедает время дежурного, пока лежит оплата. Развитие лучше вести отдельным пакетом часов.

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

• Перечислены все сайты, домены, интеграции и серверы, на которые распространяется поддержка
• Указан режим работы (9×5, 12×7, 24×7) и часовой пояс — лучше МСК
• Есть приоритеты P1–P4 с примерами именно для вашего сайта
• Для каждого приоритета указаны и время реакции, и время восстановления
• Понятно, рабочие это часы или календарные
• Описано, что считается простоем, и ключевые сценарии входят в проверку
• Указан инструмент мониторинга, у заказчика есть к нему доступ
• Закреплены каналы подачи заявок и момент начала отсчёта
• Закрытый список исключений, плановые работы — с уведомлением и ограничением по времени
• Шкала компенсаций и её потолок, право расторжения при повторных нарушениях
• Прописаны обязанности заказчика: доступы, контактное лицо, сроки ответов
• Ежемесячный отчёт с фактическими метриками и разбором P1-инцидентов
• Цифры доступности согласованы с договором хостинга

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

Вывод

SLA — это не бюрократия и не инструмент наказать подрядчика, а способ заранее договориться, что произойдёт при аварии: кто узнает о ней первым, через сколько минут начнётся работа и когда сайт снова будет принимать заказы. Хорошее соглашение короткое и конкретное: приоритеты с примерами, отдельные сроки реакции и восстановления, понятное определение простоя, реалистичная доступность с учётом хостинга, закрытый список исключений и измеримые компенсации. Считайте цифры от стоимости часа простоя вашего сайта: если час без заказов обходится в десятки тысяч рублей, круглосуточная реакция на P1 окупится с первой же аварии, а для сайта-визитки хватит поддержки в рабочее время. У нас поддержка с SLA считается по ставке 2 500 ₽ за час специалиста: абонемент на 10 часов в месяц — 25 000 ₽, на 20 часов — 50 000 ₽.