Техподдержка сайтов на Битрикс: что входит в работу инженеров, SLA и почему дешёвая поддержка дороже

Что входит в техподдержку сайта: разбираем по слоям

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

В проектах с активным импортом из 1С у нас регулярка занимает больше времени, чем реакция на инциденты: проверить, что обмен прошёл без затирания цен и остатков, что агенты отработали, что бэкап снят. У магазинов с большим каталогом добавляется работа с контентом и мета-тегами. У проектов с интеграциями — контроль обмена с CRM, платежами, службами доставки. Состав конкретных работ зависит от SLA и типа проекта: интернет-магазин, корпоративный сайт и портал на Битрикс24 требуют разного набора. Об этом ниже в статье мы ещё поговорим отдельно — а сейчас разберём, из каких слоёв вообще состоит техподдержка.

Слои работ, которые мы закладываем в поддержку:

• Инфраструктура — сервер, бэкапы, мониторинг доступности, контроль места на диске и нагрузки.
• Платформа — обновления ядра и модулей через SiteUpdate, перевод агентов на cron, проверка целостности ядра.
• Контент и каталог — импорт из 1С, актуальность цен и остатков, работа с мета-тегами и структурой разделов.
• Интеграции — 1С, CRM, платёжные системы, службы доставки, обмены с внешними сервисами.
• Развитие — доработки, новые блоки, правки шаблонов, доработка бизнес-логики под меняющиеся задачи.

Дальше — как эти слои связаны между собой и почему нельзя взять только один.

Слои не изолированы, и SLA определяет, насколько глубоко мы в каждый из них заходим. Чем выше критичность проекта — тем быстрее реакция и тем больше проактивных работ, которые делаются до того, как что-то сломалось. На базовом уровне сервиса мы можем ограничиться мониторингом доступности и реакцией на обращения. На высоком — добавляем регулярную проверку бэкапов, ревизию обменов, плановые обновления в согласованное окно, аудит логов.

Соблазн взять «только обновления» или «только мониторинг» понятен — кажется, что так дешевле и проще. Но обновления без мониторинга опасны: обновили ядро, что-то отвалилось в интеграции — а узнали об этом от клиента через неделю, когда продажи уже просели. Мониторинг без обновлений — это наблюдение за деградацией: платформа устаревает, модули перестают быть совместимы с новыми версиями PHP, и однажды обновление становится не «плановым», а «аварийным с риском». То же с контентом: импорт из 1С без контроля мета-тегов затирает вручную заполненные SEO-поля, и это всплывает только на просадке трафика.

По нашему опыту, рабочая поддержка — это связка слоёв, а не один слой. Инфраструктура обеспечивает, чтобы всё работало. Платформа — чтобы работало на актуальной версии. Контент и интеграции — чтобы данные были верными. Развитие — чтобы сайт не стоял на месте. Если подрядчик предлагает только один слой, обычно это значит, что остальное просто не входит в его зону ответственности, и затыкать дыры придётся вам.

Техподдержка Битрикс: что специфичного в обслуживании 1С-Битрикс

Многие думают, что поддержка сайта на «1С-Битрикс» — это про «поменять баннер и почистить логи». На деле Битрикс — это не только CMS, но и набор модулей, агентов, механизмов обновления и интеграций, каждый из которых живёт своей жизнью. Ядро, события, штатный SiteUpdate, обмен с 1С, права, кеш — всё это связано. Если поддерживать сайт как «просто вёрстку», рано или поздно что-то отвалится: то агенты перестанут отрабатывать, то обновление затрёт кастомизацию, то импорт из 1С встанет из-за незакрытой транзакции.

В нашей практике специфика обслуживания Битрикса проявляется в трёх вещах. Первое — обновления приходят пакетами, и их нельзя ставить «на глазок»: ядро, модули и шаблон обновляются в разном темпе, а кастомные правки в /bitrix/php_interface/ и в компонентах надо переносить руками. Второе — фоновые задачи (агенты, cron, очереди) — это отдельный слой, который надо мониторить: если агент завис, пользователь этого не заметит, а бизнес-логика встанет. Третье — интеграции с 1С и внешними сервисами живут по своим протоколам и требуют понимания событий и транзакций, а не «нажатия кнопки обмена».

