Ваш дашборд аптайма вам лжет. Он говорит, что ваш сайт онлайн. Главная страница загружается. SSL-сертификат действителен. Каждый пиксель отображается именно там, где должен. Тем временем ваш магазин не обрабатывал реальных заказов уже шесть часов, и первым об этом узнает ваш клиент, задаваясь вопросом, почему ежедневный отчет по продажам замер на нуле.
В этом заключается фундаментальная ошибка: относиться к e-commerce платформе как к сайту-визитке. Стандартный мониторинг доступности задает ровно один вопрос: вернул ли сервер статус 200 OK? Для магазина на WooCommerce этот вопрос совершенно не имеет смысла. Сервер может работать как часы, страница оформления заказа может выглядеть безупречно, но деньги все равно перестают поступать. Это «тихий сбой», и он обходится гораздо дороже, чем громкий крах сервера.
Когда статус «Online» ничего не значит
Ответ 200 доказывает лишь то, что PHP завершил выполнение и отправил HTML обратно в браузер. Это не доказывает, что загрузился JavaScript от Stripe. Это не доказывает, что кнопка оформления заказа отправляет данные на рабочий эндпоинт. Это не доказывает, что сработал вебхук, обновились остатки или отправилось письмо с подтверждением. Посетитель видит полностью загруженную страницу оформления заказа, вводит номер карты, нажимает «купить», и ничего не происходит. Или, что еще хуже, заказ помечается как неудачный, хотя платеж на самом деле прошел.
Если ваша стратегия мониторинга начинается и заканчивается пингом главной страницы, вы следите не за тем процессом. Вы заметите сбой темы, который «сломает» хедер. Но вы не заметите платежный шлюз, застрявший в тестовом режиме. Вы узнаете об этом только тогда, когда кто-то проверит график выручки или ответит на гневный телефонный звонок.
Пять способов, которыми магазин «умирает», не выходя из строя
Вот конкретные сбои, из-за которых магазин на WooCommerce сохраняет 100% аптайма, в то время как конверсия падает до нуля:
- Платежные шлюзы застревают в тестовом режиме. Разработчик переключает Stripe или PayPal в режим sandbox, чтобы воспроизвести баг, решает проблему и забывает вернуть настройки обратно. Реальные клиенты вводят реальные номера карт и натыкаются на стену тестового режима. Иногда ошибка очевидна, иногда — нет, и транзакция просто зависает.
- Обновление плагина ломает шаблон оформления заказа. WooCommerce выпускает обновление или конструктор страниц вносит изменения, и форма оформления заказа перестает отображаться корректно. Страница загружается, но поля оплаты исчезают или кнопка оформления заказа выдает ошибку JavaScript при нажатии. Сервер в порядке. Пользовательский опыт разрушен.
- Всплеск неудачных заказов из-за ошибок шлюза. Истекают API-ключи. Возникают несоответствия валют. Меняются требования 3D Secure. Эти ошибки отображаются как неудачные заказы в админке WooCommerce, а не как ошибки сервера в ваших логах аптайма. Смотрите не на тот экран — и вы пропустите медленную утечку выручки.
- Зависает серверный конвейер обработки заказов. Интеграция со сторонней ERP-системой, кастомная функция синхронизации остатков или калькулятор стоимости доставки зависают по таймауту после того, как клиент нажал «купить». Заказ бесконечно остается в статусе «в ожидании» (pending). Клиент обновляет страницу, путается и уходит. Ваши метрики хостинга по-прежнему «зеленые».
- Поток заказов просто останавливается без видимых причин. Нет фатальной ошибки. Нет конфликта плагинов. Кэш просто начинает отдавать устаревший JavaScript для оформления заказа. Баннер управления согласием (consent-management banner) блокирует iframe платежной системы. Узел CDN отдает старую версию скрипта. Сайт онлайн. Оформление заказа — нет.
Мониторинг того, что действительно важно
Чтобы отловить такие сбои, нужно перестать следить за инфраструктурой и начать следить за бизнес-логикой. Вот как построить стратегию мониторинга, учитывающую сложность реального процесса транзакций.
Мониторьте поток заказов, а не только аптайм. Отслеживайте, можно ли добавить товар в корзину, отвечает ли эндпоинт оформления заказа валидным JSON и загружается ли страница «Спасибо за покупку» после успешной оплаты. Если вы полагаетесь на внешние инструменты пинга, настройте их так, чтобы они проверяли критический путь, а не только корень домена.
Сравнивайте количество неудачных заказов с базовым показателем за семь дней. Не используйте абсолютные числа. Пять неудачных заказов в час могут быть нормой для утра понедельника после акции. Пять неудачных заказов в час в спокойный полдень среды — это тревожный сигнал. Смотрите на отклонение от вашего собственного скользящего базового показателя, а не на произвольные пороги.
Проверьте, не находятся ли рабочие шлюзы в режиме песочницы (sandbox mode). Сделайте это пунктом вашего чек-листа развертывания и автоматизированных тестов. Проверьте настройки активных шлюзов или проанализируйте публичные API-ключи, чтобы убедиться, что это рабочие учетные данные. Магазин никогда не должен запускаться, если он настроен на тестовую среду.
Запускайте ежедневный дымовой тест (smoke test) на стороне сервера. Это самый эффективный способ обнаружить неработающую страницу оформления заказа до того, как это заметят люди.
Создание ежедневного дымового теста
Правильный дымовой тест создает реалистичный заказ, не оставляя хаоса в вашей базе данных. Процесс выглядит так: создается скрытый виртуальный товар, через WooCommerce API проводится тестовый заказ, проверяется правильность расчета итоговых сумм, заказ проходит через все этапы смены статусов, а затем удаляются все созданные артефакты.
Детали реализации имеют значение. Если вы не позаботитесь о тщательной очистке данных, ваши отчеты заполнятся фейковыми заказами и фиктивными товарами.
Отключите отправку писем WooCommerce во время теста. Худшее, что может случиться, — это если владелец магазина или настоящий администратор получит письмо «New Order» в 3 часа ночи из-за того, что cron-задача запустила ежедневную проверку. Отключите исходящие уведомления на время работы скрипта или используйте фильтр, чтобы блокировать любые письма, связанные с ID тестовых заказов.
Используйте функцию завершения (shutdown function) для очистки данных в случае сбоя скрипта. PHP позволяет зарегистрировать функцию завершения, которая сработает даже в случае фатальной ошибки, прерывающей процесс. Если ваш дымовой тест упадет во время расчета налога или смены статуса заказа, процедура очистки все равно должна выполниться. В противном случае у вас останутся «осиротевшие» заказы и товары.
Записывайте ID сразу после создания, чтобы избежать появления лишних данных. Как только создан виртуальный товар, сразу сохраните его ID. Как только создан тестовый заказ, сразу сохраните его ID. Сразу записывайте их в переменные. Не ждите окончания работы скрипта, чтобы спросить у базы данных, что вы только что создали. Если скрипт прервется на полпути, эти ID уже должны быть у вас под рукой, чтобы обработчик завершения точно знал, что именно нужно удалить.
Этот тест работает в обход пользовательского интерфейса и взаимодействует напрямую с уровнем приложения. Это важно. Фронтенд может быть кэширован, минифицирован или изменен десятком расширений браузера. API же отражает истинное положение дел: может ли WooCommerce по-прежнему создавать, рассчитывать и менять статусы заказов?
Два уровня защиты
Вам необходим как внешний, так и внутренний мониторинг, и вы должны понимать, о чем на самом деле сообщает каждый уровень.
Внешний мониторинг отвечает на вопрос: «Могут ли люди зайти на сайт?» Используйте его для обнаружения проблем с DNS, истечения срока действия SSL, падения серверов и разделения сети. Это ваша первая линия обороны от сбоев инфраструктуры.
Внутренний мониторинг отвечает на вопрос: «Могут ли люди что-то купить?» Он работает внутри вашего приложения. Он отслеживает процент неудачных заказов, режимы работы шлюзов, производительность базы данных во время оформления заказа и результаты вашего ежедневного дымового теста. Он ловит сбои бизнес-логики, которые никогда не заметит ни один внешний сервис проверки доступности (ping service).
Сбой — это громко. Сайт падает, срабатывает оповещение, и вы его исправляете. Клиенты могут ворчать, но они часто возвращаются. Сломанная корзина — это тихо. Ваша реклама продолжает крутиться, бюджет на привлечение клиентов сгорает, а покупатели уходят, не сказав ни слова. При этом ваш дашборд аптайма все время остается успокаивающе зеленым.
Перестаньте следить за главной страницей. Начните следить за деньгами.