Техподдержка сайтов
на Битрикс
в Екатеринбурге

1С-Битрикс — стандарт корпоративных и интернет-магазинов в России. Полная локализация под российский рынок — НДС, документооборот, 54-ФЗ, маркировка Честный знак, ЕГАИС. Глубокая интеграция с 1С. Платная коммерческая поддержка. Большая экосистема разработчиков в России, включая уральский регион. Для крупных екатеринбургских ритейлеров (Сима-Ленд, Монетка, Кировский) и торговых компаний выбор обычно очевиден.

Полный спектр. Корпоративные сайты на «Стандарт», «Малый бизнес», «Бизнес». Интернет-магазины на «Малый бизнес» и «Бизнес». Крупные интернет-магазины на «Бизнес» и «Энтерпрайз» с десятками тысяч SKU. Корпоративные порталы (Bitrix24). B2B-платформы для оптовых клиентов уральской промышленности. Сайты с интеграцией в комплексные торговые системы.

Да, это типовая часть работы. Интеграция Битрикс-1С — бесшовный обмен между сайтом и учетной системой. Стандартные сценарии: выгрузка каталога из 1С на сайт, загрузка заказов в 1С, двусторонний обмен статусами, обмен документами. Реализуется через CommerceML, REST API 1С, либо прямое подключение к базе. Учитываем конфигурацию 1С клиента (УТ, ERP, КА), типичную для уральской металлургии, машиностроения, торговли.

Да. Битрикс выпускает несколько обновлений в год. Регламент: бэкап до обновления, применение на staging, функциональное тестирование, обновление на production с минимальным простоем, постмортум. Особенность Битрикс — обновления крупных версий иногда требуют изменений в кастомизациях.

Да, для интернет-магазинов на Битриксе это типовая задача. Интеграция с Wildberries, Ozon, Яндекс.Маркет, Авито. Синхронизируется: каталог товаров, цены, остатки, заказы, статусы, контент карточек. Используем готовые модули из Маркетплейс Битрикса и кастомные доработки.

Да, для всех интернет-магазинов это обязательная часть. Все интернет-продажи фискализируются через онлайн-кассу. Для интернет-магазинов используются облачные кассы (АТОЛ Онлайн, КОНТУР Касса Онлайн — уральская разработка Контура, Эвотор Облако). В Битриксе настраиваем интеграцию через стандартные модули или кастомные доработки.

Да. Типовые сценарии миграции на Битрикс: с самописных CMS, Joomla, Drupal, WordPress + WooCommerce, устаревших версий Битрикса, зарубежных платформ (Shopify, Magento). Миграция — серьезный проект: анализ, перенос данных, настройка обмена с 1С, тестирование, переключение DNS, контроль SEO, сопровождение в первые недели.

Базовая поддержка (для корпоративного сайта или небольшого интернет-магазина) — для малого и среднего бизнеса. Стандартная (для среднего интернет-магазина с активной торговлей и 1С-интеграцией) — для среднего бизнеса. Расширенная (для крупного интернет-магазина с большим каталогом, маркетплейсами, сложными интеграциями) — для крупного бизнеса. Помимо разработки в стоимость входит продление лицензии Битрикс.

Работаем. Территориальная привязка команды почти не влияет на качество поддержки, если процесс выстроен через удалённые инструменты, а не через личное присутствие. Сервер, тестовый контур, задачи в трекере — всё это одинаково доступно из любой точки. Разница в часовом поясе с Уралом у нас минимальная. Время ответа на срочные обращения не отличается от работы с сайтами в своём часовом поясе.

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

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

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

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

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

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

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

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

Время ответа базы смотрим само по себе, не вместе с общим временем загрузки страницы. Запрос к MySQL укладывается в десятки миллисекунд, а страница всё равно грузится секундами? Дело тогда в другом месте — обработке PHP, внешних скриптах, сети. Запросы к базе занимают основное время? Это сигнал смотреть в сторону сервера и индексов, а не в вёрстку или композитный кэш, который тут не при чём.

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

Домен остаётся тем же? Новая лицензия не нужна — ключ привязан именно к нему, а не к серверу или IP-адресу. Переезд на новый хостинг технически не требует действий с лицензией вообще. Единственный момент, который нужно проверить до переезда, — совпадение версии PHP и MySQL на новом сервере с текущими требованиями редакции, иначе после переноса сайт может отказаться работать даже при действующем ключе.

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

Чаще всего нет. На таком объёме обычный инфоблок справляется без заметных задержек, а переход на highload-блок добавляет сложности в администрировании без ощутимой выгоды в скорости. Исключение — если даже при небольшом каталоге у одного товара очень много значений одного свойства: например, десятки вариантов совместимости у детали. Смотрим на плотность данных внутри каждой карточки, а не только на число товаров.