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

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

Параллельно инфраструктура развивалась: появлялись новые домены и тестовые площадки, обновлялись версии PHP, менялись требования к доступам, резервному копированию и защите от автоматизированного трафика. Эти изменения требовалось проводить без нарушения работы основного сайта.

Какие проблемы мы обнаружили

Ошибки 502 имели несколько разных причин

Первые обращения выглядели одинаково: страницы периодически возвращали 502, а затем снова начинали отвечать нормально. Однако расследование показало, что за одинаковым симптомом стояли разные процессы.

В одном из случаев веб-сервер не успевал получить ответ от обработчика PHP. Мы разделили системные логи, включили запись ошибок PHP и сбор медленных запросов к базе данных. Трассировка загрузки главной страницы показала сотни обращений к базе за один запрос. В журнале медленных запросов обнаружились операции, которым не хватало индексов и которые обрабатывали большой объем данных.

В другом случае воркеры Apache завершались с ошибкой сегментации в модуле PHP. Для диагностики была включена запись дампов. Анализ показал связь с обработкой кеша 1С-Битрикс. После исключения каталогов кеша из проблемного механизма падения прекратились.

Позднее ошибки 502 возникали из-за интенсивного автоматизированного трафика. Отдельные боты и адреса из облачных сетей создавали десятки тысяч запросов, занимали ресурсы веб-сервера и ухудшали доступность сайта.

Производительность ограничивали диски и запросы к базе данных

Размер файлов основного сайта составлял около 500 ГБ. Из-за объема данных виртуальная машина работала на HDD, тогда как доступного места на SSD было недостаточно.

Одновременно приложение выполняло тяжелые SQL-запросы. Один из регулярно повторявшихся запросов в среднем работал несколько секунд и перебирал миллионы строк. В других эпизодах база читала почти два миллиона строк, чтобы вернуть около тысячи записей.

В результате дисковая подсистема и процессор тратили ресурсы не только на полезную работу сайта, но и на обработку неоптимальных выборок. Увеличение лимитов PHP могло временно уменьшить количество ошибок, но не устраняло источник задержек.

Несколько проектов конкурировали за общие ресурсы

На одном физическом сервере находились несколько виртуальных машин и сайтов. Нагрузка тестовой площадки, фоновые операции и тяжелые запросы одного проекта могли влиять на соседние системы.

Из-за этого замедление нельзя было диагностировать только на уровне отдельного домена. Требовалось сопоставлять нагрузку виртуальных машин, состояние базы данных, дисковый ввод-вывод и внешние запросы.

Защита от нежелательного трафика требовала постоянной настройки

Для ограничения парсинга и автоматических запросов использовались белые и черные списки IP-адресов, блокировка по User-Agent, странам и автономным системам.

Такая защита иногда затрагивала полезный трафик. В одном из случаев был заблокирован поисковый робот. В других случаях разработчики и сотрудники клиента получали 403 при смене адреса подключения.

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

Резервное копирование зависело от устаревающей инфраструктуры

Резервные копии первоначально хранились на отдельном физическом сервере. Когда провайдер объявил о выводе этого оборудования из эксплуатации, возник риск потерять площадку хранения или срочно переносить ее на другой сервер.

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

Этот эпизод показал необходимость не только создавать копии, но и понимать состояние файловой системы до запуска процедуры восстановления.

Что было сделано

Настроили наблюдаемость и диагностику

Для сайта были настроены проверки доступности в Zabbix. Система фиксировала недоступность, ошибки HTTP и сроки действия SSL-сертификатов.

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

Это позволило отличать проблемы приложения от сетевых сбоев у провайдера, перегрузки базы данных, падений PHP и внешнего автоматизированного трафика.

Скорректировали серверное окружение

Были изменены параметры PHP и MySQL под требования 1С-Битрикс. Увеличивались лимиты памяти и времени выполнения скриптов, настраивались необходимые расширения, корректировался размер буфера InnoDB.

Для снижения файловой нагрузки кеш 1С-Битрикс был перенесен в Memcached, а хранение сессий — в Redis. Эти изменения не решили проблему медленных запросов к базе данных, но отделили кеш и сессии от дисковой подсистемы и упростили дальнейшую диагностику.

Обновления PHP сначала проверялись на тестовой площадке. После проверки требуемая версия устанавливалась на основном сайте. Такой порядок снижал риск несовместимости с кодом и модулями 1С-Битрикс.

Подготовили отдельные и тестовые площадки

Для новых версий сайта создавались отдельные базы данных, домены и виртуальные машины. Настраивались DNS, SSL, параметры веб-сервера, редиректы, cron-задачи и почтовые функции.

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

Снизили влияние автоматизированного трафика

Мы анализировали источники всплесков запросов и блокировали ботов, создававших заметную нагрузку. Ограничения применялись по IP-адресам, подсетям, автономным системам и User-Agent.

Полезные адреса добавлялись в белые списки. После обнаружения ошибочной блокировки поискового робота правила корректировались.

Изменения фиксировались в системе управления конфигурацией. Благодаря этому настройки не оставались ручными правками на отдельных серверах и могли быть воспроизведены.

Перенесли резервные копии в объектное хранилище

Вместо аренды нового физического сервера для резервных копий было выбрано S3-совместимое объектное хранилище того же провайдера.

Мы создали хранилище и сервисные учетные данные, перенастроили задания резервного копирования и проверили прохождение первых копий. Новая схема убрала зависимость от конкретного устаревающего сервера и позволила оплачивать фактически занимаемый объем.

Результат

Инфраструктура проекта перешла от реакции на отдельные сбои к управляемой эксплуатации. Повторяющиеся ошибки стали диагностироваться по логам, метрикам и данным о нагрузке, а не только по сообщениям пользователей.

Не все ограничения можно было устранить на уровне серверной поддержки. Часть задержек оставалась связана с SQL-запросами и кодом приложения. Инженерная диагностика позволила установить эту границу ответственности и определить дальнейшие варианты: оптимизацию запросов разработчиками или перенос проекта на сервер с более производительными SSD.

настроен постоянный мониторинг доступности сайтов и SSL-сертификатов

разделены и дополнены системные логи

организован сбор медленных запросов к базе данных

устранена причина одного из типов падения воркеров Apache

выявлены ограничения дисковой подсистемы и неоптимальные SQL-запросы

кеш и сессии вынесены в отдельные сервисы

обновления PHP проверяются на тестовой площадке

снижено влияние агрессивных ботов и парсеров

правила защиты зафиксированы в системе управления конфигурацией

резервные копии перенесены с устаревающего сервера в объектное хранилище

доступ разработчиков отделен от административного управления инфраструктурой

Вывод

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

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

Смотрите другие
кейсы по Bitrix

Error get alias

Хотите передать
свою инфраструктуру в надежные руки?

Будем рады проконсультировать вас и обсудить проект.

Cтабилизация и развитие инфраструктуры сайта на 1С-Битрикс

О клиенте

Исходная ситуация