Техподдержка сайтов
на Битрикс в Самаре

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

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

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

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

Можно. Формат отработан на практике, независимо от города. Доступ к серверу, тестовому контуру и панели хостинга открывается один раз в начале сотрудничества и дальше используется постоянно. Задачи и правки фиксируем в трекере, а не в переписке, чтобы история решений не терялась. Живая встреча полезна разве что на старте, для знакомства с командой и процессами, — дальше формат полностью дистанционный.

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

Модули, отвечающие за приём платежей и оформление заказа, — критичны. Их сбой напрямую останавливает продажи. Модули оформления и вёрстки можно отложить на неделю без критичных последствий для бизнеса. Приоритет строим по тому, что случится, если модуль сломается прямо сейчас, а не по алфавиту в списке обновлений. Такой порядок экономит время именно там, где оно дороже всего.

Снятие доступа делаем в течение того же рабочего дня, как только получаем сигнал от клиента, — своим пунктом в чек-листе увольнения, а не по памяти. Проверяем не только вход в саму админку Bitrix, но и связанные сервисы: почту на домене, доступ к серверу по SSH, если он был выдан лично. Список действующих доступов держим в актуальном состоянии. Искать вручную, где ещё остались права уволенного человека, тогда не приходится.

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

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

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

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

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

Зависит от того, где именно узкое место. Без замера это не угадать. На проектах с плохо написанными компонентами доработка кода даёт кратный выигрыш. На проектах с изначально аккуратным кодом, но слабым сервером — тюнинг PHP-FPM, добавление памяти под кэш, переход на более быстрый диск даёт больше, чем переписывание кода. Сначала профилируем запросы, потом уже решаем, куда вкладывать время.

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

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

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

Разница ощутима на больших объёмах — в десятки-сотни тысяч записей с фильтром по нескольким полям сразу. Обычный инфоблок на такой нагрузке заметно проседает по времени ответа. На объёмах в пределах нескольких тысяч записей разница почти незаметна. Переносить данные туда только ради «на будущее» не всегда оправдано. Решение принимаем по текущему и ожидаемому объёму данных, а не по абстрактной рекомендации использовать highload-блоки везде.