«Поддержка в рабочее время» — фраза, которая встречается почти в каждом договоре на сопровождение сайта, и почти ничего не гарантирует. Что считается «рабочим временем», за сколько минут отреагируют на упавший сайт, кто отвечает, если после планового обновления пропали заказы, — без ответов на эти вопросы договор остаётся набором благих намерений, а не работающим соглашением.
Мы много лет сопровождаем сайты на 1С-Битрикс по SLA и регулярно видим, во что превращается поддержка без чётких уровней обслуживания — от многодневного ожидания реакции на критичный сбой до споров, кто виноват в потере данных после неудачного обновления. Ниже — из чего должен состоять нормальный SLA и на какие формулировки в договоре смотреть внимательно, прежде чем подписывать.
Коротко
- SLA должен содержать уровни критичности инцидентов с конкретными сроками реакции и устранения — не «в разумные сроки».
- Явно разделяйте, что входит в абонентскую плату (мониторинг, инциденты, плановые обновления), а что оплачивается отдельно (новая функциональность, экстренные работы вне лимита).
- Проверьте порядок эскалации, ответственность за резервные копии и откат при неудачном обновлении.
- Отдельно читайте условия автопродления — незаметный переход на новый период без пересмотра тарифа — частая ловушка договоров на сопровождение.
Зачем нужен SLA, если и так есть договор на поддержку
Обычный договор на техническую поддержку почти всегда описывает состав работ («устраняем ошибки, консультируем, обновляем») без измеримых обязательств по времени. Формулировка «реагируем в кратчайшие сроки» юридически не значит ничего конкретного: и час, и три дня формально укладываются в «кратчайшие сроки» без нарушения договора. SLA — это раздел (или отдельное приложение к договору), который переводит эти намерения в измеримые цифры: конкретное время реакции и устранения по каждому уровню критичности инцидента, и конкретные последствия для подрядчика при их нарушении.
Разница ощущается ровно в момент, когда что-то ломается. С SLA заказчик заранее знает, сколько времени пройдёт от обращения до первой реакции специалиста и до решения проблемы, и может планировать вокруг этого — например, предупредить клиентов о временной недоступности заказа через сайт. Без SLA единственный ориентир — репутация подрядчика, которая ничего не гарантирует в конкретной аварийной ситуации.
Уровни критичности инцидентов
Фундамент любого рабочего SLA — деление инцидентов на уровни критичности с разными сроками обслуживания. Практический минимум для сайта на 1С-Битрикс — три уровня.
- Критичный. Сайт полностью недоступен, не работает оформление заказа или приём оплаты, произошла утечка данных. Прямые финансовые потери каждую минуту простоя.
- Значимый. Не работает важная, но не блокирующая продажи функция: личный кабинет, форма обратной связи, часть каталога, интеграция с CRM отдаёт ошибки.
- Незначительный. Косметические дефекты вёрстки, опечатки, некритичные сбои, не влияющие на конверсию и продажи напрямую.
Для крупных проектов с высокой ценой простоя оправдано более детальное деление — например, выделение отдельного уровня для инцидентов, затрагивающих только часть пользователей (проблема на мобильной версии) в отличие от полной недоступности. Но даже базовые три уровня — это несопоставимо лучше, чем единая категория «проблема», куда попадает и упавший сайт, и опечатка в тексте, с одинаковым, размытым сроком реакции.
Время реакции и время устранения — разные метрики
Частая путаница в договорах — смешение «времени реакции» и «времени устранения». Это принципиально разные метрики, и SLA должен фиксировать обе отдельно. Время реакции — сколько проходит от обращения заказчика до того, как специалист поддержки взял инцидент в работу и подтвердил это (не просто получил заявку автоматической системой, а именно приступил к диагностике). Время устранения — сколько проходит до фактического решения проблемы.
Для критичного инцидента разумный ориентир — реакция в течение 15–30 минут и устранение (или хотя бы временное восстановление работоспособности) в течение 1–4 часов, в зависимости от сложности сбоя. Для значимого — реакция в течение нескольких часов, устранение в течение рабочего дня. Для незначительного — сроки можно измерять днями. Конкретные цифры зависят от специфики бизнеса и стоимости простоя, но сам принцип разделения двух метрик должен быть в SLA всегда.
Что обычно входит в абонентскую плату
Стандартный состав работ по абонентской технической поддержке сайта на 1С-Битрикс включает: мониторинг доступности сайта (обычно автоматический, с уведомлением при сбое), обработку и устранение инцидентов в рамках заявленных сроков SLA, плановые обновления ядра платформы и модулей безопасности, регулярное резервное копирование, консультации по работе с админкой в пределах оговорённого количества часов в месяц.
Разные подрядчики и тарифы по-разному определяют границы «абонентки» — поэтому важно, чтобы состав работ был перечислен в договоре явным списком, а не общей формулировкой «техническая поддержка сайта». Общая практика по тарифным планам техподдержки — с примерами того, что реально входит в разные уровни обслуживания, — доступна в новости о новом тарифе техподдержки студии.
Что оплачивается отдельно от абонентки
Не менее важно заранее понимать, что в абонентскую плату не входит — иначе первый же счёт за «доп. работы» становится неприятным сюрпризом. Обычно отдельно оплачивается: разработка новой функциональности (новый раздел, новая интеграция, доработка каталога), значительная переработка существующих модулей, экстренные работы вне обычного рабочего времени сверх оговорённого лимита часов, и восстановление данных, утраченных из-за действий самого заказчика — например, случайного удаления раздела через админку без резервной копии.
Хороший договор прямо перечисляет обе категории — что входит и что не входит — в одном разделе, чтобы не было двусмысленности на стыке. Плохой договор описывает только состав абонентки в общих словах, оставляя границу с дополнительными работами на усмотрение подрядчика в конкретной ситуации.
Эскалация: что происходит, если первая линия не справляется
Инцидент не всегда решается на уровне первой линии поддержки — иногда нужен разработчик, который писал конкретный модуль, или даже вендор платформы. SLA должен описывать процедуру эскалации: через сколько времени бездействия или безуспешных попыток первой линии инцидент автоматически передаётся более квалифицированному специалисту, и кто конкретно (по должности или роли, а не поимённо) отвечает за критичные инциденты вне рабочего времени.
Отсутствие описанной эскалации — один из самых частых пробелов в договорах на поддержку. На практике это означает, что при сложном инциденте заказчик может неделями «застрять» на уровне первой линии, которая честно пытается, но не обладает достаточной квалификацией для конкретной проблемы, а формальных оснований требовать подключения более сильного специалиста в договоре нет.
Мониторинг и обязательства по доступности (uptime)
Часть договоров включает обязательства по проценту доступности сайта (uptime) — например, 99,5% в месяц. Это разумная метрика, но важно проверить два нюанса: во-первых, входит ли в это обязательство время, зависящее не от подрядчика (сбои хостинга, DDoS-атаки, форс-мажор), — обычно такое время исключается из расчёта, и это нормально, если прописано явно. Во-вторых, как именно измеряется доступность — автоматическим внешним мониторингом с публичным доступом к отчётам заказчика, или только внутренними логами подрядчика, которым остаётся просто верить на слово.
Практика внешнего независимого мониторинга (сторонний сервис проверки доступности, отчёты которого доступны заказчику) заметно надёжнее внутренней отчётности — она снимает саму возможность спора о том, действительно ли сайт был недоступен и как долго.
Резервные копии и откат: кто отвечает
Это один из самых недооценённых пунктов договора на поддержку. Нужно чётко зафиксировать: как часто делаются резервные копии, где они хранятся (и не на том же сервере, что и сам сайт — иначе одна авария уничтожает и сайт, и его копии), сколько версий хранится и на какой срок, и — главное — что происходит, если после планового обновления модуля или ядра платформы что-то ломается. Есть ли у подрядчика обязательство протестировать обновление на копии перед применением на боевом сайте, и кто отвечает за откат, если обновление всё же привело к сбою.
Формулировки договора, на которые стоит обратить внимание
Помимо структурных пробелов (нет уровней критичности, нет эскалации), есть конкретные словесные формулировки, которые на практике почти всегда работают против заказчика.
- «В разумные сроки», «в кратчайшие сроки», «оперативно». Любая формулировка без конкретной цифры (минуты, часы, рабочие дни) юридически не гарантирует ничего измеримого.
- «Поддержка в рабочее время» без уточнения часового пояса и календаря. Особенно важно для сайтов с федеральной аудиторией в разных часовых поясах — инцидент вечером по местному времени клиента может формально оказаться «не рабочим временем» подрядчика.
- «Работы выполняются по мере возможности». Формулировка, снимающая с подрядчика фактически любые обязательства по срокам.
- Расплывчатое описание состава работ без конкретного перечня. Оставляет пространство для споров о том, что входит в абонентку, а что — дополнительная услуга.
Ловушка автопродления и скрытых условий
Отдельная категория риска — не про качество поддержки, а про условия самого договора. Автоматическое продление на следующий период без явного уведомления и права легко отказаться — распространённая практика, которая усложняет смену подрядчика даже при систематическом нарушении SLA. Стоит проверить: за сколько дней до продления должно прийти уведомление, есть ли простой механизм отказа от продления без штрафов, и не меняются ли тарифы при автопродлении без отдельного согласования.
Похожая ловушка — привязка минимального срока действия договора к невыгодным условиям расторжения: например, штраф за досрочный отказ, значительно превышающий разумную компенсацию уже выполненных работ. Такие условия не всегда означают недобросовестность подрядчика, но их стоит явно обсудить до подписания, а не обнаруживать постфактум.
Пример уровней SLA: сроки по критичности
Ниже — ориентировочные сроки для интернет-магазина или корпоративного сайта среднего размера. Конкретные цифры в вашем договоре могут отличаться в зависимости от стоимости простоя и тарифа, но структура (три уровня с разными сроками реакции и устранения) должна быть похожей.
| Уровень | Пример инцидента | Время реакции | Время устранения |
|---|---|---|---|
| Критичный | Сайт недоступен, не проходят оплаты | 15–30 минут | 1–4 часа |
| Значимый | Не работает личный кабинет или форма заявки | 1–4 часа | В течение рабочего дня |
| Незначительный | Косметический дефект вёрстки | 1 рабочий день | 3–5 рабочих дней |
Помимо сроков реакции и устранения, в договоре стоит зафиксировать и то, что происходит при нарушении этих сроков — иначе цифры в таблице остаются декларацией без последствий. Обычная практика — компенсация в виде скидки на следующий период обслуживания или дополнительных часов работ пропорционально просрочке.
Реализация в 1С-Битрикс: что мониторит поддержка на практике
На стороне 1С-Битрикс у поддержки по SLA обычно есть несколько технических точек контроля: журнал событий и монитор качества (модуль контроля ошибок ядра), уведомления об ошибках PHP и сбоях внешних интеграций (обмен с 1С, платёжные системы), автоматическое резервное копирование через штатный модуль или внешний скрипт, и мониторинг доступности через внешний сервис, независимый от самого хостинга сайта.
Частые ошибки при выборе договора поддержки
- Подписывают договор с формулировками «в разумные сроки» без конкретных цифр по времени реакции и устранения.
- Не разделяют инциденты по уровням критичности — упавший сайт и опечатка в тексте обрабатываются по одному и тому же сроку.
- Не уточняют заранее, что входит в абонентку, а что оплачивается отдельно — и получают неожиданные счета за «доп. работы».
- Не проверяют, кто отвечает за резервные копии и откат после неудачного обновления ядра или модулей.
- Пропускают условия автопродления договора и обнаруживают невыгодный тариф уже после его вступления в силу.
- Не фиксируют порядок эскалации — и застревают на уровне первой линии поддержки при сложном инциденте.
- Выбирают подрядчика только по цене абонентки, не сравнивая реальные сроки SLA между предложениями разных студий.
- Не сохраняют историю обращений и фактического времени реакции — без этой документации трудно доказать систематическое нарушение SLA.
Чек-лист: что проверить перед подписанием SLA
- Проверьте уровни критичности инцидентов. Минимум три уровня с конкретными сроками реакции и устранения по каждому.
- Уточните границу абонентки. Явный список того, что входит в плату, и того, что оплачивается отдельно.
- Найдите порядок эскалации. Что происходит, если первая линия поддержки не справляется с инцидентом.
- Проверьте ответственность за резервные копии. Частота, место хранения, кто отвечает за откат после неудачного обновления.
- Оцените обязательства по доступности. Есть ли uptime-гарантия и как именно измеряется — внешним независимым мониторингом или только внутренней отчётностью.
- Прочитайте условия автопродления. Срок уведомления, простота отказа, возможность изменения тарифа без согласования.
- Зафиксируйте компенсацию за нарушение сроков. Что получает заказчик, если подрядчик не уложился в заявленное время SLA.
Если поддержка сайта уже отдана на аутсорс без чётких уровней обслуживания — стоит сравнить, что предлагают разные форматы: от базовой абонентской поддержки 1С-Битрикс до полноценного договора с зафиксированным SLA. Полный список форматов и тарифов техподдержки — в разделе «Поддержка сайтов на 1С-Битрикс».
Вывод
Нормальный SLA техподдержки сайта на 1С-Битрикс — это не формальность, а конкретный набор измеримых обязательств: уровни критичности инцидентов с чёткими сроками реакции и устранения, явная граница между абонентской платой и дополнительными работами, описанный порядок эскалации и понятная ответственность за резервные копии. Формулировки вроде «в разумные сроки» без конкретики — сигнал, что договор нужно доработать до подписания, а не подписывать в надежде на добросовестность подрядчика по умолчанию.
