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

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

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

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

Архитектура затрудняла безопасную эксплуатацию

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

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

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

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

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

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

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

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

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

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

Аварийные процедуры не были оформлены как воспроизводимый процесс

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

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

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

Релизы были связаны с инфраструктурным риском

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

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

Система испытывала постоянную внешнюю нагрузку

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

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

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

Перестроили базовую архитектуру

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

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

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

Настроили мониторинг и эксплуатационный контроль

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

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

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

Построили систему резервного копирования

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

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

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

Проверили сценарии восстановления

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

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

Исследовали производительность MySQL

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

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

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

Организовали релизы через инфраструктурные клоны

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

На клоне команда клиента могла обновить 1С-Битрикс, сменить версию PHP, обновить Composer и проверить зависимости. Перед боевым переключением данные повторно синхронизировались с рабочей системой.
После проверки балансировщик переводил трафик на новый сервер. Фоновые задания включались на новой машине и отключались на старой. Старый сервер сохранялся на время наблюдения, затем снимался с мониторинга и удалялся.

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

Усилили сетевую защиту

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

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

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

Привели инфраструктуру к управляемому состоянию

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

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

Результат

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

основные серверы и сервисы находятся под постоянным мониторингом

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

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

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

сетевой трафик фильтруется с учетом внешних сервисов и автоматических запросов

крупные обновления выполняются на инфраструктурных клонах

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

изменения версии PHP, 1С-Битрикс и зависимостей можно протестировать до выхода в продакшен

причины низкой производительности базы проверены на отдельном стенде

устаревшие серверы и облачные ресурсы последовательно выводятся из эксплуатации

архитектура и эксплуатационная документация поддерживаются в актуальном состоянии

Вывод

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

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

Проект перешел от реакции на отдельные технические симптомы к последовательному управлению жизненным циклом инфраструктуры.

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

Error get alias

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

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

Стабилизация и развитие инфраструктуры нескольких проектов на 1С-Битрикс

О клиенте

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