SLA на поддержку сайта: шаблон для агентства
Что такое SLA и зачем он агентству
SLA (Service Level Agreement) — соглашение об уровне сервиса, раздел договора на поддержку сайта, в котором зафиксированы измеримые обязательства исполнителя: какая доступность гарантируется, как быстро реагируют на инцидент, что происходит при нарушении.
Для агентства SLA — это не формальность, а инструмент, который решает сразу несколько задач:
- Фиксирует границы ответственности. Заказчик понимает, за что именно платит и что входит в поддержку, а что — отдельная работа.
- Защищает от необоснованных претензий. Если в договоре прописана доступность 99,5 %, заказчик не сможет требовать «нуля простоя» и штрафа за каждую минуту.
- Делает отношения предсказуемыми. Метрики измеримы, а значит, спор «сайт лежал часто» превращается в разговор о конкретных цифрах.
Практика показывает: конфликты с заказчиками почти всегда возникают из-за того, что ожидания не были зафиксированы заранее. Одна сторона считала, что «поддержка» — это реакция в течение часа ночью и в выходные, другая — что достаточно ответить в рабочее время на следующий день. SLA снимает эту неопределённость.
Обратная сторона: SLA — это обязательство, которое нужно реально выполнять и подтверждать. Поэтому прежде чем писать «доступность 99,99 %», посчитайте, сколько простоя эта цифра допускает. Девять девяток — это менее 5 минут простоя в год, и такая гарантия требует серьёзной инфраструктуры с резервированием. Прикинуть допустимое время простоя для любого процента можно на калькуляторе доступности — от него стоит отталкиваться, выбирая цифру для договора.
Из чего состоит SLA: обязательные блоки
Хорошее SLA — компактный документ без воды. Его ядро — пять блоков.
1. Объект и границы услуги
Чётко перечислите, что обслуживается: конкретный сайт (домен), его компоненты (CMS, база данных, интеграции), окружение (хостинг или сервер). И не менее чётко — что не входит: доработка функционала, контент, дизайн, продвижение. Это отдельный от поддержки объём.
2. Метрики доступности
Главная метрика — uptime, доля времени, в течение которого сайт доступен. Обычно её задают за месяц или за год. Второй по важности параметр — время реакции, то есть за сколько исполнитель обязан приступить к устранению. Разберём их подробнее ниже.
3. Приоритеты инцидентов
Не все проблемы одинаково серьёзны. Падение сайта целиком и опечатка в тексте — разные вещи, и у них должны быть разные нормативы реакции. Стандартная схема — три-четыре уровня приоритета.
4. Порядок взаимодействия
Как заказчик сообщает о проблеме (канал), кто с каждой стороны отвечает за инцидент, как фиксируется факт и время. Без этого пункта «время реакции» невозможно проверить — вы не договорились, от какого момента оно отсчитывается.
5. Компенсации и штрафы
Что происходит, если метрики не выполнены. Это может быть перерасчёт оплаты, бонусные часы работ или скидка. Важно: штрафы должны быть симметричны — если исполнитель платит за простой, заказчик тоже должен иметь обязательства (например, предоставлять доступы вовремя).
Таблица метрик: что и как измерять
Ключевое правило SLA — всё должно быть измеримо. Любая метрика, которую нельзя проверить автоматически, в договоре бесполезна: по ней невозможно будет ни подтвердить выполнение, ни зафиксировать нарушение.
| Метрика | Что означает | Как измеряется | Типичное значение |
|---|---|---|---|
| Доступность (uptime) | Доля времени, когда сайт отвечает | Автоматические проверки с интервалом 1–5 мин | 99,5–99,9 % за месяц |
| Время реакции | От сигнала до начала работ | От метки времени в заявке/алерте | 15 мин–4 часа по приоритету |
| Время восстановления | От сигнала до полного восстановления | По истории инцидентов | 1–24 часа по приоритету |
| Макс. длительность одного простоя | Предел непрерывного простоя | Длительность инцидента | 1–8 часов |
| Срок продления SSL/домена | До какого срока нужно перевыпустить | По данным мониторинга | За 14–30 дней до истечения |
| Время ответа (TTFB) | Скорость отдачи страницы | Средний показатель за период | До 1–3 секунд |
Разберём две самые спорные метрики, вокруг которых чаще всего идут разногласия.
Доступность: какую цифру обещать
Доступность считается по формуле: uptime = (время работы / общее время) × 100 %. Простой от плановых работ (если они заранее согласованы) обычно из расчёта исключают — это важный пункт, который нужно прописать отдельно, иначе любое обновление будет «портить статистику».
Выбирая цифру, опирайтесь на реальные возможности инфраструктуры:
| Гарантируемый uptime | Допустимый простой за месяц | За год | Кому подходит |
|---|---|---|---|
| 99,0 % | ~7,3 часа | ~3,7 суток | Простые сайты, низкая цена поддержки |
| 99,5 % | ~3,7 часа | ~1,8 суток | Большинство коммерческих сайтов |
| 99,9 % | ~43 минуты | ~8,8 часа | Магазины, сервисы с транзакциями |
| 99,99 % | ~4,3 минуты | ~52 минуты | Критичные сервисы, нужна отказоустойчивая инфраструктура |
Обратите внимание: разница между 99,9 % и 99,99 % — это в десять раз меньше допустимого простоя. Если вы обещаете «четыре девятки» на обычном хостинге без резервирования, вы почти гарантированно не выполните SLA. Лучше честно предложить 99,9 % и реально его держать, чем красиво написать 99,99 % и платить штрафы.
Время реакции vs время восстановления
Это разные вещи, и их часто путают. Время реакции — когда исполнитель отреагировал (взял заявку в работу, начал разбираться). Время восстановления — когда сайт снова полностью работает. Заказчику важнее второе, но гарантировать его сложнее: устранение может зависеть от внешних факторов (хостинг-провайдер, регистратор домена).
Поэтому в SLA фиксируют оба показателя, но с разными значениями: время реакции — жёстко, время восстановления — как целевой показатель с оговоркой о внешних зависимостях.
Приоритеты инцидентов: готовая схема
Привязывать нормативы к приоритету — стандартная практика. Вот рабочая трёхуровневая схема, которую можно использовать как основу.
| Приоритет | Что это | Пример | Время реакции | Время восстановления |
|---|---|---|---|---|
| P1 — критичный | Сайт или ключевой функционал полностью недоступен | Главная не открывается, заказы не оформляются | 15–30 минут | до 4 часов |
| P2 — высокий | Частично не работает значимый функционал | Не работает форма, сломана оплата | 1–2 часа | до 8 часов |
| P3 — средний | Проблема не блокирует работу | Мелкая ошибка вёрстки, медленный раздел | 4–8 часов (в раб. время) | до 24–48 часов |
| P4 — низкий | Косметика, запросы | Опечатка, замена текста | 1–2 рабочих дня | по договорённости |
Два важных уточнения, которые стоит внести в договор:
- Рабочие и нерабочие часы. Нормативы P1 обычно действуют круглосуточно (сайт не спрашивает, выходной ли сегодня), а P3–P4 — только в рабочие часы. Иначе поддержка по «мелочам» превратится в круглосуточное дежурство.
- Откуда отсчитывается время. Время реакции отсчитывается от момента фиксации инцидента в согласованном канале. Пропишите, что заявка считается зафиксированной, когда она поступила в тикет-систему или канал мониторинга, а не «когда заказчик позвонил в личку менеджеру в отпуске».
Готовые формулировки для договора
Ниже — формулировки, которые можно адаптировать под конкретный договор. Они написаны без юридического канцелярита, но фиксируют все ключевые моменты. Перед подписанием документ стоит показать юристу — здесь приведена содержательная часть, а не полный текст договора.
Формулировка про доступность
«Исполнитель обеспечивает доступность Сайта на уровне не ниже 99,9 % за каждый отчётный период (календарный месяц). Доступность рассчитывается как отношение времени, в течение которого Сайт отвечал на проверочные запросы с кодом 2xx/3xx, к общему времени периода. Плановые технические работы, согласованные с Заказчиком не менее чем за 24 часа, в расчёт времени простоя не включаются. Факт доступности фиксируется автоматической системой мониторинга с интервалом проверки не более 5 минут.»
Обратите внимание на три ключевых оговорки: способ подсчёта (коды ответа), исключение плановых работ и источник данных (система мониторинга). Без них метрика «доступность» остаётся декларацией.
Формулировка про время реакции
«Время реакции — период от момента регистрации инцидента в согласованном канале до момента начала работ Исполнителем по его устранению. Для инцидентов приоритета P1 время реакции составляет не более 30 минут, для P2 — не более 2 часов, для P3 — не более 8 часов в рабочие часы (пн–пт, 10:00–19:00).»
Формулировка про отчётность
«Исполнитель ежемесячно предоставляет Заказчику отчёт о доступности Сайта, сформированный на основании данных автоматической системы мониторинга, с указанием общего времени простоя, количества и длительности инцидентов, а также причин их возникновения.»
Этот пункт защищает обе стороны: у заказчика есть объективные данные, а у исполнителя — доказательство выполненной работы.
Подробнее о том, как агентству выстроить мониторинг клиентских проектов и использовать его в отчётности, — в статье «Мониторинг сайтов для агентств».
Формулировка про штрафы
«В случае если доступность Сайта за отчётный период составила менее 99,9 %, стоимость услуг за соответствующий период уменьшается пропорционально времени простоя сверх допустимого, но не более чем на 20 % стоимости услуг за период. Нарушение считается подтверждённым только на основании данных системы мониторинга, указанной в Приложении.»
Два принципа, которые стоит соблюдать при формулировании штрафов:
- Ограничивайте верхнюю границу. Штраф не должен превышать стоимость услуги за период, иначе одно падение сайта обнулит месячный доход агентства.
- Опирайтесь на объективные данные. Спор «сколько лежал сайт» должен решаться данными мониторинга, а не перепиской.
Распространённые ошибки при составлении SLA
Разберём типичные грабли, на которые наступают и начинающие, и опытные агентства.
| Ошибка | К чему приводит | Как правильно |
|---|---|---|
| Обещать «99,99 %» без инфраструктуры | Гарантированные штрафы, испорченные отношения | Ставить реальную цифру по возможностям хостинга |
| Не отличать время реакции от восстановления | Заказчик требует «починить за 30 минут», вы не можете | Фиксировать оба показателя раздельно |
| Не прописывать исключения (плановые работы) | Каждое обновление «роняет» статистику | Явно исключить согласованные работы |
| Не указывать источник данных о доступности | Спор «лежал/не лежал» без объективных цифр | Сослаться на конкретную систему мониторинга |
| Не ограничивать штрафы сверху | Один инцидент съедает месячную выручку | Лимит штрафа — доля от стоимости периода |
| Гарантировать время реакции 24/7 по всем приоритетам | Выгорание команды, невыполнимые обязательства | Круглосуточно — только P1, остальное в рабочие часы |
Общая логика: обещайте то, что можете измерить и реально выполнить. Лучше более скромные цифры, которые вы держите с запасом, чем амбициозные, по которым платите неустойку.
Проверка выполнимости: посчитайте до подписания
Прежде чем зафиксировать цифры в договоре, проверьте, что вы их реально вытягиваете. Порядок действий:
- Посчитайте допустимый простой. Возьмите целевой процент доступности и посмотрите, сколько это минут простоя в месяц и в год. Для быстрой прикидки используйте калькулятор доступности.
- Оцените текущую инфраструктуру. Один сервер без резервирования не даст 99,99 %. Резервирование, балансировка, автоматические фейловеры — всё это стоит денег, которые должны быть заложены в цену поддержки.
- Проверьте каналы реакции. Если вы обещаете реакцию за 30 минут, кто-то в команде должен реально дежурить и получать алерты. Автоматический мониторинг с уведомлениями — обязательное условие, а не опция.
- Протестируйте сценарий. Имитируйте инцидент (например, временно отключите проверку) и засеките, за сколько команда реально отреагировала и восстановила работу. Это честнее любых оценок «на глаз».
Только после такой проверки вносите цифры в договор. SLA, который невозможно выполнить, хуже его отсутствия: он не защищает, а создаёт источник постоянного конфликта.
Коротко о главном
SLA — это договорённость, которая делает отношения агентства и заказчика предсказуемыми. Его ядро — измеримые метрики: доступность, время реакции и восстановления, приоритеты инцидентов. Всё остальное — формулировки, которые эти метрики фиксируют юридически.
Три правила, которые стоит запомнить: обещайте реальные цифры (посчитайте допустимый простой до подписания), разделяйте время реакции и восстановления, и опирайтесь на объективные данные мониторинга во всех спорных вопросах. Тогда SLA станет инструментом продажи доверия, а не источником головной боли.
Начать стоит с цифр: посмотрите на калькуляторе доступности, сколько простоя допускает тот или иной процент аптайма, — это станет отправной точкой для разговора с заказчиком о реалистичных гарантиях.