Поэтому поддержка Битрикса — это не «поддерживать сайт», а поддерживать систему в актуальном и предсказуемом состоянии. Дальше разберём два самых частых технических сюжета: обновления через SiteUpdate и агенты на cron.

Обновления через SiteUpdate и модули

Штатный механизм обновлений в Битриксе — технология SiteUpdate: она скачивает обновления и новые модули для поддержания актуальности системы. Это не «обновить WordPress в один клик» — обновление проходит через модуль main, затрагивает зависимости между модулями и может потребовать миграции данных. В наших проектах мы никогда не ставим обновления на продакшене без предварительного прогона на стенде: слишком часто всплывают несовместимости с кастомными компонентами и правками в шаблоне.

Ключевое, что нужно понимать про обновления Битрикса:

• Обновляется не «сайт», а модули — у каждого свой номер версии и свой changelog, и обновлять их можно выборочно.
• Кастомизация в ядре затирается — правки в /bitrix/modules/ не переживут обновление; всё, что нужно сохранить, живёт в /local/ или в собственном модуле.
• Обновление требует бэкапа — и базы, и файлов, и, желательно, состояния лицензии.

Отдельная история — обновление шаблона и компонентов. Штатный SiteUpdate их не трогает: если вы кастомизировали компонент в /bitrix/components/, обновление может сломать его вызов. Правильная практика — выносить правки в /local/components/ и фиксировать версии модулей в документации проекта.

Агенты на cron: зачем и как не потерять

Агенты в Битриксе — это фоновые задачи: рассылки, пересчёт скидок, синхронизация с 1С, чистка кеша. По умолчанию они запускаются «на хитах» — то есть когда на сайт приходит посетитель. Это работает, пока трафик есть. Ночью, в выходные или на «тихом» сайте агенты просто не отрабатывают — и задачи копятся. Именно поэтому на любом серьёзном проекте агенты переводят на cron.

В BitrixEnv/BitrixVM 5.1.2 работа агентов и почты на cron является способом по умолчанию — то есть на типовом окружении это уже настроено. Но если сайт разворачивали вручную или переносили с другого сервера, параметр мог остаться дефолтным. Проверять надо явно: через админку (Настройки → Инструменты → Командная PHP-строка) или через PHP-консоль на сервере.

Установить параметр можно так:

<?php
// Включаем использование агентов на cron.
// Выполнять от имени пользователя bitrix (или того, под которым работает PHP-FPM).
require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';

use Bitrix\Main\Config\Option;

// Вариант через COption (старый API, но всё ещё рабочий):
COption::SetOptionString('main', 'agents_use_crontab', 'Y');

// Вариант через D7-обёртку:
Option::set('main', 'agents_use_crontab', 'Y');

echo "agents_use_crontab = " . Option::get('main', 'agents_use_crontab') . PHP_EOL;

После установки параметра нужно убедиться, что в crontab пользователя bitrix есть строка запуска /bitrix/modules/main/tools/cron_events.php — иначе агенты просто не будут запускаться, и параметр ничего не изменит.

SLA техподдержка: уровни сервиса и как их настроить в 1С-Битрикс

Самый частый запрос на эту тему звучит так: «хотим, чтобы заявки не терялись и чтобы было понятно, за что мы платим». За этим стоит отсутствие SLA — соглашения об уровне сервиса. Разберём, что это и как настроить в 1С-Битрикс.

