Поддержка и сопровождение
сайта на Битрикс
в Краснодаре

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кастомные компоненты, переопределяющие шаблоны ядра напрямую вместо local-папки, — самый частый случай. При обновлении такие правки просто затираются. Иногда вместо этого выскакивает ошибка PHP. Вторая причина — сторонние модули, которые перехватывают события ядра и не проверяют версию перед вызовом метода. Перед обновлением сверяем список кастомных правок с changelog новой версии: это дешевле, чем чинить аварию после апдейта.

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

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

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