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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Веб-серверы не выдерживали отдельные сценарии нагрузки

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

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

Фоновые задачи были важной, но нестабильной частью системы

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

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

Почта и внешние интеграции зависели от локальных настроек

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

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

Инфраструктура развивалась быстрее, чем её эксплуатационные правила

В поддержку последовательно добавлялись новые серверы, сайты, боты, домены и вспомогательные сервисы. Появились контейнерные окружения, кэширование, новые версии PHP и переносы в облако.

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

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

Упорядочили базовую конфигурацию серверов

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

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

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

Настроили контроль дисков и журналов

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

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

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

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

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

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

Стабилизировали базы данных

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

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

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

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

Под наблюдение поставили доступность серверов и сайтов, состояние MySQL, Apache, Nginx, Postfix, Memcached и других сервисов. Контролировались нагрузка, память, диски, внутренние порты, срок действия сертификатов, резервные копии и выполнение cron-заданий.

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

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

Работали с производительностью веб-приложений

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

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

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

Упорядочили фоновые задания

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

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

Перенесли часть проектов в облачную инфраструктуру

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

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

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

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

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

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

Результат

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

состояние сайтов, серверов и ключевых сервисов контролируется централизованно

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

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

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

конфигурации новых серверов частично автоматизированы

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

проекты получили управляемый процесс переноса на новую инфраструктуру;

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

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

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

Вывод

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

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

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

Error get alias

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

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

Стабилизация и развитие инфраструктуры e-commerce-проектов

О клиенте

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