SLA (Service Level Agreement) — документ, который фиксирует критерии качества услуг: время реакции на обращение, приоритеты, зоны ответственности. С точки зрения законодательства РФ SLA не является самостоятельным договором: это приложение к основному договору на обслуживание, и юридическую силу ему придаёт именно связка с ним. Без SLA поддержка превращается в лотерею. Сроки исправления бага непредсказуемы, ответственность исполнителя размыта. Внутри 1С-Битрикс SLA — это ещё и рабочий инструмент: он разграничивает, кто из пользователей может создавать обращения какой критичности и как быстро они должны обрабатываться.

Настроим по шагам.

1. Перейти в административной панели в Сервисы > Техподдержка > Уровни поддержки. Это страница управления SLA — здесь хранятся все уровни, их параметры и привязки к пользователям.
2. Выбрать предустановленный уровень — Старт, Стандарт, Малый бизнес или Битрикс24.CRM — либо создать собственный, если готовые не описывают вашу модель работы. Предустановленные уровни удобны как шаблон: их можно скопировать и подправить под регламент студии.
3. Настроить права пользователей на создание обращений с разной критичностью. Логика простая: обычный SLA даёт право заводить только обращения низкой критичности, а SLA «Партнёры» — низкую и среднюю. Так вы не получите «аварию» от случайного пользователя, но не заблокируете эскалацию для тех, кому она положена.
4. Задать уровень поддержки по умолчанию и настроить категории обращений в параметрах модуля «Техподдержка». Категории связываются с уровнями SLA — так обращение автоматически попадает в нужную очередь обработки.

Что это даёт на практике. Категории — это не «для красоты»: они определяют, в какую группу попадёт тикет, кто его увидит первым и по какому сроку он должен быть закрыт. Если категории не привязаны к SLA, весь смысл уровней теряется — обращения сыпятся в одну кучу.

В проектах на обслуживании мы обычно настраиваем два-три уровня: базовый для штатных сотрудников клиента (только низкая критичность, стандартное время реакции), расширенный для ключевых контактов с правом заводить среднюю критичность, и отдельный для аварийных ситуаций. Каждый уровень мы связываем с внутренним регламентом студии: сколько времени даётся на первую реакцию, на диагностику, на устранение. Это защищает обе стороны — клиент видит предсказуемые сроки, а мы не разрываемся между «срочно» и «очень срочно» без критериев.

Что стоит менять под свой проект: количество уровней (не плодите лишние — три-четыре максимум), список категорий обращений и распределение прав между ролями пользователей. Если у вас один-два администратора сайта — хватит одного уровня; если это интернет-магазин с менеджерами, контент-редакторами и маркетологом — разграничение по критичности обязательно.

Поддержка и обслуживание сайтов: регулярные работы vs аварийные

Типичный сценарий: сайт работает, задачи закрываются по мере поступления заявок от менеджеров, обновления ставятся «когда-нибудь», бэкапы делаются хостингом «наверное». Пока ничего не падает — кажется, что поддержка есть. Но стоит одному модулю обновиться несовместимо с ядром, или импорту из 1С залить битую порцию данных — и проект уходит в простой, а все силы команды бросаются на тушение пожара вместо планового развития.

Мы делим поддержку на два принципиально разных режима. Плановая — это регулярные работы: обновления ядра и модулей через SiteUpdate с предварительным тестом, резервное копирование по расписанию, мониторинг доступности и ошибок в логах, оптимизация запросов и чистка агентов. Аварийная — реакция на инциденты: сайт упал, оплата не проходит, каталог не открывается, письма не уходят.

Без плановой работы аварийная обходится в разы дороже. Каждое обновление, которое не поставили вовремя, копится в отложенный долг: чем дольше откладываешь, тем сложнее пройти апдейт сразу через несколько версий. Каждый бэкап, которого нет, — это риск потерять данные при сбое импорта или ошибке в коде. Именно регулярные работы превращают аварии из «когда» в «редко и предсказуемо».

Как мы строим регламент в проектах на поддержке: ежедневно — проверка доступности, просмотр логов ошибок, контроль бэкапов, реакция на алерты мониторинга. Еженедельно — обновление модулей и ядра на тестовом контуре, проверка импорта из 1С, чистка отложенных агентов, которые могут тормозить страницы. Ежемесячно — сводный отчёт: что обновили, какие инциденты были, что рекомендуем поправить в архитектуре.

