Проверяйте путь пользователя
Начните со списка действий, из-за которых сайт существует: поиск товара, вход, оформление заказа, отправка формы, получение письма. Для каждого пути определите простой проверяемый признак успеха. Страница с кодом 200 может содержать сообщение об ошибке внутри HTML.
Проверки не должны создавать реальные заказы или рассылать письма клиентам. Используйте отдельные тестовые учётные записи и очищаемые тестовые данные, ограничьте права и документируйте сценарий.
Наблюдайте за компонентами
Следите за загрузкой процессора, доступной памятью, диском, временем ответа приложения, очередью PHP-процессов, соединениями и задержкой запросов к базе. Один показатель без контекста мало полезен: высокий CPU при нормальном времени ответа и тот же CPU при росте очереди требуют разной реакции.
Отдельно контролируйте сертификат, домен, резервные копии, срок последней успешной фоновой задачи и доставку системных писем. Эти проблемы часто остаются незаметными, пока пользователь не попробует конкретное действие.
Настройте сигнал без шума
Для каждого критичного события задайте порог, время подтверждения, получателя и способ передачи. Однократный сбой внешней проверки может быть сетевым шумом; серия неудач из нескольких точек повышает уверенность. Нельзя ждать часами, если перестали приниматься заявки.
Разделите уведомления на требующие немедленного действия и плановые. Если система ежедневно отправляет десятки бесполезных сообщений, важный сигнал перестанут замечать. Регулярно пересматривайте правила по реальным инцидентам.
Проверьте сам мониторинг
Периодически проводите безопасный тест: искусственно создайте событие в тестовой среде и проследите весь путь до ответственного. Проверьте, что человек увидел уведомление, понял его смысл и имеет доступ к нужным журналам.
Рабочий результат мониторинга — не красивая панель графиков, а короткое время между появлением проблемы и началом понятных действий.
Хотите применить эти рекомендации на своём проекте? Опишите задачу в форме ниже, и мы обсудим дальнейшие шаги.
