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

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

В дальнейшем инфраструктура стала сложнее. Помимо основного сайта появились отдельные серверы баз данных, Redis, объектное хранилище, CDN, staging-среда, контейнерные приложения и Kubernetes-кластер. Разрозненные задачи по устранению сбоев постепенно превратились в постоянную работу по обеспечению доступности и управляемости всей платформы.

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

Причины замедлений находились на разных уровнях системы

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

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

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

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

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

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

Файловые сессии и локальные данные мешали горизонтальному масштабированию

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

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

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

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

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

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

Долгие запросы конфликтовали с тайм-аутами разных компонентов

При выполнении тяжёлых операций пользователи периодически получали ошибки 502. Запрос проходил через несколько уровней — CDN или защитный сервис, ingress, веб-приложение и API. На каждом уровне действовали собственные ограничения времени ожидания.

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

Ресурсы Kubernetes не всегда соответствовали реальной нагрузке

Контейнерная часть системы требовала отдельной настройки масштабирования. В инфраструктуре возникали ситуации, когда deployment не набирал нужное количество реплик, rollout не завершался, pod долго оставался в неготовом состоянии или CronJob завершался ошибкой.

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

Ошибки проявлялись за пределами прикладных логов

В одном из случаев поисковая система фиксировала многочисленные ответы 500, 502 и 503 при обходе страниц, хотя в логах основного backend-приложения соответствующих ошибок не было.

Проверка показала, что часть отказов возникала между внешним защитным контуром, ingress и контейнерами приложения. В логах Kubernetes встречались обращения к уже удалённым pod и ошибки самого frontend-приложения. Это означало, что диагностика только по backend-логам давала неполную картину.

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

Staging-среда расходилась с production

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

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

Эксплуатационные процессы оставались разрозненными

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

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

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

Построена система наблюдения за инфраструктурой

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

В дальнейшем мониторинг охватил серверы, сайты, MySQL, Redis, Elasticsearch, резервные копии, Kubernetes-компоненты, deployments, CronJob и доступность отдельных сервисов. Для контейнерных компонентов добавлялись метрики Prometheus, а для централизованного анализа событий использовалось хранилище логов.

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

Перестроена работа с базами данных

Для MySQL настроили схему master-slave и контроль отставания реплики. Серверы базы данных масштабировали и перенастраивали по мере изменения нагрузки.

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

Такая схема уменьшила зависимость проекта от одного экземпляра базы и сделала восстановление более управляемым.

Состояние приложения вынесено из отдельных серверов

Сессии перенесли из файловой системы в Redis. Redis также использовали для файлового кеша приложения и подключили к системе мониторинга.

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

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

Фоновые процессы отделены от пользовательских запросов

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

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

Развёрнута и настроена контейнерная инфраструктура

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

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

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

Настроены staging и процессы развёртывания

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

Разделялись настройки production и staging, проверялась работа автоматического деплоя, исправлялись ошибки pipeline и установки компонентов приложения.

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

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

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

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

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

Добавлены эксплуатационные и защитные механизмы

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

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

Результат

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

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

база данных получила репликацию, внешние резервные копии и холодную копию

сессии и кеш были вынесены в Redis

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

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

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

для нагруженных сервисов были выделены более производительные Kubernetes-узлы

staging стал регулярно синхронизироваться с production

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

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

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

Вывод

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

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

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

Error get alias

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

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

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

О клиенте

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