О компании

Поддержка сайта по SLA: что фиксировать в договоре, чтобы это работало

Если SLA не работает, почти всегда причина одна. Ниже — полный «скелет» того, что нужно прописать, с практическими формулировками и логикой.

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

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

1) С чего начать: SLA ≠ договор, и это важно

Чтобы поддержка была управляемой, обычно разделяют документы:

  1. Договор (основной). Юридическая часть: стороны, оплата, ответственность, порядок оказания услуг, конфиденциальность, обработка данных, порядок приемки.
  2. SLA (Service Level Agreement) — приложение, раздел. Измеримые уровни сервиса: время реакции, восстановления, часы поддержки, каналы, критичность, отчётность, service credits, штрафы.
  3. Перечень услуг / SOW / Техническое приложение. Что конкретно делаете: мониторинг, администрирование, бэкапы, обновления CMS, багфикс, работа с хостингом, поддержка интеграций и т. п.

Ошибка, которая ломает всё: пытаться «запихнуть» в SLA и объём работ, и условия оплаты, и регламенты разработки. В итоге документ становится нечитаемым и непроверяемым.

2) Почему SLA «не работает»: 7 типовых провалов

  1. Не определены уровни критичности → спор «это срочно или подождёт».
  2. Не определено, что такое «время реакции» → подрядчик отвечает «принято», а вы ждёте диагностику.
  3. Нет единого канала заявок → заявки в Telegram, почте, звонках теряются и не измеряются.
  4. Нет источника правды по простоям → каждый считает по-своему.
  5. Не разделены «поддержка» и «развитие» → бюджет съедают «маленькие правки».
  6. Не описаны исключения и зависимости (хостинг, CDN, платежи, 1С, API) → виноватых нет.
  7. Нет регламента изменений → релизы ломают прод, и SLA превращается в пожарную команду.

3) Объект поддержки: что именно покрывает SLA

В договоре, приложении нужно зафиксировать состав объекта. Иначе вы обсуждаете поддержку «сайта» в целом, а ломается всегда конкретный компонент.

3.1. Компоненты (пример перечня)

  • Публичная часть сайта (frontend).
  • Админ-панель (CMS/панель управления).
  • Серверная часть (backend), cron-задачи.
  • База данных.
  • Поиск по сайту.
  • Интеграции: платежи, доставка, 1С/ERP/CRM, почтовые сервисы, SMS, аналитика.
  • Инфраструктура: хостинг/VM/контейнеры, CDN/WAF, домены, SSL-сертификаты, DNS.
  • Логи, мониторинг, резервное копирование.

3.2. Окружения

  • Production (боевой сайт) — обязательно.
  • Staging/Preprod (тестовое окружение) — желательно.
  • Dev (среда разработки) — опционально.

Фиксируйте: какие окружения обслуживаются, кто имеет доступ и по каким правилам туда попадают изменения.

3.3. «Стартовое состояние»

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

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

4) Канал заявок и правила обращений: без этого SLA нельзя измерить

Если заявка не попала в систему — её не существует для SLA.

4.1. Единая точка входа

Закрепите один (или два) официальных канала:

  • Service Desk (Jira Service Management, YouTrack, HelpDesk) — лучший вариант.
  • Email, который автоматически создаёт тикеты в системе — допустимо.

Мессенджеры — только как дополнение (уведомления, оперативная связь), но не как юридически значимый канал постановки задач.

4.2. Обязательные поля тикета (чтобы инженеры не гадали)

  • URL / раздел сайта.
  • Время возникновения проблемы.
  • Шаги воспроизведения.
  • Ожидаемое поведение / фактическое.
  • Скриншоты/видео/логи (если есть).
  • Масштаб: у всех / у части пользователей / только у админов.
  • Контакты ответственного с вашей стороны.
  • Предложенный приоритет (с пояснением).

4.3. Роли и права

Зафиксируйте:

  • кто может создавать заявки;
  • кто подтверждает критичность;
  • кто принимает результат;
  • кто согласует изменения.

Рекомендация: минимум один технический контакт со стороны клиента и один бизнес-контакт (для приоритизации).

5) Критичность инцидентов: матрица S1–S4 с примерами

Это ядро SLA. Не будет матрицы — будет хаос.

5.1. Пример определения уровней (адаптируйте под проект)