Мы настаиваем на документировании каждого действия не из бюрократии. Когда через полгода что-то ломается, журнал работ показывает, что менялось и когда. Без него диагностика превращается в археологию: непонятно, обновление ли виновато, правка ли контента, или импорт. По нашему опыту, проект с регламентом и логом работ диагностируется в разы быстрее — просто потому, что виден контекст последних изменений.

Если у вас большой каталог и активный импорт из 1С, регламент стоит строить вокруг обмена: обновления ставить в окно между выгрузками, бэкап делать до импорта, а не после. Для контентных сайтов приоритет смещается в сторону мониторинга и обновлений безопасности. Универсального графика нет. Есть принцип: плановые работы должны опережать проблемы, а не догонять их.

Обслуживание сайта цена: из чего складывается и почему дешёвая поддержка дороже

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

У магазина на 1С-Битрикс с обменом каталогом, оплатой, доставкой и личным кабинетом цена поддержки объективно выше, чем у визитки на шаблоне. Это не «накрутка за бренд» — разное количество точек отказа. Дешёвая поддержка почти всегда означает одно и то же: нет мониторинга, бэкапы делаются редко или формально, реакция на инцидент — «в течение суток, если успеем», обновления не ставятся. Формально услуга оказана. Фактически сайт живёт на честном слове.

По нашему опыту, грамотный разговор о цене начинается не с вопроса «сколько», а с вопроса «что входит». И дальше — по списку факторов.

• Количество сайтов и поддоменов — один магазин, сеть региональных витрин или основная площадка плюс B2B-портал требуют разного ресурса.
• Объём каталога — 500 SKU и 50 000 SKU обслуживаются по-разному: индексация, импорт, скидки, генерация разделов.
• Наличие интеграции с 1С — обмен, выгрузка заказов, остатки, цены; сбой в обмене роняет продажи быстрее, чем падение сайта.
• Требуемое время реакции (SLA) — «в течение дня» и «15 минут 24/7» — это разные сметы и разное дежурство.
• Проактивные работы — обновления ядра и модулей, аудит логов, чистка агентов, профилактика БД, а не только реакция на заявки.
• Доступность 24/7 — ночные дежурства, аварийная линия, эскалация на выходных.

Дальше — про то, почему экономия на этом списке выходит боком.

Дешёвая поддержка переносит риск с подрядчика на владельца сайта. Пока всё работает, разницы не видно: заявки закрываются, счёт приходит маленький. Разница проявляется в момент аварии, а он обязательно наступает. Магазин лежит, корзина не оформляется, заказы не уходят в 1С, реклама продолжает лить трафик в никуда. Каждая минута простоя — это не «потерянные деньги вообще», а конкретные неслучившиеся заказы, которые уже оплачены в рекламном бюджете.

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

Третий слой — срочные доработки. Когда сайт лежит или ломается обмен, у владельца нет переговорной позиции: любые работы делаются по аварийному тарифу, вне очереди, с наценкой. Именно здесь «сэкономленные» на абонентке деньги возвращаются подрядчику — только уже без гарантий и без плана. Логика простая: регулярная поддержка распределяет нагрузку по времени и стоит предсказуемо, аварийная концентрирует её в худший момент и стоит дороже.

Самые частые ошибки, которые ломают поддержку Битрикса

За годы практики мы заметили: техподдержка Битрикса ломается не на экзотике, а на одних и тех же технических граблях. Про них не пишут в документации, потому что формально «всё работает как задумано». Но именно из-за них сайт месяцами живёт с неработающими агентами, отвалившимся обменом с 1С и обновлениями, которые невозможно поставить.

Разберём четыре самые частые.

Cron без пролога. Скрипт вынесли в отдельный файл, повесили на планировщик, а внутри ни prolog.php, ни подключения ядра. Из браузера файл открывается, из cron падает с fatal error. Классика.

