Поддержка сайта на 1С-Битрикс: SLA и безопасность

Что важно учесть: поддержка 1С-Битрикс должна охватывать не только правки шаблона, но и платформу, модули, PHP, базу данных, cron/агенты, почту, интеграции, резервные копии и сервер. До договора фиксируют SLA, приоритеты, часы, границы ответственности и способ приёмки. Базовая поддержка сайта Za IT стоит 9 999 ₽ в месяц: до четырёх часов работ, мониторинг, резервные копии и обновления.

Битрикс-проект часто объединяет магазин, обмен с 1С, пользовательские доработки и инфраструктуру. Ошибка в одном слое выглядит как проблема другого: заказ не появился из-за агента, письмо не дошло из-за внешнего сервиса, а медленная страница упирается в запрос к базе. Поэтому сначала нужна диагностика полного пути.

Что входит в контур

Перед стартом составляют карту:

• редакция и модули 1С-Битрикс;
• версия PHP и веб-сервер;
• СУБД и размер базы;
• пользовательские компоненты и шаблоны;
• cron, агенты и фоновые задания;
• обмены с 1С, CRM, оплатой и доставкой;
• почта и уведомления;
• файловое хранилище и резервные копии;
• мониторинг и журналы;
• владельцы домена, лицензий и аккаунтов.

Без карты невозможно честно разделить ответственность CMS, кода, сервера и внешнего сервиса.

SLA и приоритеты

SLA описывает измеримые условия, а не слово «быстро». Полезно зафиксировать:

• Критичный приоритет. Пример: недоступен сайт, заказ или оплата. Реагируем по согласованному аварийному каналу; задача — ограничить ущерб и восстановить путь.
• Высокий приоритет. Пример: не работает важная функция. Реагируем в рабочем окне; задача — найти обход и исправить.
• Обычный приоритет. Пример: локальная ошибка. Реагируем по очереди; задача — выполнить в пакете.
• Плановый приоритет. Пример: улучшение и контент. Реагируем при планировании; задача — оценить и поставить в релиз.

Конкретное время реакции и режим дежурства согласуются отдельно. Публичный базовый пакет не означает круглосуточный SLA. Время реакции также не равно времени устранения: для неизвестной аварии сначала нужна диагностика.

Обновления без риска

Ядро, модули и окружение нельзя обновлять вслепую на production. Безопасный процесс:

1. проверить лицензию и доступные версии;
2. прочитать изменения и известные ограничения;
3. создать проверяемую резервную копию;
4. воспроизвести обновление на тестовом контуре;
5. пройти критические сценарии;
6. согласовать окно и план отката;
7. обновить production;
8. проверить публичный путь и фоновые задания.

Если проект содержит изменённое ядро или сторонний модуль без поддержки, риск фиксируют отдельно. Сначала устраняют конфликт или принимают осознанное решение отложить обновление.

Резервные копии

Для восстановления нужны база, файлы, конфигурация окружения и информация о внешних зависимостях. Копия хранится вне основного сервера и защищается от доступа обычной учётной записи сайта.

Политика определяет частоту, глубину истории, шифрование, уведомление об ошибке и ответственного. После значимого изменения создают контрольную точку. Периодически выполняют тестовое восстановление: зелёный статус создания архива не подтверждает его пригодность.

Для магазина отдельно учитывают допустимую потерю заказов между копиями и процедуру сверки с оплатой и 1С.

Безопасность

Минимальная гигиена поддержки:

• уникальные учётные записи вместо общего администратора;
• минимальные права и двухфакторная защита;
• закрытый доступ к служебным интерфейсам;
• своевременные обновления после тестирования;
• контроль изменённых файлов и необычных входов;
• секреты только в защищённом хранилище;
• отзыв доступов ушедших сотрудников и подрядчиков;
• журналы без паролей, токенов и персональных данных.