S1 — Критический инцидент (авария):

  • сайт недоступен (5xx/таймауты);
  • оформление заказа/оплата не работают;
  • массовая утечка/риски безопасности;
  • критичная функция бизнеса остановлена.

S2 — Высокая критичность:

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

S3 — Средняя:

  • частичные ошибки, влияющие на отдельные сценарии;
  • визуальные/контентные дефекты, не останавливающие продажи.

S4 — Низкая:

  • косметика, правки текста, баннеров;
  • консультации, мелкие улучшения, задачи «когда будет время».

5.2. Кто назначает критичность

В SLA фиксируют правило:

  • клиент предлагает уровень,
  • подрядчик подтверждает (или аргументированно меняет),
  • при споре — применяется правило «влияние × срочность» и эскалация.

6) Метрики SLA: что считаем, когда стартует отсчёт, что считается выполнением

Частый конфликт внутри проектов и задач — не в сроках, а в определениях.

6.1. Время реакции (Response Time)

Правильное определение: время от регистрации тикета в системе до первого содержательного ответа, включающего:

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

Ответ «принято» без смысла — не должен считаться реакцией.

6.2. Время восстановления (Restore Time)

Время до возвращения сервиса в работоспособное состояние (временно или полностью — это надо прописать).

Важно: часто полезно разделять:

  • восстановление (быстро вернуть сервис),
  • окончательное устранение причины (root cause fix).

Если не разделять — либо сервис будет стоять до «идеального» исправления, либо появится серия костылей без нормального закрытия причины.

6.3. Время решения (Resolution Time)

Время до полного устранения проблемы и закрытия тикета.

6.4. Рабочие часы и окна обслуживания

Прямо фиксируйте:

  • режим: 8×5 / 12×5 / 24×7;
  • часовой пояс;
  • праздничные дни;
  • плановые окна обслуживания (например, ночью).

6.5. Источник правды по простоям

Определите один источник измерений:

  • внешний мониторинг доступности (UptimeRobot/StatusCake/Prometheus + blackbox),
  • логи, метрики ошибок,
  • данные хостинга, провайдера.

Если источников несколько — заранее укажите приоритет (например: внешний мониторинг → логи → сообщения пользователей).

7) Пример SLA-таблицы (как закрепить в приложении)

Ниже — шаблон логики. Значения подбирают под бизнес (интернет-магазин и корпоративный портал — разные риски).

S1

  • Реакция: до 15 минут (24×7) / до 30 минут (12×5).
  • Восстановление: до 2 часов (включая временное решение, обходной путь).
  • Решение: до 24 часов или отдельный план с ETA и статусами каждые X часов.

S2

  • Реакция: до 1 часа.
  • Восстановление: до 8 часов.
  • Решение: до 3 рабочих дней.

S3

  • Реакция: до 4 часов.
  • Решение: до 10 рабочих дней / в плановом релизе.

S4

  • Реакция: до 1 рабочего дня.
  • Решение: по плану / в рамках пакета часов.

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

8) RPO/RTO, бэкапы и восстановление: пункт, который защищает бизнес, а не подрядчика

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

8.1. Что зафиксировать

  • RPO (Recovery Point Objective): допустимая потеря данных по времени. Пример: «не более 15 минут» для заказов.
  • RTO (Recovery Time Objective): допустимое время восстановления. Пример: «не более 2 часов» для оплаты.

8.2. Политика бэкапов

  • периодичность (например: БД каждые 15 минут, файлы раз в сутки);
  • срок хранения (30/90/180 дней);
  • место хранения (разные зоны/провайдеры);
  • шифрование;
  • ответственность: кто проверяет корректность бэкапа.

8.3. Тест восстановления (restore drill)

Это отдельный пункт: «не реже 1 раза в квартал проводится тест восстановления на тестовом окружении с актом».

9) Регламент изменений: чтобы поддержка не была вечным «пожарным»

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

9.1. Что описать

  • что считается изменением (обновление CMS, модулей, изменение шаблонов, интеграций, конфигурации сервера);
  • процесс релиза: staging → тесты → окно выкладки → мониторинг → подтверждение стабильности;
  • откат: в каких случаях обязателен, кто принимает решение;
  • emergency changes: как выкатывать критический фикс ночью и как потом закрывать хвосты.

10) Граница «поддержка» vs «развитие»: фиксируем, чтобы не сжечь бюджет

Это второй по частоте источник конфликтов после «времени реакции».

