Поддержка сайтов
на 1С-Битрикс
в Москве

Со всеми действующими редакциями «Управления сайтом» — от «Старта» до «Бизнеса» — и с «Корпоративным порталом». На объём работ влияет не столько редакция, сколько две другие вещи: насколько сильно правили ядро и шаблон и сколько платных модулей стоит из Маркетплейса. Смотрим ещё на версию PHP: старые сайты нередко держатся на сборке, которую сам Битрикс уже не поддерживает, и это решается первым.

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

Да, со стороны сайта: передачу заявок из форм в CRM, привязку сделок к заказам, уведомления ответственным, обратную передачу статусов. Разбор почти всегда упирается в одно место — что именно уходит в CRM и в каких полях, потому что «заявка не дошла» чаще означает несовпадение полей, а не обрыв связи. Настройку самой системы — воронки, права, роботы — закрывает внедрение и интеграция Битрикс24.

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

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

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

Обновляться нужно, но не ради номера версии. Причин три, и все практические: закрытые уязвимости, совместимость с новыми версиями PHP и то, что разрыв между вашей сборкой и текущей растёт, а вместе с ним растёт цена будущего обновления. Раз в год пройти небольшую дистанцию дешевле и безопаснее, чем однажды перебираться через несколько лет изменений сразу. Как именно проводится само обновление. Отдельный разговор.

Начинаем с того, чем сайт отличается от оригинальной сборки. Сверяем файлы ядра в папке /bitrix/ с дистрибутивом той же версии и выписываем каждую правку: такие правки исчезают при первом же обновлении вместе с функциональностью, ради которой их делали. Дальше смотрим папку /local/, журнал обновлений, список установленных решений Маркетплейса, состояние лицензии, настройку агентов и cron, размер и индексы базы. На выходе. Список рисков с ценой каждого, а не общая оценка «всё плохо».

Потому что обновление ядра перезаписывает эту папку целиком. Правка внутри неё живёт до ближайшего апдейта, а потом пропадает молча: сайт остаётся рабочим, но перестаёт делать то, ради чего правку вносили. Штатное место для своего кода. Папка /local/, туда переносятся шаблоны, компоненты, обработчики событий и init.php. При приёме проекта мы переносим найденный кастомный код в /local/ и дополнительно фиксируем, что именно было перенесено и почему.

С разделения: обмен встал на стороне 1С, на канале или на сайте. Смотрим лог обмена и ответ обработчика 1c_exchange.php, размер шага выгрузки, таймауты веб-сервера и PHP, права на каталог выгрузки. Типовые причины. Не тот формат обмена CommerceML, разошедшиеся идентификаторы товаров после ручной правки каталога, обрыв длинной выгрузки по лимиту времени. Синхронизацию восстанавливаем без повторной полной выгрузки, чтобы не задвоить каталог и не потерять привязки заказов.

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

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

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

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

Сначала измеряем, а не оптимизируем наугад. Смотрим, сколько времени уходит на запросы к базе, сколько на PHP и сколько на отдачу статики. Дальше работаем по найденному: включаем фасетный индекс для умного фильтра, переносим свойства с большим числом значений в highload-блоки, добавляем индексы под реальные запросы, настраиваем кеш компонентов и его сброс по событию, а не по расписанию. Результат проверяем тем же замером, которым ставили диагноз.

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

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

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

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