Работа началась с переноса проектов на новый сервер. Для этого потребовалось собрать и упорядочить доступы, подготовить виртуальную машину, перенести сайты и базы данных, настроить DNS и проверить работу сервисов после переключения.

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

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

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

Инфраструктура не была подготовлена к неравномерной нагрузке

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

Мониторинг фиксировал высокий Load Average, исчерпание лимита подключений MySQL и достижение предельного числа процессов веб-сервера. Когда лимиты заканчивались, новые запросы не могли нормально обрабатываться. Это приводило к замедлению сайта или полной недоступности.

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

Состояние сайта зависело от нескольких связанных компонентов

Недоступность сайта не всегда означала отказ самого сервера. Причиной могли быть остановка MySQL или Apache, ошибки конфигурации Nginx, исчерпание лимитов, проблемы DNS или сетевой доступности.

Например, после прекращения использования внешней DDoS-защиты одна из DNS-записей продолжила указывать на старую точку входа. В результате клиент не мог подключиться к серверу по SSH, хотя сам сервер работал и принимал соединения по правильному адресу.

Без централизованного мониторинга такие ситуации выглядели одинаково: «сайт не работает». Для восстановления требовалось сначала определить, какой именно уровень инфраструктуры дал сбой.

Дисковое пространство регулярно подходило к пределу

На сервере накапливались кэш 1С-Битрикс, резервные копии и другие данные проекта. Мониторинг неоднократно фиксировал остаток менее 5%, а в отдельных случаях — менее 1% свободного места.

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

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

Резервные копии существовали, но систему хранения требовалось развивать

На первом этапе базы данных и файлы сайта копировались ежедневно. Копии передавались на отдельный сервер и хранились с ограниченной глубиной.

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

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

Требовалось контролировать безопасность сервера и приложения

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

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

При этом SSH-доступ нельзя было оставлять открытым для всех адресов. Доступ ограничивался правилами межсетевого экрана и выдавался только с согласованных IP.

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

Перенесли проект и стандартизировали сервер

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

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

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

Настроили комплексный мониторинг

Под наблюдение поставили:

доступность сайта и сервера;
работу SSH, MySQL, Apache и агента мониторинга;
загрузку процессора и системы;
использование подключений к базе данных;
лимиты процессов веб-сервера;
свободное место и количество inode;
размер каталогов кэша;
сроки действия SSL-сертификатов и делегирования доменов;
успешность резервного копирования.

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

Организовали подготовку к периодам высокой нагрузки

Перед запланированными мероприятиями мы анализировали текущие графики и заранее согласовывали увеличение ресурсов.

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

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

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

Проработали сценарий защиты от DDoS

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

Для критического периода была подключена внешняя защита с изменением схемы прохождения трафика. После окончания работ инфраструктуру вернули к стандартной конфигурации и восстановили прямые DNS-записи.

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

Выстроили резервное копирование

Базы данных копировались отдельно от файлов проекта. Из файловых копий исключили временные данные, логи и воспроизводимые каталоги кэша. Это уменьшило объём архивов и ускорило передачу данных.

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

Когда объём резервных копий вырос, хранение перенесли в S3-совместимое объектное хранилище. Для этого создали отдельный бакет и сервисную учётную запись, настроили резервное копирование и проверили успешное создание архива.

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

Управляли дисковым пространством

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

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

Поддерживали безопасность и контролировали изменения

SSH-доступ ограничили согласованными IP-адресами. Временные учётные записи и доступы, использованные при миграции, блокировались после завершения работ.

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

При обнаружении бэкдора в Битриксе проблема была вынесена в отдельное направление работ. Это позволило разделить ответственность между безопасностью серверной инфраструктуры и состоянием кода приложения.

Результат

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

состояние сервера и ключевых компонентов стало контролироваться автоматически

причины недоступности сайта стало возможно определять по уровню инфраструктуры

появилась процедура временного увеличения ресурсов перед мероприятиями

критические события стали поступать дежурным инженерам

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

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

риски заполнения диска стали выявляться до остановки сервисов

SSH-доступ был ограничен доверенными адресами

обновления безопасности стали выполняться по согласованной процедуре

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

Вывод

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

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

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

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

Error get alias

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

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

Повышение устойчивости и развитие инфраструктуры сайта на 1С-Битрикс

О клиенте

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