Сайт может открываться с кодом 200, сервер может быть зелёным, а бизнес-процесс при этом уже не работать
Например, каталог показывает товары, но 1С больше не отвечает. Checkout доступен, но нельзя создать оплату. CRM открывается в браузере, но интеграционный ключ перестал работать. Служба доставки вернула ошибку, а пользователь узнаёт об этом первым
Поэтому в РЕТОН мониторинг постепенно вырос из проверки «жив ли сайт» в проверку связанных бизнес-контуров
Технический uptime — только первый слой
Базовые проверки никуда не исчезают:
- Nginx
- процесс магазина
- публичные домены
- локальный health endpoint
- память приложения
Но они отвечают только на вопрос «сервер вообще работает?»
Бизнесу нужен другой вопрос: можно ли сейчас пройти нужный сценарий?
Проверять нужно границы между системами
В текущем мониторинге отдельно контролируется доступность и готовность ключевых зависимостей
Среди них:
- Bitrix24 REST
- передача заказов в CRM
- 1С Fresh
- каталог из 1С
- ЮKassa
- операторский контур
- ИИ-консультант
- службы доставки
- почтовая резервная инфраструктура
На момент последнего аудита система собирала несколько десятков отдельных проверок. Это уже не один health-check, а карта взаимозависимостей
API ответил и контур готов — разные вещи
Даже успешный HTTP-ответ не всегда означает, что интеграция готова к работе
Например, можно отдельно проверять:
- доступен ли внешний API
- корректно ли настроена интеграция
- включена ли реальная запись
- хватает ли обязательных параметров
- проходит ли безопасная диагностическая операция
Так мониторинг не смешивает сетевую доступность и бизнес-готовность
Не каждая ошибка должна будить человека
Внешний сервис может моргнуть один раз и сразу восстановиться
Если отправлять уведомление на каждый единичный сбой, сотрудники быстро перестанут читать алерты
Поэтому полезно различать:
- кратковременную ошибку
- подтверждённый инцидент
- продолжение уже известного инцидента
- восстановление
Тогда сообщение «Почта России один раз не ответила» не равно сообщению «оплата недоступна уже несколько проверок подряд»
Отчёт важен не меньше алерта
Помимо оперативных уведомлений есть смысл собирать сводки за день и месяц
Они отвечают на другие вопросы:
- что чаще всего было нестабильно
- сколько длились инциденты
- какие контуры восстанавливались
- где появилась новая зависимость
Так мониторинг становится не только сиреной, но и материалом для технических решений
Почему мне нравится этот контур
Он хорошо показывает разницу между «поднять сайт» и «поддерживать цифровую систему»
Когда магазин связан с CRM, 1С, кассой, чатом и доставкой, работоспособность больше нельзя описать одной лампочкой server online
Нужно видеть всю цепочку. И желательно узнать о разрыве раньше, чем о нём напишет клиент
Что можно перенести в другой бизнес
Этот подход не привязан к РЕТОН
Для любой интеграционной системы полезно сначала нарисовать реальные бизнес-цепочки, а потом поставить проверки на их критические узлы и переходы
Тогда мониторинг отвечает не на вопрос «жив ли наш VPS», а на вопрос «может ли компания сейчас нормально выполнить то, ради чего этот VPS вообще существует»