Аудит CRM и интернет-магазина на Битрикс: стабилизация по ходу работ и план для рефакторинга

Когда систему на Битриксе годами дорабатывают разные подрядчики, правки вносят сразу на рабочем сервере, без контроля версий и тестовой среды, и со временем систему боятся обновлять.

Наш клиент — веб-студия, которая запросила технический аудит инфраструктуры проекта. Заказчик студии продаёт серверное оборудование: отдел продаж работает в CRM на Битрикс24, а интернет-магазин — каталог серверов и комплектующих на «1С-Битрикс: Управление сайтом» — приводит клиентов из поиска, заявки из его форм уходят в CRM. Обе системы работают в BitrixVM — типовом окружении Битрикса на виртуальной машине. Над CRM успели поработать 8–10 подрядчиков, над сайтом — около восьми.

CRM работала медленно, на диске в 500 ГБ регулярно заканчивалось место (150 ГБ из них — база), старые файлы не переносились в объектное хранилище, а вертикальное масштабирование упиралось в ограничения провайдера. Нужно было оценить код и настройку сервера, ответить, как масштабироваться и можно ли разделить систему на контейнеры. На аудит отводили пару недель, изменения по итогам планировали отдельной работой.

В первые дни аудита CRM несколько раз падала, и заказчик попросил сначала убрать самые острые проблемы, чтобы не встала работа отдела продаж.
Отдельно клиент заказал аудит интернет-магазина. Сайт работал медленно, что мешало продвижению в поиске, а обновить Битрикс и серверное ПО без риска недоступности было нельзя. Нужно было понять, можно ли сайт ускорить, поддерживать его или писать новый, как его обезопасить и обновлять.

Июнь — ноябрь 2024 года

2 DevOps-инженера (тимлид и senior), техлид, PHP-разработчик, менеджер проекта

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

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

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

Рекомендации. По инфраструктуре: обновления и отказ от автонастройки, резервное копирование с реплики базы и инкрементальный бэкап файлов, переход на Nginx + PHP-FPM, тонкая настройка базы данных и сервера уведомлений. По коду: внедрение тестовых площадок, контроля версий, линтеров и инвентаризация кастомного кода вместе с бизнесом. Бэкап мы предложили переделать сразу, не дожидаясь рефакторинга - иначе система долго оставалась бы в зоне риска.

Правки по ходу аудита. Вместе с разработчиками отключили режим отладки, закрыли две уязвимости в коде, удалили открытые служебные файлы, среди них дамп базы, и подключили APM-агент.

Что нашли. Среднее время ответа — больше 400 мс, Apdex — 0,85. Около трети времени уходило на неиспользуемый модуль веб-аналитики: на каждом запросе он обращался к внешним сервисам геоданных и писал в базу, а в дайджесте запросов MySQL его таблица заняла первое место по времени — 20%. Ошибка в корзине создавала запись в базе почти на каждом запросе, хотя корзина сайту не нужна. В коде разработчики нашли уязвимые места, закладки и признаки прошлого взлома; контроль версий на проекте пробовали ввести и бросили, тестового контура нет. На сервере мы нашли ОС без поддержки, лишние доступы к серверу и базе, только последнюю резервную копию на диске сервера и сжатие ответов только для скриптов и CSS.

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

Рекомендации по серверу свели в план, каждый пункт мы оценили в часах. По плану сделали следующее.

Доступы. Закрыли лишние доступы к серверу и базе, настроили fail2ban.

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

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

Что отложили. Автоконфигурацию отключили, но не удалили: за ней потянутся веб-серверы и база, поэтому удаление отложили до переезда в контейнеры. Буферы базы не урезали: они заняты на 97%, нехватки памяти нет. Связку Nginx + PHP-FPM заложили в целевую схему с самого начала: на ней работают тестовые стенды CRM. Но переводить старый продакшен сайта на эту связку сочли рискованным, поэтому переход вместе с обновлением стека перенесли в блок будущих работ по обновлению.

Рекомендации обоих аудитов — резервное копирование CRM с реплики, тестовые стенды, переезд CRM и сайта в контейнеры — стали следующими работами; о них — в кейсе про рефакторинг инфраструктуры.