Владельцу магазина не обязательно знать каждую настройку сервера. Но полезно понимать, где сохраняется заказ, почему письмо может опоздать и какие компоненты нужны для восстановления. Такая схема помогает правильно поставить задачу поддержке и не считать любой отказ проблемой самой CMS.
Рассмотрим условный магазин на WordPress, 1С-Битрикс или собственном PHP-приложении. Конкретная реализация будет различаться, однако путь пользователя обычно затрагивает несколько технических уровней. Они могут размещаться на одной машине или в отдельных сервисах. Число серверов не меняет необходимости учитывать все зависимости.
Веб-сервер принимает запрос
Домен и DNS помогают браузеру найти адрес, а HTTPS — установить защищённое соединение с нужным узлом. Перед приложением могут работать CDN, защитный прокси и балансировщик. Веб-сервер принимает запрос и либо отдаёт готовый файл, либо передаёт обработку приложению.
Ошибка на этом участке может проявиться до запуска CMS: неверный сертификат, недоступный адрес или правило маршрутизации. Поэтому при недоступности магазина сначала полезно определить, устанавливается ли соединение и какой компонент возвращает ответ. Открывающаяся статическая страница ещё не подтверждает работу каталога, кабинета или оформления покупки.
Приложение выполняет правила магазина
Код CMS, темы и модулей решает, что показать посетителю, можно ли оформить заказ и какие данные сохранить. В PHP-проекте запрос обрабатывается в настроенном окружении с определёнными расширениями, лимитами и правами. Команда фонового задания может использовать другое окружение, чем веб-страница.
Плагины и собственные доработки связывают приложение с оплатой, доставкой и учётной системой. Перед обновлением важно знать эти связи и проверять сценарий целиком. Если модуль завершился без видимой ошибки, но отправил неверный статус заказа, техническое выполнение не означает правильный результат для магазина.
База хранит структурированные данные
В базе обычно находятся товары, пользователи, заказы и настройки. Набор таблиц и способов доступа зависит от платформы. На скорость влияют запросы, индексы, блокировки и ресурсы, поэтому одной характеристики процессора недостаточно для оценки производительности магазина.
Для восстановления нужен согласованный набор данных. Если база ссылается на изображение, которое отсутствует в файловой копии, часть каталога останется повреждённой. Разделяйте резервирование базы и всего проекта. Перед выделением отдельного узла измерьте нагрузку и сетевые требования; подробнее — в статье о выносе базы на другой сервер.
Файлы и кеш выполняют разные задачи
Код приложения, фотографии товаров, документы покупателей и временные данные требуют разного обращения. Код можно получить из проверенного релиза, а уникальные загрузки пользователя часто невозможно восстановить без копии. Укажите, какие каталоги меняются и куда попадают новые файлы.
Кеш ускоряет повторную выдачу, но не должен подменять основное хранилище. Важно знать, как обновляется страница после изменения цены или остатка. Персональные ответы нельзя смешивать с общими. Для разных видов данных могут использоваться разные кеши, а полная очистка иногда создаёт дополнительную нагрузку на приложение.
Фоновые задачи продолжают работу после ответа
Письма, выгрузки, импорты и длительные операции удобно выполнять отдельно от ожидания браузера. Для этого нужны планировщик или очередь, обработчик и контроль результата. Статус «задание создано» не означает, что заказ уже передан в учётную систему.
Следите за последним успехом, задержкой и числом повторных попыток. После сбоя накопившиеся задачи не должны перегрузить базу или отправить одно уведомление несколько раз. Для критичных операций сохраняйте идентификатор и понятное состояние обработки. Особенности связки магазина с учётной системой разобраны в контроле обмена с 1С.
Внешние сервисы имеют свои границы
Платёжный шлюз, доставка, почта и CRM могут быть недоступны независимо от вашего сервера. Приложению нужны ограничения ожидания и понятное поведение при ошибке. Нельзя автоматически считать покупку неуспешной только потому, что ответ от внешней системы не дошёл: операция могла выполниться.
Запишите контакты поставщиков, используемые аккаунты, тестовые режимы и доверенные адреса. Для диагностики полезны время и идентификатор операции без секретных данных. При нескольких подрядчиках назначьте того, кто связывает наблюдения между компонентами. Иначе каждый участник подтвердит исправность своего сервиса, а пользовательский сценарий останется сломанным.
Соберите схему эксплуатации
Для каждого компонента укажите размещение, доступы, владельца обновлений, копирование и контроль. Пройдите один условный заказ от открытия товара до письма и обмена. Уточните, где подтверждается каждый этап и что произойдёт при остановке одного узла. Это нагляднее длинного перечня установленного ПО.
Обновляйте схему при подключении новой интеграции и смене размещения. Используйте её для мониторинга, плана восстановления и передачи проекта. Даже небольшой магазин выигрывает от понимания зависимостей: исчезают необоснованные перезапуски и предположение, что архив папки сайта содержит всё необходимое.
Для каждой связи полезно указать способ подтверждения результата. Соединение с сервисом может работать, пока данные обрабатываются неправильно. Поэтому карта должна включать не только адреса, но и контрольные операции сотрудников.
Если нужно разобраться в инфраструктуре вашего магазина, напишите в HOMEWEB. Укажите CMS, размещение и подключённые оплаты, доставку и учётную систему — обсудим состав обследования.
