Чем сопровождение сайта на «1С-Битрикс» отличается от сопровождения обычного сайта
Сайт на «1С-Битрикс» редко бывает просто витриной. Обычно это система, где сходятся каталог, корзина, личный кабинет, обмен с 1С, интеграция с CRM и десяток внешних сервисов. Когда такой сайт падает или отдаёт страницы за десять секунд, компания теряет не «место в интернете», а поток заявок — здесь и сейчас, в деньгах.
Отсюда и разница в подходе. Простой лендинг можно чинить по факту: сломалось — написали разработчику, он посмотрел, когда освободится. Портал или интернет-магазин так сопровождать нельзя: цена простоя измеряется часами работы отдела продаж и упущенной выручкой. Нужна не «помощь по возможности», а зафиксированный уровень услуги — то, что в договоре называется SLA (Service Level Agreement, соглашение об уровне сервиса).
Проблема в том, что слово SLA встречается в коммерческих предложениях почти у всех, а внятного содержания за ним стоит далеко не всегда. Часто это две строки: «реакция в течение 24 часов, работы в будни с 9 до 18». Такой SLA не защищает ни от чего — он не отвечает, что считается инцидентом, кто виноват, если проблема на стороне хостинга, и кто платит за восстановление после взлома. Дальше по пунктам — то, что реально должно быть в таком соглашении, если вы заказываете техподдержку 1С-Битрикс.
Что такое SLA и зачем он нужен бизнесу, а не только айтишникам
SLA — это часть договора, которая переводит расплывчатое «мы вас поддержим» в измеримые обязательства: за сколько минут подрядчик обязан ответить, за сколько — устранить критичный сбой, в какие часы он на связи, что именно входит в абонентскую плату, а что оплачивается отдельно, и какая ответственность наступает при нарушении сроков.
Для руководителя ценность SLA не в красоте формулировок, а в предсказуемости. Когда уровень сервиса зафиксирован, можно планировать: закладывать в бюджет сопровождение, обещать клиентам стабильный личный кабинет, запускать рекламу, не опасаясь, что в пик трафика сайт ляжет и никто не поднимет трубку. Плюс это инструмент управления подрядчиком: без него спор упирается в «мы же старались», с ним — в цифры из отчёта.
Хороший признак: документ понятен и техническому директору, и коммерческому. Если в нём нет ни одного числа — это маркетинг, а не соглашение.
Границы ответственности: что входит в поддержку, а что нет
Первое, что должно быть описано в SLA до всех сроков и приоритетов, — периметр. Кто за что отвечает.
Типовой сайт на «1С-Битрикс» живёт в четырёхслойной конструкции: хостинг или сервер, серверное окружение (PHP, база данных, веб-сервер), ядро «1С-Битрикс» с модулями, и поверх — кастомный код, шаблоны, компоненты и интеграции. Плюс внешние сервисы: платёжный шлюз, служба доставки, CRM, коллтрекинг, сервис рассылок. Инцидент может возникнуть в любом слое, и без явной границы каждая авария превращается в перекладывание ответственности.
В договоре имеет смысл прямо перечислить:
- Что подрядчик обслуживает полностью — например, ядро и модули системы, кастомный код, шаблоны, интеграции, которые он же и разрабатывал.
- Что подрядчик диагностирует, но чинит через третью сторону — сбои на стороне хостинга, недоступность платёжного шлюза, изменения API внешнего сервиса. Здесь обязательство должно звучать как «локализовать причину за N часов и эскалировать провайдеру», а не как «восстановить работу».
- Что не входит вообще — например, наполнение контентом, доработка нового функционала, SEO, дизайн новых разделов. Это отдельные работы, и лучше сразу зафиксировать, по какой ставке и в каком порядке они заказываются.
Отдельно проговорите доступы: если у подрядчика нет прав на перезапуск сервисов, требовать от него восстановления за час бессмысленно. Уровень SLA всегда согласуется с уровнем полномочий.
Время реакции и время решения — это разные обязательства
Самая частая подмена в договорах на техподдержку 1С-Битрикс: подрядчик обещает «реакцию за 2 часа», клиент читает это как «починят за 2 часа». Это разные вещи, и в SLA они должны быть разведены явно.
Время реакции — интервал от регистрации обращения до момента, когда с задачей начал работать живой инженер и заказчик получил подтверждение. Это дисциплина, а не решение проблемы.
Время решения (или время восстановления) — интервал до момента, когда сервис снова работает. Здесь допустимо разделять полное решение и обходное: если критичную функцию можно временно вернуть заглушкой или откатом релиза, это уже восстановление сервиса, а корневая причина устраняется в следующем окне.
Честный SLA даёт время решения не по всем классам задач: по инцидентам — да, по доработкам — нет, там уместнее оценка трудозатрат по каждой задаче. Обещание фиксированного срока решения для любого обращения — будущий конфликт.
Классификация обращений и приоритеты
Чтобы сроки имели смысл, обращения нужно разделить по критичности — иначе «сайт не открывается» и «поправьте отступ в футере» попадут в одну очередь.
Рабочая схема для сайта на «1С-Битрикс» обычно выглядит так:
- Критический (P1). Сайт недоступен целиком, не работает оформление заказа или оплата, не проходят заявки с форм, ядро выдаёт фатальную ошибку, обнаружено заражение или утечка. Бизнес несёт прямые потери каждую минуту.
- Высокий (P2). Сайт работает, но сломан существенный сценарий: не отдаётся часть каталога, не отрабатывает обмен с 1С, не уходят письма о заказе, личный кабинет доступен не всем.
- Средний (P3). Локальные дефекты без потери денег: некорректная вёрстка на отдельном разрешении, ошибка в фильтре, неверная сортировка.
- Низкий (P4) и запросы на изменение. Правки контента, косметика, мелкие улучшения, консультации.
Под каждый приоритет прописываются свои цифры реакции и решения. Важная деталь, о которой забывают: в SLA нужно указать, кто присваивает приоритет. Оптимально — заказчик заявляет, подрядчик подтверждает или мотивированно понижает, и спорные случаи трактуются в пользу более высокого приоритета до выяснения. Иначе любой P1 будет тихо переклассифицирован в P3.
Режим работы, каналы обращений и эскалация
Дальше — расписание. «Будни 9:00 — 18:00» для магазина, у которого пик заказов приходится на вечер и выходные, означает, что субботняя авария подождёт до понедельника. Обсудить стоит расширенное рабочее окно, дежурство по критическим инцидентам вне графика, режим 24/7 для P1. Каждый вариант влияет на стоимость — плохо, когда режим не оговорён вовсе.
Каналы обращений должны быть учитываемыми. Личный мессенджер конкретного разработчика — не канал: сообщения теряются, история не восстанавливается, в отпуске никто не подхватит. Рабочая схема — тикет-система или задачи в CRM подрядчика, где каждое обращение имеет номер, автора, время регистрации и историю.
И третий обязательный элемент — процедура эскалации: что делает заказчик, если инженер не отвечает или срок горит. В SLA прописывается вторая линия и контакт руководителя с телефоном. Пункт кажется формальным ровно до первого случая, когда ответственный сотрудник подрядчика оказался недоступен в момент аварии.
Обновления ядра и продление лицензии: отдельный пункт договора
Это специфика именно «1С-Битрикс», и её нужно выносить в SLA явно. Лицензия «1С-Битрикс: Управление сайтом» включает год технической поддержки вендора и доступа к обновлениям с момента регистрации. По истечении этого срока сайт продолжает работать, но новые обновления становятся недоступны — чтобы их получать дальше, лицензию на обновления нужно продлевать.
Обновления ставятся через административный раздел «Обновление платформы» по технологии SiteUpdate. Звучит просто, но на практике обновление продакшн-сайта с кастомными доработками — это отдельная процедура, а не нажатие кнопки. Поэтому в SLA стоит зафиксировать:
- кто отслеживает выход обновлений и уведомляет о критичных, в первую очередь связанных с безопасностью;
- что обновление сначала ставится на копию сайта (тестовый контур), а не сразу на боевой;
- что перед обновлением делается резервная копия и определён порядок отката;
- в какое окно проводятся работы — например, в часы минимального трафика, с предварительным уведомлением;
- кто и в какие сроки напоминает о продлении лицензии, чтобы оно не всплыло внезапно в момент, когда обновление уже нужно.
Разные редакции продукта — «Первый сайт», «Старт», «Стандарт», «Малый бизнес», «Эксперт», «Бизнес», «Энтерпрайз» — отличаются набором модулей, и это влияет на объём сопровождения: то, что в старшей редакции решается штатным модулем, в младшей приходится закрывать доработкой. Полезно, чтобы в договоре была зафиксирована редакция, под которую считался SLA.
Резервные копии: RPO, RTO и проверка восстановления
Пункт про бэкапы есть почти в каждом договоре и почти всегда бесполезен, потому что звучит как «выполняется резервное копирование». Из этой фразы не следует ни частота, ни глубина хранения, ни место, ни обязательство восстановиться.
В «1С-Битрикс» резервное копирование доступно штатно, в разделе «Настройки → Инструменты → Резервное копирование». Копию можно разместить локально в папке сайта, в облаке «1С-Битрикс» или в стороннем облачном хранилище; локальные копии складываются в служебную папку сайта. При использовании облака «1С-Битрикс» для каждой лицензии хранятся три последние копии, а более старые удаляются автоматически; копии шифруются паролем, который задаёт сам пользователь. Регулярное копирование настраивается по расписанию, минимальная частота — раз в сутки.
Из этих возможностей в SLA нужно превратить конкретику. Две ключевые метрики:
- RPO — какой объём данных допустимо потерять. Если копия снимается раз в сутки ночью, то при аварии в 18:00 вы теряете рабочий день заказов. Для магазина это часто неприемлемо, и тогда нужны либо более частые копии, либо репликация базы.
- RTO — за сколько подрядчик обязан развернуть сайт из копии. Именно обязан, с цифрой в договоре.
И главное — периодическая проверка. Копия, которая ни разу не разворачивалась, существует только на бумаге: битый архив обнаруживается ровно тогда, когда он нужен. Разумная практика — тестовое восстановление на отдельный контур с фиксированной регулярностью и коротким отчётом. Хранить копии только на том же сервере, где живёт сайт, нельзя: при отказе диска вы теряете и сайт, и бэкапы.
Безопасность: что подрядчик обязан делать до инцидента
В «1С-Битрикс» встроен модуль «Проактивная защита» — комплекс средств, включающий проактивный фильтр (по сути межсетевой экран уровня веб-приложений), веб-антивирус, панель безопасности и сканер безопасности. Уровень защиты выбирается из нескольких предустановленных: стандартный, высокий, повышенный.
Сам по себе модуль ничего не гарантирует, если он не настроен. Поэтому в SLA стоит описать регулярные, а не только аварийные обязательства: какой уровень безопасности поддерживается, как контролируются права административных учётных записей, кто и как быстро реагирует на уведомления об уязвимостях в решениях Маркетплейса.
Отдельно — сценарий компрометации. Заражение сайта не равно обычному сбою: нужно изолировать проблему, найти точку входа, вычистить код, сменить доступы, восстановить чистую версию и убедиться, что закладка не вернулась. Эти работы дороже рутины, и в договоре должно быть написано, входят ли они в абонемент, оплачиваются ли отдельно и по какой ставке. Если этого пункта нет, обсуждать цену вы будете в самый неудачный момент — когда сайт уже помечен в поиске как опасный.
Производительность как измеримое обязательство
Медленный сайт не выглядит аварией, но по деньгам часто дороже разовых падений: он режет конверсию и ухудшает позиции в поиске. Поэтому производительность стоит выносить в SLA отдельным блоком с числами.
В «1С-Битрикс» для этого есть штатный инструментарий — модуль «Монитор производительности» с панелью производительности, разбором по страницам, хитам, компонентам, SQL-запросам, кешированию, анализом индексов, историей замеров и списком ошибок PHP. Плюс раздел «Настройки → Инструменты → Проверка системы», который проверяет соответствие окружения требованиям продукта и включает тестирование конфигурации сервера, а также утилиты диагностики базы данных.
Что из этого превращается в обязательства: ежемесячный замер по фиксированному набору ключевых страниц, отчёт с динамикой, порог, при пересечении которого подрядчик обязан инициировать работы, и контроль журнала ошибок PHP — накопление однотипных ошибок обычно предвещает аварию. Такой пункт делает поддержку профилактической, а не реактивной.
Отчётность и ответственность за нарушение
SLA без отчётности — это обещание без проверки. В договоре должно быть указано, что заказчик получает регулярный отчёт: список обращений с приоритетами, фактические время реакции и решения, процент соблюдения нормативов, объём выработанных часов, перечень профилактических работ. Формат вторичен, важна регулярность и то, что данные берутся из системы учёта, а не пишутся по памяти.
Дальше — последствия. Реалистичные механизмы обычно такие: перерасчёт абонентской платы за период, начисление дополнительных часов в следующем месяце, право расторжения без штрафа при систематическом нарушении. Формулировки вроде «подрядчик прилагает разумные усилия» не значат ничего.
Полезно оговорить и исключения, при которых сроки не действуют: форс-мажор, авария у хостинг-провайдера, DDoS-атака выше согласованного порога, отсутствие доступов по вине заказчика, правки, внесённые в код сторонними подрядчиками. Это защищает обе стороны и делает документ рабочим.
Как это выглядит на практике
Приведём иллюстративный пример — обобщённая ситуация, а не описание конкретного клиента. Оптовая компания с интернет-магазином на «1С-Битрикс» работала с подрядчиком по договору «поддержка по запросу, реакция в течение рабочего дня». В пятницу вечером перестал проходить обмен с 1С: заказы с сайта не попадали в учётную систему. Заметили в понедельник, подрядчик отреагировал во вторник, причину нашли в среду — обновление на стороне 1С изменило формат выгрузки. Итог: три дня заказов разбирали вручную, часть клиентов ушла.
Что изменил бы нормальный SLA. Во-первых, сбой обмена был бы заранее отнесён к высокому приоритету — с реакцией в часах, а не «в течение рабочего дня». Во-вторых, в перечень профилактики вошёл бы мониторинг результата обмена с уведомлением при ошибке, и проблему увидели бы в пятницу, а не в понедельник. В-третьих, была бы прописана процедура эскалации, и обращение не зависло бы у одного занятого инженера. Стоимость такого сопровождения выше, чем «по запросу», но она сопоставима с выручкой одного потерянного дня.
Именно поэтому мы в B2BPRO.KZ строим сопровождение вокруг измеримых обязательств, а не вокруг абстрактной «поддержки»: фиксируем приоритеты, сроки, регламент обновлений и бэкапов, ведём учёт обращений и отчитываемся цифрами. Если вам нужен сайт на «1С-Битрикс», который делают и сопровождают по такой логике, посмотрите наши услуги по разработке и поддержке сайтов — мы работаем и с проектами, которые вели другие команды, начиная с аудита текущего состояния.
Чек-лист: что проверить в договоре перед подписанием
- Перечислены слои и системы, за которые отвечает подрядчик, и явно указано, что вне периметра.
- Разведены время реакции и время решения, по каждому приоритету есть цифры.
- Описаны классы обращений и порядок присвоения приоритета, включая спорные случаи.
- Указан режим работы, в том числе по критическим инцидентам вне рабочих часов.
- Назван канал регистрации обращений с учётом и историей, а не личный мессенджер.
- Прописана эскалация: вторая линия и контакт руководителя.
- Есть регламент обновлений ядра: тестовый контур, бэкап перед работами, окно, откат.
- Зафиксировано, кто следит за сроком лицензии на обновления и заранее предупреждает о продлении.
- По бэкапам указаны частота, глубина хранения, место (не только тот же сервер), RPO и RTO.
- Есть регулярная проверка восстановления копии, а не только её создание.
- Описаны профилактика безопасности и отдельный порядок работ при компрометации сайта.
- Есть измеримые обязательства по производительности и регулярная отчётность с последствиями за нарушение сроков.
Если из двенадцати пунктов в предложенном договоре закрыты два-три, это не поддержка, а разовые работы с абонентской платой.
Частые вопросы
Чем техподдержка отличается от абонентского обслуживания и доработок?
Техподдержка — поддержание работоспособности того, что уже есть: сбои, обновления, бэкапы, безопасность, мониторинг. Доработки — создание нового функционала. Их стоит разделять и в договоре, и в учёте часов, иначе развитие сайта съест ресурс, зарезервированный под аварии.
Обязательно ли продлевать лицензию, если сайт и так работает?
Сайт не выключится после окончания оплаченного периода. Но новые обновления, включая обновления безопасности, станут недоступны, и разрыв между вашей версией и актуальной со временем начнёт мешать — и при подключении новых решений, и при переезде на новое серверное окружение.
Сколько часов в месяц закладывать на поддержку?
Универсальной цифры нет: она зависит от объёма кастомного кода, числа интеграций и нагрузки. Практичный подход — начать с небольшого пакета, три-четыре месяца вести честный учёт трудозатрат и после этого пересмотреть объём. Главное, чтобы в договоре заранее был описан порядок действий при исчерпании пакета: работы останавливаются, переносятся или оплачиваются сверх.
Можно ли передать поддержку новому подрядчику, если сайт делала другая команда?
Да, это стандартная ситуация. Разумный порядок — сначала аудит: версия ядра, объём и качество кастомного кода, настройки безопасности, наличие рабочих бэкапов. По результатам виден реальный объём сопровождения, и только после этого имеет смысл подписывать SLA со сроками.
Нужен ли режим 24/7 небольшой компании?
Не всегда. Круглосуточное дежурство оправдано, когда сайт приносит заказы вне рабочего дня или у вас работает личный кабинет с клиентами. Если основные продажи идут в будни днём, чаще достаточно расширенного окна и отдельного порядка реагирования на критические инциденты в выходные — это дешевле и закрывает реальные риски.
Договор на сопровождение стоит читать так же внимательно, как договор на саму разработку. Разница между «поддержкой» за символическую сумму и работающим SLA становится заметна не в спокойные месяцы, а в тот единственный день, когда сайт лежит и от скорости реакции зависит выручка недели. Проще потратить час на согласование цифр заранее, чем потом доказывать подрядчику, что три дня простоя — это долго.