Ваша панель моніторингу доступності вам бреше. Вона каже, що ваш сайт онлайн. Головна сторінка завантажується. SSL-сертифікат дійсний. Кожен піксель відображається саме там, де й має. Тим часом ваш магазин не обробив жодного реального замовлення протягом шести годин, і першою людиною, яка про це вам повідомить, буде клієнт, що запитає, чому щоденний звіт про продажі перестав зростати.

Це фундаментальний недолік у ставленні до e-commerce платформи як до сайту-брошури. Стандартний моніторинг доступності ставить лише одне запитання: чи повернув сервер статус 200 OK? Для магазину на WooCommerce це запитання зовсім не стосується суті. Сервер може працювати безперебійно, сторінка оформлення замовлення може виглядати бездоганно, але гроші все одно можуть перестати надходити. Це «тиха помилка», і вона коштує набагато дорожче, ніж гучний збій сервера.

Коли статус «Онлайн» нічого не означає

Відповідь 200 лише доводить, що PHP завершив виконання та надіслав HTML у браузер. Вона не доводить, що завантажився JavaScript від Stripe. Вона не доводить, що кнопка оформлення замовлення надсилає запит на робочий ендпоінт. Вона не доводить, що спрацював вебхук, скоригувалися залишки на складі або надійшов лист із підтвердженням. Відвідувач бачить повністю завантажену сторінку оформлення замовлення, вводить номер картки, натискає «купити», і нічого не відбувається. Або, що ще гірше, замовлення реєструється як невдале, хоча платіж насправді пройшов.

Якщо ваша стратегія моніторингу починається і закінчується пінгінням головної сторінки, ви спостерігаєте не за тим процесом. Ви помітите збій теми, який «покладе» хедер. Ви не помітите платіжний шлюз, що застряг у тестовому режимі. Ви дізнаєтеся про це лише тоді, коли хтось перевірить графік доходів або відповість на гнівний телефонний дзвінок.

П'ять способів, якими магазин «помирає», не виходячи з мережі

Ось конкретні збої, через які магазин на WooCommerce зберігає 100% доступності, тоді як конверсія падає до нуля:

  • Платіжні шлюзи застрягають у тестовому режимі. Розробник перемикає Stripe або PayPal у режим sandbox, щоб відтворити баг, вирішує проблему і забуває повернути налаштування назад. Реальні клієнти вводять реальні номери карток і впираються в стіну тестового режиму. Іноді помилка очевидна, іноді — ні, і транзакція просто зависає.
  • Оновлення плагіна ламає шаблон оформлення замовлення. WooCommerce випускає оновлення або page builder вносить зміни, і форма оформлення замовлення більше не відображається коректно. Сторінка завантажується, але поля для платіжних даних зникають або кнопка оформлення замовлення видає помилку JavaScript при натисканні. Сервер у нормі. Користувацький досвід зруйновано.
  • Різке зростання кількості невдалих замовлень через помилки шлюзів. Термін дії API-ключів закінчується. Виникають невідповідності валют. Змінюються вимоги 3D Secure. Ці помилки відображаються як невдалі замовлення в адмінпанелі WooCommerce, а не як помилки сервера у ваших логах доступності. Дивитеся не на той екран — і ви пропустите повільну «витік» прибутку.
  • Зависає серверний ланцюжок обробки замовлень. Інтеграція зі сторонньою ERP-системою, кастомна функція синхронізації запасів або калькулятор вартості доставки видають тайм-аут після того, як клієнт натискає «купити». Замовлення залишається в статусі pending нескінченно довго. Клієнт оновлює сторінку, плутається і йде. Ваші метрики хостингу все ще показують зелене світло.
  • Потік замовлень просто зупиняється без очевидної причини. Немає фатальної помилки. Немає конфлікту плагінів. Кеш просто починає видавати застарілий JavaScript для оформлення замовлення. Банер керування згодою блокує iframe платіжної системи. Edge-вузол CDN видає стару версію скрипта. Сайт онлайн. Оформлення замовлення — ні.

Моніторинг того, що справді важливо

Щоб виявити ці збої, ви повинні припинити стежити за інфраструктурою і почати стежити за бізнес-логікою. Ось як побудувати стратегію моніторингу, яка враховує складність реального потоку транзакцій.