10.1. Пример разграничения

Поддержка:

  • исправление ошибок (багфикс);
  • восстановление после сбоев;
  • обновления безопасности (patching);
  • мелкие корректировки, не меняющие бизнес-логику (если включены пакетом);
  • консультации по эксплуатации.

Развитие:

  • новые функции (новые формы, новые способы оплаты/доставки);
  • изменения логики заказа, персонализации;
  • редизайн, новые разделы;
  • новый личный кабинет;
  • перенос на другую архитектуру/хостинг, серьёзная оптимизация.

10.2. Как это закрепить юридически

  • Поддержка идёт по SLA.
  • Развитие — по отдельному процессу: оценка, срок, бюджет, приемка, релизный цикл.

11) Производительность и «скорость»: определите, что считается проблемой

Фраза «сайт медленный» не имеет смысла, пока нет метрик.

11.1. Что можно закрепить

  • порог по доле 5xx/4xx;
  • среднее и p95 время ответа (по ключевым эндпоинтам);
  • допустимая деградация под пиковой нагрузкой;
  • правила реагирования на рост ошибок/нагрузки.

11.2. Раздел ответственности

Очень важно описать: если деградация из-за внешних сервисов (платежи/доставка/CRM), подрядчик:

  • диагностирует,
  • собирает фактуру,
  • взаимодействует с поставщиком сервиса, но не отвечает за их внутренние SLA (если вы это отдельно не согласовали).

12) Безопасность и доступы: пункт, который обычно игнорируют до первого инцидента

В договоре должны быть правила:

  • выдача доступов по ролям (RBAC): кто к чему имеет доступ;
  • хранение секретов (пароли/ключи) — не в чатах, а в менеджере секретов;
  • журналирование действий админов;
  • политика смены паролей/ключей;
  • порядок действий при подозрении на компрометацию.

13) Отчетность и контроль качества: как проверять SLA ежемесячно

Если нет отчётности — вы платите за «ощущение поддержки».

13.1. Минимальный отчёт (1 раз в месяц)

  • количество инцидентов по уровням S1–S4;
  • фактические времена реакции, восстановления, решения;
  • процент соблюдения SLA;
  • топ причин инцидентов;
  • повторяемость (какие проблемы вернулись);
  • что сделано для предотвращения повторов;
  • рекомендации (что надо поправить в архитектуре, процессах).

13.2. Postmortem для S1–S2

Для критических инцидентов нужен короткий разбор:

  • что произошло,
  • почему,
  • как восстановили,
  • что сделаем, чтобы не повторилось,
  • кто ответственный и сроки.

14) Ответственность и финансовая модель: штрафы не спасают, но дисциплинируют

Штрафы сами по себе не делают поддержку качественной. Но они помогают, когда:

  • метрики измеримы,
  • исключения прописаны,
  • вы реально ведёте статистику.

Что обычно прописывают:

  • service credits (скидка, компенсация) при нарушении SLA;
  • лимиты часов и тариф за переработку;
  • исключения: форс-мажор, аварии провайдера, DDoS (и что считается корректной реакцией подрядчика в таких случаях).

15) Чек-лист: 12 пунктов договора, без которых SLA не взлетит

  1. Официальный канал заявок + регламент заполнения.
  2. Матрица критичности S1–S4 с примерами.
  3. Определения «реакция/восстановление/решение».
  4. Часы поддержки, часовой пояс, окна обслуживания.
  5. Правила остановки таймера (ожидание данных, доступов).
  6. Источник правды по простоям (мониторинг, логи).
  7. RPO/RTO + политика бэкапов + тест восстановления.
  8. Регламент изменений и откатов.
  9. Граница «поддержка vs развитие» и процесс оценки задач.
  10. Раздел ответственности за внешние сервисы и интеграции.
  11. Политика доступов и безопасность (RBAC, секреты, аудит).
  12. Отчетность + postmortem по критическим инцидентам.

