Техподдержка сайтов
на Битрикс
в Челябинске

Мы проверяем совместимость плагинов, восстанавливаем корректные сценарии и тестируем процесс до успешного платежа.

Да. Настраиваем интеграции, проверяем тарифы и корректность расчетов по регионам.

Настраиваем SMTP, чиним триггеры писем и следим, чтобы сообщения доходили.

Оптимизируем запросы к базе, настраиваем кеширование и ускоряем отображение карточек.

Да. Всю разработку и поддержку ведём удалённо: доступ к серверу, тестовый контур, созвон с показом экрана. Даже перенос сайта на новый хостинг делаем без выезда — подключаемся к панели провайдера и переносим по чек-листу. Если сервер закрыт периметром компании, поднимаем VPN и работаем через него. Живая встреча случается редко, чаще по желанию клиента, а не по необходимости. Срочная правка уходит в бой за минуты, без дороги через город.

Зависит от задач системы, а не от оборота компании. Всё считается по задаче. «Стандарт» тесен, если каталог растёт за пару тысяч товаров и нужны highload-блоки под характеристики. «Малый бизнес» даёт REST API для внешней CRM. До «Бизнеса» есть смысл дорасти при нескольких юрлицах или втором сайте на одной базе. Мы считаем выгоду апгрейда под конкретную задачу, а не продаём редакцию саму по себе.

Обмен идёт по протоколу CommerceML, по расписанию через cron каждые 15–30 минут. Узкое место — дубли. Если артикул в 1С и на сайте не совпадает символ в символ, создаётся новая позиция вместо обновления старой. Мы сверяем справочник единиц измерения перед первым запуском и логируем каждый цикл. Конфликт виден в журнале сразу, а не в жалобе клиента на сайте неделей позже.

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

Ставим после проверки на копии сайта, а не сразу после релиза. Смотрим changelog на конфликты с кастомным кодом и модулями маркетплейса. Конфликтов нет — уходит в бой в тот же день. Есть — откладываем и чиним совместимость. Перед любым апдейтом снимаем бэкап базы и файлов. Откат тогда занимает минуты, а не разбор аварии посреди рабочего дня.

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

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

Подключаем готовые модули эквайринга — Сбербанк, Т-Банк, ЮKassa — без своего протокола с нуля. Онлайн-касса идёт вторым контуром через ОФД, чаще АТОЛ или Эвотор. Чек формируется в момент оплаты и уходит клиенту на почту. Проверяем, что возврат в личном кабинете синхронизируется со статусом чека, а не только со статусом заказа. Тестовый платёж на копейку делаем перед первым боевым запуском.

Виджет СДЭК или Boxberry встраивается на страницу оформления заказа и показывает карту точек с ценой и сроком. Расчёт идёт по весу, габаритам и региону через API службы в реальном времени, без ручных тарифных таблиц. Упал API службы — сайт должен показать понятную заглушку, а не пустой список. Это проверяем перед запуском отдельным сценарием: имитируем сбой и смотрим на поведение формы.

Можно, если перенос идёт по правилам, а не новой вёрсткой поверх старого кода. Сохраняем структуру URL, метатеги и микроразметку на каждой странице. Адреса меняются — ставим 301-редиректы со старых на новые до релиза. Риск живёт не в дизайне. Он живёт в мелочах: забытом noindex на тесте, который случайно уехал в бой вместе со всем остальным.

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

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

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

Когда инфоблок с характеристиками разрастается настолько, что список товаров начинает тормозить при фильтрации. Highload-блок — это своя таблица без древовидной структуры инфоблоков, зато с быстрой выборкой по большому числу свойств: отзывы, характеристики, история цены. Туда нельзя перенести всё подряд. Вложенные категории highload-блок не умеет, и это нужно закладывать в структуру каталога с самого начала, а не чинить постфактум.