При подозрении на взлом не начинают с удаления «странного файла». Сохраняют evidence, ограничивают доступ, определяют точку входа, проверяют пользователей и изменённые данные, затем восстанавливают доверенный контур и закрывают первопричину.

Производительность

«Ускорить Битрикс» — диагностическая задача. Проверяются серверный ответ, запросы базы, кеш, фоновые процессы, изображения, frontend-ресурсы и внешние интеграции.

Полезные измерения:

• время ответа ключевых URL;
• медленные запросы и блокировки;
• hit/miss кеша;
• CPU, память и задержка диска;
• длительность агентов и cron;
• размер и рост таблиц;
• ошибки внешних сервисов;
• вес первого экрана на мобильном.

Установка дополнительного кеша без понимания причины может скрыть проблему и добавить новую точку отказа.

Обмен с 1С и внешние сервисы

Для обмена документируют источник истины, поля, расписание, обработку повторов и журнал ошибок. Нужно понимать, что произойдёт, если сеанс оборвётся после передачи части товаров или заказ уже создан, но подтверждение не дошло.

Проверяются:

1. тестовый обмен небольшой выборки;
2. повторный запуск без дублей;
3. изменение цены и остатка;
4. удаление или деактивация товара;
5. заказ с нестандартным составом;
6. недоступность одной стороны;
7. уведомление ответственного.

Те же правила применяются к оплате, доставке и CRM. Браузерное сообщение об успехе не заменяет серверное подтверждение.

Почта, формы и заказы

Форма считается работоспособной, когда обращение фактически дошло до ответственного и сохранилось там, где предусмотрено процессом. Проверяют валидацию, серверный ответ, почтовый транспорт, спам-фильтры и конечный ящик.

Для заказа дополнительно сверяют сумму, статус оплаты, запись в административной панели и обмен. Контрольная заявка должна выполняться после обновлений, затрагивающих шаблон, почту или интеграцию.

Границы пакета и цена

Регулярная поддержка сайта Za IT стоит 9 999 ₽ в месяц. В неё входит до четырёх часов задач, мониторинг, резервные копии и обновления. Разовая инженерная работа стоит 2 999 ₽/час.

Отдельно оцениваются:

• большой редизайн и новый функциональный раздел;
• сложная миграция или обновление с несовместимыми доработками;
• круглосуточное дежурство;
• аварийное восстановление неизвестного масштаба;
• лицензии, хостинг и платные сервисы;
• массовая переработка каталога;
• новая интеграция с 1С или внешней системой.

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

Как устроить работу

Единая очередь содержит симптом, влияние, приоритет, evidence и ожидаемый результат. Перед изменением фиксируется исходное состояние; после — проверка production.

Ежемесячный отчёт включает:

• выполненные задачи и затраченное время;
• доступность и заметные инциденты;
• состояние копий;
• установленные обновления;
• найденные риски;
• план следующего периода.

Пароли и токены в отчёт не попадают. Для чувствительных данных достаточно признака наличия, длины и безопасной контрольной суммы, если это нужно для сверки.

Критерии приёмки

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

Практический пример

В магазине периодически не обновляется остаток. Простая перезагрузка обмена временно помогает, но проблема возвращается. Команда проверяет журнал, расписание агента, блокировки базы и повторную обработку. Выясняется, что длительное задание пересекается с импортом.

Расписание разводится, добавляется сигнал о просроченном обмене и тест повторного запуска. После исправления проверяются карточка, корзина и заказ. Это более надёжный результат, чем ручной рестарт без наблюдения.

Что отправить для диагностики

Укажите URL, редакцию, симптом, время ошибки, затронутый сценарий и недавние изменения. Секреты через форму не передавайте. Действующие условия находятся на странице поддержки сайтов.

Для нового коммерческого контура используйте разработку сайтов. Практический Битрикс-проект представлен в кейсе sf2v, а соседний материал объясняет администрирование сайта и его стоимость.