Отвалившийся TLS. Внешний API (платёжка, служба доставки, интеграция с маркетплейсом) внезапно перестаёт отвечать. На стороне сервиса подняли минимальную версию протокола, а на сайте PHP-клиент по-прежнему стучится старым TLS.

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

Правка ядра. Самая дорогая ошибка. Кто-то поправил файл прямо в /bitrix/modules/, обновление перезаписало, и правка исчезла вместе с логикой работы.

Дальше разберём первые две подробно: они встречаются чаще всего и обе лечатся за пять минут, если знать, где смотреть.

Fatal error: Class 'CModule' not found в cron

На ru.stackoverflow разбирали ровно этот случай: скрипт собирает данные с другого сайта, запускается по cron и падает с Fatal error: Class 'CModule' not found. При этом если открыть тот же файл в браузере, всё отрабатывает нормально. Причина простая: из браузера скрипт попадает в контекст, где ядро Битрикса уже подключено, а из cron нет. Классы CModule, COption, CUser живут в ядре, и без явного подключения их просто не существует.

Мы регулярно видим эту ошибку в проектах, где cron-задачи писали «на коленке» — быстрым файлом в корне сайта. Решение не в костылях вроде require $_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include.php', а в штатном прологе. Вариантов два, и выбор зависит от того, где лежит скрипт.

Если файл живёт в корне сайта — подключаем prolog.php с явным указанием уровня. Если скрипт вынесен в отдельную CLI-утилиту и должен работать без веб-окружения — используем prolog.php с константой NO_KEEP_STATISTIC и отключённой авторизацией, чтобы не тянуть лишнее. Оба варианта рабочие, второй чуть чище для тяжёлых выгрузок.

<?php
// cron/import_from_api.php — скрипт запускается планировщиком
// Подключаем пролог Битрикса: без него классов CModule, COption и т.д. нет

define('NO_KEEP_STATISTIC', true);
define('NOT_CHECK_PERMISSIONS', true);
define('BX_NO_ACCELERATOR_RESET', true);

// путь до корня сайта — подставьте свой
$_SERVER['DOCUMENT_ROOT'] = '/home/bitrix/www';

require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';

// теперь ядро подключено, классы доступны
\Bitrix\Main\Loader::includeModule('iblock');

$iblockId = 12; // замените на ваш IBLOCK_ID

$res = \CIBlockElement::GetList(
    ['ID' => 'ASC'],
    ['IBLOCK_ID' => $iblockId, 'ACTIVE' => 'Y'],
    false,
    false,
    ['ID', 'NAME', 'CODE']
);

while ($item = $res->Fetch()) {
    // ваша логика обработки
}

require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/epilog_after.php';

TLS handshake failure при обращении к внешним API

Второй по частоте случай с того же ru.stackoverflow: телеграм-бот на сайте сначала не заработал, потому что Telegram требует HTTPS и TLS не ниже 1.2. Через три недели нормальной работы он снова отвалился, теперь с ошибкой Authentication failed because the remote party sent a TLS alert: 'HandshakeFailure'. Проблема может быть как на стороне сервера, так и на стороне клиента. Диагностировать нужно сравнением протоколов с эталонным сайтом вроде google.com.

В PHP всё решается через stream_context у HTTP-клиента. По умолчанию PHP берёт версию TLS из настроек OpenSSL системы, и если сервер старый, там может стоять TLS 1.0/1.1, которые внешний API давно отвергает. Мы всегда прописываем протоколы явно: это снимает зависимость от конфигурации хостинга и делает поведение предсказуемым при переезде.

Выбирать между 1.2 и 1.3 не нужно — указываем оба, клиент сам договорится с сервером на максимально доступной версии. Если API требует строго 1.3, оставляем только его. Тогда проверьте, что OpenSSL на сервере умеет 1.3 (PHP 7.4+ обычно умеет).

