Доработка модулей и инфраструктуры на 1С-Битрикс: код, производительность и DevOps

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

Почему технический фундамент со временем проседает

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

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

Что меняет доработка модулей и инфраструктуры

Доработка решает технические проблемы адресно, не разрушая то, что уже работает и приносит деньги. Медленный каталог ускоряется настройкой кеша и оптимизацией запросов, а не переездом на новую платформу. Хрупкие обновления перестают ломать сайт, когда кастом вынесен из ядра в собственные модули. Уязвимости закрываются обновлениями, проактивным фильтром и наведением порядка в правах доступа. А страшная ручная выкладка превращается в спокойный процесс, когда появляется тестовый контур и автоматический деплой через CI/CD. В сумме сайт становится быстрым, стабильным и безопасным — но остаётся тем же сайтом, со всем накопленным SEO-весом, привычным интерфейсом и работающими интеграциями.

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

Чем доработка инфраструктуры отличается от переписывания

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

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

Когда доработка окупается, а когда хватит точечной правки

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

Как мы ведём технические работы

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

Особое внимание — безопасной выкладке. Мы не выкатываем правки руками на боевой сайт в надежде, что всё пройдёт гладко. Вместо этого настраиваем тестовый контур и конвейер CI/CD: изменения проходят проверку, собираются и переносятся автоматически, а в случае проблемы откатываются за минуты. Это снимает главный источник простоев и позволяет релизить чаще и спокойнее. Если ваш сайт ещё не на подходящем окружении, мы настраиваем BitrixVM или контейнеры Docker под фактическую и прогнозную нагрузку и при необходимости переносим проект на более производительный хостинг.

Гарантии и прозрачность

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

Возражения, которые мы слышим чаще всего

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

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

«Нам нужна только одна задача, а вы предлагаете целый пакет». Не предлагаем. Если достаточно одной правки — настроить кеш, обновить модуль, закрыть уязвимость — мы делаем именно её и берём за неё столько, сколько она стоит. Пакет работ имеет смысл, когда проблем несколько и они связаны между собой. Что выгоднее в вашем случае, покажет технический аудит.

Сценарии, под которые мы дорабатываем инфраструктуру

Технические задачи у всех разные, и работы подстраиваются под состояние проекта, а не наоборот. Для интернет-магазина с большим каталогом на первый план выходит производительность: композитный кеш, оптимизация запросов и индексов, разгрузка базы данных, чтобы каталог и фильтры не ложились в пик. Для B2B-портала с накопленным кастомом важнее навести порядок в коде: вынести правки из ядра в собственные модули, чтобы обновления Битрикса перестали ломать сайт. Для маркетплейса и высоконагруженного проекта в центре внимания окружение и выкладка: BitrixVM, Docker, CI/CD, масштабирование и отказоустойчивость.

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

Этапы работы по шагам

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

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

Гарантии и сопровождение

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

С чего начать

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