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

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

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

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

Инфраструктура реагировала на нагрузку нестабильно

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

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

Приложение и серверная конфигурация менялись несогласованно

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

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

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

Критические процессы не были достаточно контролируемыми

Проект зависел от нескольких фоновых механизмов:

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

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

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

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

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

Проект зависел от исторически сложившейся серверной среды

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

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

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

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

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

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

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

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

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

Настроили постоянное наблюдение за состоянием проекта

Сайт и сервер были подключены к мониторингу. Контролировались:

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

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

Стабилизировали работу веб-сервера и базы данных

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

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

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

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

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

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

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

Сопровождали обновления программной платформы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат

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

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

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

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

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

обновления PHP, системы управления и серверных компонентов проходят поэтапно

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

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

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

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

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

Вывод

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

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

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

Error get alias

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

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

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

О клиенте

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