Сайт лёг в пятницу вечером, в разгар распродажи. Вы пишете подрядчику — тишина. Дозваниваетесь в субботу — «ответим в понедельник, поддержка не работает по выходным». За эти два дня магазин потерял выручку, которую уже не вернуть. И самое обидное — формально подрядчик ничего не нарушил, потому что режим работы поддержки нигде не был зафиксирован.
Эта статья — о том, как сформулировать SLA на поддержку интернет-магазина так, чтобы он защищал бизнес: как задать приоритеты инцидентов, время реакции и решения, доступность, зоны ответственности и метрики. Разберём специфику магазинов на 1С-Битрикс и типовые ошибки. Если поддержка и стабильность магазина вызывают вопросы, начать стоит с аудита и оптимизации текущего решения.
Коротко
- SLA превращает «мы вас поддержим» в измеримые обязательства со сроками.
- Основа SLA — приоритеты инцидентов и для каждого своё время реакции и решения.
- Обязательно фиксируйте доступность, зоны ответственности, RPO/RTO и режим работы.
- Чёткие метрики и разумные компенсации важнее грозных штрафов.
Зачем магазину нужен SLA
SLA (Service Level Agreement) — это соглашение об уровне сервиса. Оно нужно, чтобы обе стороны одинаково понимали, что такое «хорошая поддержка» в измеримых величинах, а не на уровне ощущений. Для магазина, который зарабатывает деньги, простой — это прямой убыток, и SLA определяет, насколько быстро этот убыток остановят.
Без SLA каждый сбой превращается в спор: заказчик считает, что чинить должны немедленно, подрядчик — что «это не срочно» или «это не наша зона». SLA убирает эту неопределённость заранее, до аварии, когда все спокойны и договороспособны. Это документ не про недоверие, а про предсказуемость: он одинаково защищает и заказчика от медленной реакции, и подрядчика от нереалистичных ожиданий.
Из чего состоит SLA
Хороший SLA — это не юридическая простыня, а набор понятных разделов, каждый из которых отвечает на конкретный вопрос бизнеса.
| Раздел SLA | На какой вопрос отвечает |
|---|---|
| Приоритеты инцидентов | Что считать аварией, а что мелочью |
| Время реакции и решения | Как быстро ответят и починят |
| Доступность (uptime) | Сколько простоя допустимо |
| Зоны ответственности | Кто за что отвечает при сбое |
| RPO / RTO | Что с бэкапами и восстановлением |
| Состав поддержки | Что входит, а что оплачивается отдельно |
| Каналы и режим | Куда писать и когда ответят |
| Метрики и компенсации | Как измеряют и что при нарушении |
Разберём ключевые разделы подробнее — именно в них чаще всего кроются недосказанности, которые потом оборачиваются конфликтами.
Приоритеты инцидентов
Фундамент SLA — классификация проблем по влиянию на бизнес. Без неё либо всё чинится одинаково медленно, либо на косметическую правку тратят ресурсы как на аварию. Обычно выделяют три-четыре уровня.
- Критический. Магазин недоступен, не работает оплата или оформление заказа, потеряны данные. Бизнес несёт прямые убытки каждую минуту.
- Высокий. Существенная функция сломана: не грузятся товары, не идёт обмен с 1С, не отправляются письма. Магазин работает, но с потерями.
- Средний. Локальная проблема, есть обходной путь: криво отображается блок, сбоит второстепенная функция.
- Низкий. Косметика, мелкие правки, пожелания. Не влияет на продажи.
Важно описать критерии словами и примерами, а не только названиями. Тогда при инциденте не придётся спорить, критичный он или высокий, — определение уже согласовано.
Время реакции и время решения
Для каждого приоритета в SLA задают два разных срока — и их часто путают. Время реакции — за сколько подрядчик подтвердит, что взял заявку в работу. Время решения — за сколько проблему фактически устранят.
| Приоритет | Время реакции | Время решения (ориентир) |
|---|---|---|
| Критический | 15–30 минут | до 2–4 часов |
| Высокий | 1–2 часа | до 1 рабочего дня |
| Средний | до 1 рабочего дня | 2–5 рабочих дней |
| Низкий | 1–2 рабочих дня | по договорённости |
Цифры в таблице — ориентир; реальные значения зависят от масштаба магазина и цены поддержки. Круглосуточная реакция за 15 минут стоит дороже, чем реакция в рабочие часы. Важно, чтобы сроки были реалистичны: невыполнимый SLA хуже, чем честный.
Доступность: uptime и как его считать
Доступность показывает долю времени, когда сайт работает. Разница между красивыми цифрами больше, чем кажется:
- 99,9% — около 43 минут простоя в месяц.
- 99,5% — примерно 3,6 часа в месяц.
- 99% — около 7,2 часа в месяц.
Ключевое — не сама цифра, а как её измеряют. SLA должен определять: что считается простоем (недоступность главной? оформления заказа?), кто и чем измеряет (внешний мониторинг), исключаются ли плановые работы, о которых предупредили заранее. Без этих оговорок «99,9%» — просто маркетинговая фраза. Высокая доступность упирается в инфраструктуру: как устроен надёжный хостинг для Битрикс, разобрано в статье о хостинге и BitrixVM.
Зоны ответственности
Самый частый источник конфликтов при сбое — вопрос «чья это проблема». Магазин на 1С-Битрикс живёт в связке из нескольких слоёв, и ответственность за них может лежать на разных сторонах.
- Хостинг и дата-центр. Железо, сеть, питание. Часто это отдельный провайдер со своим SLA.
- Системное ПО. Веб-сервер, база данных, окружение BitrixVM.
- Код и настройки сайта. Ядро Битрикс, компоненты, кастомная разработка — зона подрядчика.
- Внешние сервисы. Платёжные системы, службы доставки, обмен с 1С.
- Действия заказчика. Правки контента, изменения в админке, установка модулей.
SLA должен разграничить, за что отвечает подрядчик напрямую, а где он лишь эскалирует и координирует (например, при проблеме на стороне хостинга). Тогда при аварии не будет спора, а будет понятный план: кто что делает.
RPO и RTO: бэкапы и восстановление
Обещание «у нас есть бэкапы» без цифр ничего не гарантирует. За надёжностью стоят два параметра:
- RPO (Recovery Point Objective) — максимально допустимая потеря данных. Если бэкап делается раз в сутки, вы рискуете потерять до суток заказов. Для активного магазина RPO измеряют часами, а базу заказов бэкапят чаще.
- RTO (Recovery Time Objective) — за какое время магазин поднимут после сбоя. Свежий бэкап бесполезен, если разворачивать его будут сутки.
Эти показатели определяют требования к резервному копированию и процедуре восстановления, и их стоит проверять учебными восстановлениями. Надёжность деплоя и отката изменений тоже часть этой темы — про безопасный выпуск обновлений без простоев есть материал про CI/CD и деплой на Битрикс.
Что входит в поддержку, а что нет
Расплывчатое «поддержка сайта» — источник взаимных обид. Одна сторона ждёт, что в абонемент входит любая доработка, другая считает поддержкой только устранение сбоев. SLA должен явно разделить.
- Входит в абонемент. Мониторинг, устранение сбоев, обновления безопасности, консультации, мелкие правки в оговорённом объёме.
- Оплачивается отдельно. Новый функционал, крупные доработки, редизайн, интеграции с новыми системами.
- Серая зона — описать явно. Правки контента, наполнение каталога, настройка акций: определить, кто это делает и на каких условиях.
Часто удобна модель «абонемент + банк часов»: базовые обязательства покрыты фиксированной платой, а сверх — из пакета часов. Главное, чтобы граница была прописана заранее.
Каналы, режим работы и эскалация
SLA должен ответить, куда обращаться и когда ждать ответа. Здесь важны конкретика и отсутствие «серых» ситуаций вроде той аварии в пятницу вечером.
- Каналы обращения. Тикет-система, почта, телефон для критичных случаев — с указанием, какой канал для какого приоритета.
- Режим работы. Рабочие часы поддержки и отдельно — режим для критичных инцидентов (например, 24/7 для аварий, рабочие часы для остального).
- Эскалация. Что делать, если сроки нарушаются: к кому обращаться, как поднять приоритет.
- Единая точка входа. Понятно, кто со стороны подрядчика отвечает за заявку.
Метрики, отчётность и компенсации
SLA работает, только если выполнение измеряется. Иначе обязательства остаются на бумаге. Поэтому в документе фиксируют, какие метрики отслеживаются и как отчитываются.
- Метрики. Фактическое время реакции и решения по приоритетам, достигнутая доступность, число инцидентов.
- Отчётность. Регулярный отчёт (например, ежемесячный) с фактом против обязательств.
- Компенсации. Перерасчёт платы или сервисные кредиты за нарушение — соразмерные и реалистичные.
Про компенсации важно понимать: их цель — стимул держать уровень, а не наказание. Чрезмерные штрафы либо отпугивают адекватных подрядчиков, либо закладываются в цену. Разумный SLA мотивирует, а не превращает сотрудничество в тяжбу.
SLA для 1С-Битрикс: специфика
У магазина на 1С-Битрикс есть особенности, которые стоит отразить в SLA отдельно.
- Обмен с 1С. Обмен CommerceML — критичный процесс: сбой обмена рвёт актуальность цен, остатков и заказов. Его мониторинг и сроки восстановления часто выносят в SLA отдельно.
- Обновления ядра и модулей. Порядок установки обновлений, тестовый контур, окно работ — чтобы обновление не уронило продакшн.
- Лицензия и продление. Кто следит за активной лицензией Битрикс и её продлением.
- Композит и кэш. Ответственность за корректную работу кэширования и композитного сайта, чтобы производительность не деградировала.
Чем сложнее интеграционный ландшафт, тем важнее прописать SLA на стыки систем. Как безопасно устроен обмен через API, разобрано в статье про REST, вебхуки и безопасность, а надёжность самой цепочки заказ–склад обеспечивает автоматизация продаж и склада на 1С.
Частые ошибки при составлении SLA
- Нет приоритетов. Всё чинится «в порядке очереди», авария ждёт наравне с косметикой.
- Путают реакцию и решение. Обещают «ответ за 15 минут», но не говорят, когда починят.
- Доступность без методики. «99,9%» без определения простоя и способа измерения.
- Не разграничены зоны. При сбое спорят, чья это проблема — подрядчика или хостинга.
- Нет RPO/RTO. «Есть бэкапы» без частоты и времени восстановления.
- Размытый состав поддержки. Непонятно, что входит в абонемент, а что нет.
- Нереалистичные сроки. Красивые цифры, которые заведомо невыполнимы.
- Драконовские штрафы. Санкции, которые отпугивают или закладываются в цену.
Чек-лист SLA
- Приоритеты описаны. Уровни инцидентов заданы словами и примерами.
- Сроки разделены. Время реакции и решения указаны отдельно для каждого приоритета.
- Доступность измерима. Определены простой, метод измерения и исключения.
- Зоны разграничены. Понятно, за что отвечает подрядчик, хостинг и заказчик.
- RPO и RTO заданы. Частота бэкапов и время восстановления зафиксированы.
- Состав поддержки ясен. Что входит, что отдельно, серые зоны описаны.
- Каналы и режим прописаны. Куда писать, когда отвечают, как эскалировать.
- Метрики и отчётность есть. Как измеряют выполнение и какие компенсации при нарушении.
Вывод
SLA — это перевод обещаний о поддержке на язык измеримых обязательств. Он не нужен, пока всё работает, и становится бесценным в момент аварии: когда сайт лежит, спорить о сроках и зонах ответственности уже поздно. Хороший SLA задаёт приоритеты, разделяет время реакции и решения, честно определяет доступность и разграничивает зоны — и делает поведение подрядчика предсказуемым.
Составляйте SLA реалистичным: невыполнимые сроки и грозные штрафы хуже честных обязательств, которые действительно соблюдаются. Учтите специфику 1С-Битрикс — обмен, обновления, композит — и подкрепите документ реальной инфраструктурой и автоматизацией. Тогда SLA станет не формальностью, а инструментом, который защищает выручку магазина в самые критичные моменты.
