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

Инфраструктура складывалась постепенно. На одном сервере могло работать большое количество Docker-контейнеров, соответствующих разным сайтам и поколениям приложений. Контейнеры запускались через отдельные docker-compose.yml в каталогах проектов. Для маршрутизации запросов использовался общий reverse proxy, а под отдельные домены выделялись собственные IP-адреса.

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

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

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

Инфраструктура была неоднородной

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

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

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

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

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

push или обновление из репозитория не проходили;
изменения в основной ветке не появлялись на production;
разработчик не мог выложить верстку;
автоматический git pull или связанная с ним задача cron завершались ошибкой;
тестовая среда отличалась от боевой;
у сотрудников не хватало прав для публикации изменений.

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

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

Инфраструктура обслуживала множество доменов и поддоменов. Это требовало контролировать:

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

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

Сайты зависели от внешних систем и фоновых процессов

Для работы проектов использовались CRM, 1С, почта, коллтрекинг и фоновые задания. Интеграции были сравнительно простыми с технической точки зрения, но критичными для бизнеса.

Сайт мог оставаться доступным, однако:

заявки переставали поступать в CRM;
оплаты не выгружались в 1С;
почтовые сообщения не отправлялись или не принимались;
фоновые обработчики переставали запускаться;
базы тестовых сред теряли актуальность.

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

Знания об инфраструктуре были связаны с отдельными специалистами

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

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

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

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

Команда получила доступ к текущим и новым серверам, разобрала состав размещенных сервисов и уточнила назначение основных компонентов.

Были определены:

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

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

Подготовили новые серверы и перенесли проекты

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

После переноса проверялись:

открытие сайтов;
маршрутизация доменов;
работа SSL;
подключение к базам;
выполнение cron-задач;
отправка почты;
обмен с внешними системами;
публикация изменений из репозиториев.

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

Привели развертывание и доступы в рабочее состояние

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

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

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

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

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

Дополнительно проверялись:

работоспособность резервного копирования;
состояние cron-задач;
автозапуск сервисов;
корректность конфигурации Nginx;
доступность отдельных портов;
состояние MySQL и параметры его работы.

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

Организовали регулярную эксплуатацию сайтов

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

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

Результат

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

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

Вывод

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

Отдельные сбои — неприменившийся push, остановившийся cron, закончившееся место или недействительный сертификат — были проявлениями одной системной причины: инфраструктура росла быстрее, чем процессы ее эксплуатации.

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

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

Error get alias

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

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

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

О клиенте

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