16) FAQ: вопросы, которые чаще всего задают владельцы сайтов

  1. Что обязательно должно быть в SLA поддержки сайта?
    Единый канал заявок, уровни инцидентов S1–S4, понятные сроки реакции/восстановления/решения, часы поддержки, способ измерения простоя, эскалации, граница «поддержка vs развитие», отчётность и компенсации при нарушениях. Если это нельзя измерить (по тикетам и мониторингу) — это не SLA, а пожелания.
  2. Чем отличается время реакции от времени восстановления и времени решения?
    Время реакции — когда вы получили первый содержательный ответ и началась диагностика. Восстановление — когда сервис снова работает (иногда временно, через обходной путь). Решение — когда устранена причина и инцидент закрыт. Пример: «упала оплата» — реакция 15 минут, восстановление 2 часа, окончательное решение 24 часа.
  3. Что такое уровни S1–S4 и как назначать критичность?
    S1 — сайт/оплата/заказ не работают или массовая недоступность; S2 — критичная функция частично сломана, но бизнес не полностью остановлен; S3 — сбой отдельных сценариев/части пользователей; S4 — косметика и плановые правки. Критичность назначают по влиянию на бизнес, а не по эмоциям: «кнопка Купить не работает у всех» — S1, «ошибка в одном фильтре каталога» — чаще S3.
  4. Как считать простой по SLA, чтобы потом не спорить?
    Нужен заранее выбранный «источник правды»: внешний мониторинг и/или метрики ошибок (5xx, таймауты, доля ошибок). В SLA фиксируют, что именно считается простоем и по какому порогу. Простой пример формулировки: «недоступность = 3 проверки подряд fail с 2 точек мониторинга».
  5. Когда SLA-таймер может ставиться на паузу?
    Только когда подрядчик объективно не может продолжать без действий клиента или третьей стороны, и это зафиксировано в тикете. Типовые причины: ожидание доступов, данных, ожидание подтверждения решения, подтверждённый инцидент у провайдера или внешнего сервиса (с отметкой времени обращения). Если причин паузы нет в договоре — паузы быть не должно.
  6. Кто отвечает, если «упала» оплата, доставка, CRM/1С или другой внешний сервис?
    Подрядчик поддержки отвечает за диагностику, сбор фактов, временные меры на вашей стороне (например, отключить проблемный модуль, включить резервный сценарий) и коммуникацию с провайдером. Но сроки исправления у внешнего сервиса не могут быть гарантированы вашим подрядчиком, если это не отдельный договор/тариф. В SLA это лучше прописывать прямо как зависимость.
  7. Что обязательно прописать про бэкапы, RPO и RTO?
    Частоту и хранение бэкапов, ответственность за проверку, регулярный тест восстановления и целевые RPO/RTO для критичных данных. Формулировка «у нас есть бэкапы» ничего не гарантирует без теста восстановления. Пример: «БД: RPO 15 минут, RTO 2 часа; тест восстановления — раз в квартал».
  8. Как отделить поддержку от развития, чтобы бюджет не утекал?
    Поддержка — восстановление, багфикс, безопасность, эксплуатационные правки в рамках оговорённого перечня. Развитие — новые функции и изменение бизнес-логики, сценариев, интеграций. Простое правило: если меняется поведение системы или добавляется новый сценарий — это развитие и должно оцениваться отдельно. Пример: «починить ошибку оформления заказа» — поддержка, «добавить новый способ доставки» — развитие.
  9. Как SLA связан с релизами и обновлениями CMS?
    Если нет регламента изменений, релизы будут ломать прод, а поддержка превратится в пожарную команду. В приложении фиксируют staging, тестирование, окно выкладки, мониторинг после релиза и понятные правила отката. Минимум: «выкладываем через тестовый контур; при росте 5xx — откат в течение N минут».
  10. Что должно быть в ежемесячном отчёте по SLA?
    Количество инцидентов по S1–S4, фактические времена реакции/восстановления/решения, процент соблюдения SLA, причины, повторяемость и что сделано, чтобы не повторилось. Для S1–S2 почти всегда нужен короткий разбор (что случилось → почему → какие меры → сроки), иначе проблемы будут возвращаться.
  11. Нужны ли компенсации и как их правильно привязывать к SLA?
    Компенсации работают только при измеримых метриках и признанном источнике данных (тикеты + мониторинг). На практике чаще используют service credits (скидка/компенсация в следующем периоде), а не «штрафы ради штрафов». Пример: «нарушено восстановление S1 — кредит X% от месячного платежа».
  12. Какие пункты по безопасности и доступам обязательны в поддержке?
    Роли доступа (RBAC), порядок выдачи и отзыва доступов, хранение секретов (не в чатах), аудит действий администраторов и регламент реагирования на инциденты. Это снижает риск «сломали и не нашли кто» и упрощает расследования.