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

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

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

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

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

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

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

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

Публичные сайты были уязвимы для повторных DDoS-атак

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

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

Перенос мог нарушить работу связанных сервисов

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

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

Не было полноценного контроля доступности

До начала поддержки у команды не было достаточных данных мониторинга, в том числе истории нагрузки во время DDoS-атак.

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

Жалобы на скорость не всегда были связаны с сервером

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

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

Инфраструктура продолжала меняться после первого переезда

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

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

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

Провели первичный аудит и подобрали инфраструктуру

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

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

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

Подготовили новое окружение

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

До переключения разработчики получили возможность проверить сайты через локальную подмену адресов. Это позволило тестировать новое окружение без изменения публичных DNS-записей и без влияния на посетителей.

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

Перенесли доменную и почтовую конфигурацию

Перед переключением была собрана структура DNS основного домена и поддоменов.

На новую площадку перенесли необходимые A-, MX-, TXT- и другие записи. Отдельно проверили поддомены, которые указывали на внешние серверы, чтобы миграция основной инфраструктуры не нарушила работу связанных систем.

После переключения протестировали отправку писем на разные почтовые сервисы и работу внутренних адресов.

Выполнили переключение с возможностью отката

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

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

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

После подтверждения работоспособности DNS-записи переключили на новый сервер.

Закрыли сервер защитным прокси

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

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

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

Настроили содержательный мониторинг

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

Мониторинг также контролировал:

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

Организовали резервное копирование и контроль емкости

Для серверов и приложений настроили резервное копирование. Ошибки создания копий автоматически превращались в задачи для инженерной команды.

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

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

Сопровождали развитие проекта

В процессе поддержки команда обновляла версии PHP, меняла параметры PHP-FPM и веб-сервера, корректировала задания планировщика, создавала новые окружения и переносила отдельные сайты и директории.

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

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

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

Когда действующей конфигурации стало недостаточно для дальнейшей эксплуатации, проект перенесли на новый сервер.

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

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

Результат

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

сайты перенесены на инфраструктуру, подготовленную для постоянной поддержки

сохранена структура доменов, поддоменов, почтовых и внешних сервисов

исходный адрес сервера скрыт за защитным прокси

настроен мониторинг серверов, сайтов и фактического содержимого страниц

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

появился регламент аварийных обращений к дежурному инженеру

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

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

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

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

Вывод

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

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

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

Error get alias

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

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

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

О клиенте

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