Моніторте потік замовлень, а не лише доступність. Відстежуйте, чи можна додати товар у кошик, чи відповідає ендпоінт оформлення замовлення валідним JSON, і чи завантажується сторінка подяки після успішної оплати. Якщо ви покладаєтеся на зовнішні інструменти пінгіння, налаштуйте їх так, щоб вони перевіряли критичний шлях, а не лише корінь домену.

Порівнюйте кількість невдалих замовлень із семиденним базовим показником. Не використовуйте абсолютні числа. П'ять невдалих замовлень за годину можуть бути нормою для ранку понеділка після акції. П'ять невдалих замовлень за годину спокійного вечора середи — це тривожний сигнал. Дивіться на відхилення від вашого власного скользячого базового показника, а не на довільні пороги.

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

Запускайте щоденний серверний smoke-тест. Це найефективніша мережа безпеки, яка дозволяє виявити непрацюючу оплату ще до того, як це помітить людина.

Створення щоденного smoke-тесту

Належний smoke-тест створює реалістичне замовлення, не залишаючи хаосу в базі даних. Процес виглядає так: згенерувати прихований віртуальний товар, провести тестове замовлення через WooCommerce API, перевірити правильність розрахунку підсумкових сум, провести замовлення через усі статуси, а потім видалити всі артефакти.

Деталі реалізації мають значення. Якщо ви не дбайливо підійдете до очищення даних, ваші звіти заповняться фейковими замовленнями та фіктивними товарами.

Пригнічуйте розсилку email-повідомлень WooCommerce під час тесту. Найгірше, що може статися, — це якщо власник магазину або реальний адміністратор отримає лист «Нове замовлення» о 3:00 ранку через те, що cron-завдання запустило щоденну перевірку. Вимкніть вихідні сповіщення на час роботи скрипта або використовуйте фільтр, щоб блокувати будь-які листи, пов'язані з ID тестових замовлень.

Використовуйте функцію shutdown для очищення даних у разі збою скрипта. PHP дозволяє зареєструвати функцію shutdown, яка спрацьовує навіть тоді, коли процес зупиняється через фатальну помилку. Якщо ваш smoke-тест перерветься під час розрахунку податків або зміни статусів замовлення, процедура очищення все одно має виконатися. Інакше у вас залишаться «сирітські» замовлення та товари.

Записуйте ID одразу після створення, щоб уникнути появи зайвих даних. Щойно віртуальний товар створено — зафіксуйте його ID. Щойно створено тестове замовлення — зафіксуйте його ID. Одразу зберігайте їх у змінних. Не чекайте завершення скрипта, щоб запитати базу даних про те, що ви щойно створили. Якщо скрипт перерветься в процесі роботи, ці ID вже мають бути у вас під рукою, щоб обробник shutdown точно знав, що саме видаляти.

Цей тест оминає користувацький інтерфейс і взаємодіє безпосередньо з рівнем додатка. Це важливо. Фронтенд може бути кешованим, мініфікованим або зміненим десятками розширень браузера. API відображає справжній стан справ: чи може WooCommerce все ще створювати, розраховувати та змінювати статуси замовлення?

Два рівні захисту

Вам потрібен як зовнішній, так і внутрішній моніторинг, і ви повинні розуміти, що саме повідомляє кожен із цих рівнів.

Зовнішній моніторинг відповідає на питання: «Чи можуть люди зайти на сайт?» Використовуйте його для виявлення проблем із DNS, закінчення терміну дії SSL, падіння серверів та розривів мережі. Це ваш перший рядок оборони від збоїв інфраструктури.

Внутрішній моніторинг відповідає на питання: «Чи можуть люди щось купити?» Він працює всередині вашого додатка. Він відстежує частоту помилок при оформленні замовлень, режими роботи шлюзів, продуктивність бази даних під час оплати та результати вашого щоденного smoke-тесту. Він виявляє збої в бізнес-логіці, які жоден зовнішній сервіс перевірки доступності (ping service) ніколи не побачить.

Збій інфраструктури — це гучно. Сайт падає, спрацьовує сповіщення, і ви його виправляєте. Клієнти можуть поскаржитися, але вони часто повертаються. Поломка процесу оплати — це тихо. Ваша реклама продовжує працювати, бюджет на залучення клієнтів продовжує згорати, а покупці йдуть, не сказавши ні слова. При цьому ваш дашборд доступності (uptime dashboard) весь час залишається заспокійливо зеленим.

Досить стежити за головною сторінкою. Почніть стежити за грошима.