Задача
К нам обратился крупный новостной проект с простой, но критичной проблемой: сайт на 1С-Битрикс периодически становился недоступен.
Для обычного корпоративного сайта несколько минут недоступности — неприятность. Для новостного проекта это уже прямая потеря аудитории: сайт является основной площадкой публикации материалов, а редакция работает постоянно.
За плечами проекта — около 10 лет развития, более 128 тысяч публикаций, большая медиатека и сформировавшаяся аудитория. При этом техническая часть проекта долгое время развивалась без системной модернизации.
Наша задача была не просто «поднять сайт», а понять, почему он падает и что нужно изменить, чтобы проблема не возвращалась.
Сначала перестали гадать
Первым делом подключили мониторинг доступности сайта.
Он показал закономерность: сайт много раз в сутки становился недоступен на 3–5 минут. В момент сбоя происходил таймаут подключения, после чего сервер возвращался в работу.
Следующим этапом посмотрели на сам сервер.
Картина оказалась показательной:
- загрузка CPU регулярно доходила почти до 600%;
- оперативная память была занята на 98–99%;
- диск на 160 ГБ был заполнен примерно на 92%;
- Nginx фиксировал сотни тысяч запросов в сутки;
- значительную часть запросов генерировали боты.
Начали разбирать, что происходило внутри проекта.
Что обнаружили внутри
Проект оказался типичным legacy-продуктом, который много лет успешно выполнял бизнес-задачи, но постепенно оброс техническим долгом.
На сервере находились:
128+ тысяч публикаций
Новости хранились в инфоблоках 1С-Битрикс с большим количеством полей и связей.
140 ГБ данных
Около 120 ГБ занимали изображения из публикаций.
Устаревший стек
CentOS 7, Bitrix VM 7.5, Apache + Nginx и PHP 7.3.
Устаревшая версия 1С-Битрикс
Проект не обновлялся с 2023 года.
Тяжёлые фоновые процессы
На cron выполнялись ресурсоёмкие скрипты, которые конкурировали за ресурсы с основным сайтом.
Нагрузка от ботов
Часть запросов не имела отношения к реальным пользователям и дополнительно расходовала ресурсы сервера.
Проблемы с кешированием
Помимо стандартного кеширования Битрикс использовался собственный механизм, который постепенно разрастался.
Редкие резервные копии
Полный backup выполнялся раз в неделю.
Почему сайт падал
После анализа инфраструктуры, логов и кода сформировали картину.
Проблема была не в одной конкретной ошибке. Сайт падал из-за совокупности технических факторов.
Нелегитимные боты создавали дополнительную нагрузку.
Тяжёлые запросы к инфоблоку с 128 тысячами публикаций потребляли большое количество ресурсов.
Некоторые компоненты Битрикс работали неоптимально и выполняли слишком дорогие выборки.
Фоновые cron-задачи конкурировали с пользовательскими запросами за CPU и память.
Кеш проекта разрастался и дополнительно нагружал систему.
При этом Apache был настроен таким образом, что при пиковом количестве соединений сервер упирался в лимит. В результате происходила перезагрузка, а сайт становился недоступен на те самые 3–5 минут.
Наш вывод
Нужно было не увеличивать сервер и ждать следующего падения.
Проекту требовалось техническое наведение порядка.
Что сделали
Работы разбили на несколько направлений.
1. Отсечь лишнюю нагрузку
Начали с Nginx и инфраструктурного уровня.
Настроили фильтрацию нелегитимных ботов, чтобы они не доходили до приложения и не тратили ресурсы PHP и Битрикс.
Параллельно пересмотрели cron-задачи:
- разобрали выполняемые скрипты;
- нашли ресурсоёмкие процессы;
- изменили расписание;
- убрали конкуренцию фоновых задач с пользовательской нагрузкой.
Также скорректировали настройки Apache для работы с большим количеством одновременных соединений.
2. Обновить фундамент
Старый сервер уже сам по себе становился проблемой.
CentOS 7 находился в конце жизненного цикла, PHP 7.3 давно устарел, а версия Битрикс не позволяла использовать современные возможности инфраструктуры.
Поэтому приняли решение перейти на новый VPS и современный стек:
- актуальную Bitrix VM;
- современную версию PHP;
- MySQL 8;
- обновлённую версию 1С-Битрикс.
Сначала развернули полную копию проекта на отдельной инфраструктуре.
Далее провели последовательное обновление:
PHP 7.3 → PHP 8.x → актуальная версия 1С-Битрикс.
Большая проблема — 120 ГБ картинок
Еще до подготовки к переезду было ясно, что есть серьезное ограничение.
На сервере было около 140 ГБ данных, из которых примерно 120 ГБ занимали изображения.
При этом свободного места оставалось около 10%.
Хранить такой объём медиаданных на локальном диске приложения было архитектурно неоптимально.
Поэтому изображения решили вынести в S3-хранилище.
Это позволило:
- разгрузить сервер приложения;
- уменьшить размер проекта;
- отделить медиаданные от инфраструктуры сайта;
- упростить дальнейшее масштабирование;
- не зависеть от размера локального диска VPS.
3. Перенесли медиатеку в S3
После обновления Битрикс подключили S3 и запустили перенос изображений.
И здесь нас ждал неприятный сюрприз.
Стандартный механизм Битрикс переносил изображения со скоростью примерно 1–2 ГБ в час.
При 120 ГБ данных это означало до 60 часов непрерывной миграции.
Останавливать редакцию на такой срок было невозможно.
Что сделали
Изменили стратегию миграции.
Редакцию вернули к работе, а перенос изображений продолжили параллельно.
После завершения основных подготовительных работ снова зафиксировали проект, выполнили финальную синхронизацию и завершили перенос за ночь.
Утром редакция уже работала на новой инфраструктуре.
Неожиданный бонус
В процессе переноса обнаружили около 20 ГБ устаревших resize-копий изображений, которые больше не использовались сайтом.
В результате в S3 перенесли около 90 ГБ актуальных изображений.
Размер данных самого проекта сократился:
120 ГБ → 15 ГБ
То есть медиаданные, занимавшие около 120 ГБ локального диска, были практически полностью вынесены из проекта.
Объём локальных данных сократился примерно на 87,5%.
4. Оптимизировали работу 1С-Битрикс
После стабилизации инфраструктуры перешли непосредственно к приложению.
Основная проблема находилась в работе с новостным инфоблоком.
128 тысяч публикаций — это уже объём, при котором неэффективный запрос может стать серьёзной проблемой.
Нашли тяжёлые выборки, оптимизировали запросы и добавили кеширование там, где оно действительно снижало нагрузку.
Отдельно переработали работу кастомного кеша, чтобы он не разрастался бесконтрольно.
В результате серверу стало требоваться значительно меньше ресурсов для выполнения тех же операций.
5. Переехали на новую инфраструктуру
Когда размер проекта удалось привести в адекватное состояние, сделали backup и перенесли проект на новый VPS.
Параллельно:
- обновили системное ПО;
- обновили PHP;
- обновили MySQL;
- обновили 1С-Битрикс;
- настроили работу с S3;
- пересмотрели конфигурацию веб-сервера;
- настроили мониторинг;
- проверили cron;
- оптимизировали кеширование.
Что пошло не по плану
Большой legacy-проект невозможно перенести без сюрпризов.
60 часов на перенос изображений
Первоначально планировали выполнить перенос с остановленной редакцией.
Но скорость 1–2 ГБ/час сделала такой сценарий неприемлемым.
Решение: разделили миграцию на фоновый и финальный этапы. Основную часть данных перенесли при работающей редакции, а финальную синхронизацию выполнили ночью.
После обновления выросло количество обращений от редакции
Между старой и актуальной версиями Битрикс было несколько лет обновлений, включая серьёзные изменения в механизмах безопасности.
После запуска редакторы начали сталкиваться с:
- срабатыванием проактивного фильтра;
- блокировками сессий;
- другими отличиями в поведении административной части.
Это уже была не техническая проблема сервера, а проблема перехода пользователей на новую версию системы.
Решение: выделили отдельную команду на период запуска, собрали типовые проблемы и подготовили инструкции.
Через несколько дней около 99% подобных вопросов закрывались готовыми решениями.
Новый сервер получил проблемный IP
В процессе переезда обнаружили, что выданный VPS IP-адрес не подходит для нормальной работы части пользователей.
Предположительно, адрес попал под фильтрацию сетевого трафика.
Проверить конкретную причину срабатывания таких ограничений публичными инструментами невозможно, а повлиять на сам список фильтрации мы не могли.
Решение: заменили IP-адрес сервера.
Вся процедура заняла около 15 минут, после чего доступ восстановился.
Результат
За время проекта мы не просто «починили падения».
Мы привели в порядок инфраструктуру и архитектуру проекта, который развивался около 10 лет.
Было
- 128+ тысяч публикаций;
- ~120 ГБ изображений на локальном сервере;
- ~140 ГБ общего объёма данных;
- 10% свободного места на диске;
- CentOS 7;
- PHP 7.3;
- устаревшая версия 1С-Битрикс;
- регулярные падения сайта;
- тяжёлые cron-задачи;
- лишний трафик от ботов;
- неоптимальные запросы и кеширование;
- backup раз в неделю.
Стало
- современная серверная инфраструктура;
- актуальный стек PHP / MySQL / 1С-Битрикс;
- изображения вынесены в S3;
- локальный объём данных сокращён с 120 до 15 ГБ;
- оптимизированы тяжёлые запросы;
- переработано кеширование;
- пересмотрены cron-задачи;
- настроена фильтрация ботов;
- подключён мониторинг;
- проект перенесён на новый VPS;
- миграция выполнена с минимальным простоем редакции.
Главное в этом кейсе
Для нас это не история про «поставили сервер мощнее».
Наоборот.
Это и есть то, что мы называем техническим наведением порядка в legacy-проекте.
Когда сайт годами работает, обрастает функциональностью, контентом и техническим долгом, его не обязательно переписывать с нуля.
Иногда гораздо эффективнее системно разобрать то, что уже есть, убрать узкие места и привести инфраструктуру к современному состоянию.
Именно этим мы и занимаемся в MONOPLAN.