<?php
// Явно задаём TLS 1.2 и 1.3 для исходящих HTTP-запросов.
// Актуально, когда хостинг по умолчанию отдаёт TLS 1.0/1.1,
// а внешний API их уже не принимает.

$context = stream_context_create([
        'ssl' => [
            'verify_peer'       => true,
            'verify_peer_name'  => true,
            'crypto_method'     => STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT
            | STREAM_CRYPTO_METHOD_TLSv1_3_CLIENT,
        ],
        'http' => [
            'method'  => 'POST',
            'header'  => "Content-Type: application/json\r\n",
            'content' => json_encode(['order_id' => 12345]),
            'timeout' => 15,
        ],
]);

$response = file_get_contents(
    'https://api.payment-provider.example/v1/status',
    false,
    $context
);

if ($response === false) {
    // сюда попадаем в том числе при handshake failure
    error_log('API request failed: ' . error_get_last()['message']);
}

Как выбрать подрядчика на техподдержку сайта: чеклист

Разберём практический чеклист, по которому мы сами оцениваем подрядчиков, когда нам передают проект «на сопровождение» от предыдущей команды. Критериев немного, но каждый закрывает конкретный риск: прозрачный SLA, состав работ, отчётность, наличие мониторинга, опыт именно с 1С-Битрикс и скорость реакции. Проваливается хотя бы один пункт — и поддержка превращается в лотерею, где сроки исправления бага непредсказуемы. По опыту подрядчиков они гуляют от часа до недели.

Почему это важно именно для Битрикса. Платформа обновляется через SiteUpdate, модули тянут зависимости друг от друга, а обмен с 1С идёт по расписанию агентами. Подрядчик без профиля в Битриксе просто не поймёт, где смотреть: обфусцированное ядро в /bitrix/modules/main/include.php, отложенные функции в компонентах, нюансы работы агентов на cron — всё это требует накопленной практики. Поэтому мы всегда начинаем разговор с SLA и составом работ, а не с цены часа.

Чеклист вопросов, которые стоит задать подрядчику до подписания договора:

• Какие работы входят в абонентку, а какие считаются отдельной задачей — где граница «доработки» и «поддержки»?
• Как фиксируется время реакции: по какому каналу принимается заявка, что считается моментом старта отсчёта?
• Какие инструменты мониторинга используются — доступность сайта, ошибки PHP, очереди агентов, бэкапы?
• Как передаются задачи: тикет-система, почта, Telegram — и есть ли история обращений, доступная клиенту?
• Что с бэкапами: кто их делает, куда складывает, как часто проверяет восстановление, а не только создание?
• Кто отвечает за обновления ядра и модулей и как откатывается неудачное обновление?
• Есть ли дежурный инженер в нерабочие часы и по какому тарифу это считается?

Теперь про договор. SLA должен быть приложением к договору, а не самостоятельным документом. С точки зрения законодательства РФ SLA сам по себе не является отдельным договором, он фиксирует критерии качества услуг. Поэтому в тексте основного договора должна быть прямая ссылка на приложение с уровнями сервиса, иначе в спорной ситуации ссылаться будет не на что.

Внутри SLA мы советуем смотреть на три вещи. Первое — уровни поддержки: в Битриксе они настраиваются на странице «Уровни техподдержки (SLA)» (Сервисы → Техподдержка → Уровни поддержки), и там есть предустановленные варианты — Старт, Стандарт, Малый бизнес, Битрикс24.CRM. Это удобно как ориентир, но подрядчик должен уметь описать свои уровни своими словами, а не копировать дефолт. Второе — категории обращений: критичная авария, обычная задача, консультация. По нашему опыту, SLA, в котором нет разницы между «сайт лежит» и «поменяйте цвет кнопки», бесполезен. Третье — порядок эскалации: кому пишут, если дежурный не отвечает, за какой срок подключается руководитель, что происходит при повторном нарушении сроков.

Читайте также: Отправка форм с сайта Битрикс в Битрикс24 через init.php: события, кастомные поля, лиды и сделки.