Моніторинг WooCommerce: магазин працює, але чи можна в ньому купити?

Магазин працює, а продажів немає

Магазин на WooCommerce може ламатися так, що перевірка статусу цього не побачить. Оновлення теми ховає кнопку «Додати в кошик». Конфлікт плагінів не дає кошику зберігати товари. Ключі платіжного шлюзу застаріли, і на оформленні з’являється загальне повідомлення про помилку. Webhook перестають надходити, а оплачені замовлення висять у статусі «Очікує оплати». Усі ці збої не заважають головній відповідати нормальним кодом 200, і втрата виручки лишається непомітною, доки хтось не загляне у список замовлень. Моніторинг магазину здебільшого полягає у виборі сторінок, за вмістом яких видно, що весь конвеєр працює.

Які сторінки несуть сигнал

Практичний набір для магазину, кожен елемент — окремий монітор:

• Сторінка товару-індикатора: товар, який завжди опублікований і є в наявності, з обов’язковою фразою «Add to cart». Якщо колись знімете цей товар із продажу, змініть монітор.
• Кошик: порожній кошик показує повідомлення WooCommerce «Your cart is currently empty», тож вимога цієї фрази перевіряє, що шаблон кошика відображається; забороніть і загальне повідомлення про помилку.
• Оформлення замовлення: Tenium не може зберігати кошик між запитами, тож із порожнім кошиком його зазвичай перенаправляють або показують повідомлення, що все одно доводить, що сторінка й тема завантажуються. Залиште діапазон очікуваних статусів широким (200-399) і вимагайте фразу, яку бачите в такому стані.
• Store API: /wp-json/wc/store/v1/products?per_page=1 повертає JSON у нових версіях WooCommerce. Монітор JSON API зі шляхом 0.id перевіряє, що товари віддаються з бази даних через шар REST незалежно від кешу.
• Сторінка пошуку чи категорії: вона навантажує базу даних більше, ніж головна, яку можна закешувати.

Платіжні callback

Шлюзи повідомляють магазин через адресу callback, часто вигляду /?wc-api=NAME, а точну адресу покаже сторінка налаштувань плагіна. Tenium може надсилати лише GET, а шлюзи надсилають POST із підписаним вмістом, тож відповіддю зазвичай буде якийсь статус помилки. Це нормально: задайте очікуваний статус 200-499, і перевірку пройде будь-яка відповідь, що доводить, що PHP працює, а відповіді 500, 502, 503 і таймаут її провалять. Те, чи може шлюз до вас достукатися і чи сходяться підписи, монітор не покаже, тому поглядайте й на журнал доставки у власній панелі шлюзу.

Повільне оформлення коштує грошей

Оформлення, яке триває вісім секунд, губить кошики, ніколи не впавши. На тарифах Pro і Agency можна задати поріг повільної відповіді в мілісекундах: Tenium порівнює з ним середнє за три останні перевірки й відкриває інцидент про погіршення, коли поріг перевищено. Оберіть значення за власними даними: дайте монітору попрацювати тиждень, подивіться на графік часу відповіді й поставте ліміт приблизно вдвічі вище за звичайне значення. Пам’ятайте, що перевірки звертаються до некешованих сторінок кошика й оформлення з кількох регіонів, тож у цифру входить і відстань мережею.

Розпродажі за розкладом, склад і Action Scheduler

WooCommerce покладається на Action Scheduler для листів, підписок, резервування залишків і запланованих цін розпродажу. Він працює поверх wp-cron, тож порада з розділу про моніторинг WordPress тут діє вдвічі сильніше: запускайте його із системного планувальника й підключіть heartbeat. Якщо встановлено WP-CLI і команди Action Scheduler, завдання на кшталт wp action-scheduler run з наступним curl на heartbeat підкаже, що черга застрягла, зазвичай раніше, ніж покупці почнуть скаржитися на відсутні листи-підтвердження.

Скільки потрібно моніторів, сповіщення й пікові дні

Закладайте від шести до десяти моніторів на магазин: товар-індикатор, кошик, оформлення, Store API, wp-login, callback, SSL / домен і heartbeat. 100 моніторів тарифу Starter вистачить приблизно на 12 магазинів по вісім, 300 моніторів Pro — приблизно на 37 магазинів. Спрямовуйте сповіщення туди, де їх помітить людина: Telegram і Slack доступні з тарифу Starter, а Pro додає ескалацію, якщо перше повідомлення ніхто не підтвердив. Перед великою акцією скоротіть інтервал ключових моніторів (1 хв на Starter, 30 с на Pro) і плануйте вікна обслуговування для деплоїв, щоб вони не з’їдали аптайм, який власник магазину бачить на сторінці статусу.