Большинство команд мониторят не то, что действительно ломается.

Когда говорят о мониторинге, обычно имеют в виду CPU, память, диск, базу данных и доступность приложения. Если сервер падает, об этом узнают быстро: срабатывают алерты, краснеют дашборды, начинается расследование.

Но самые неприятные инциденты часто выглядят совсем иначе.

Представьте типичную SaaS-систему. Она использует Stripe для платежей, OpenAI для генерации контента, Telegram для уведомлений, GitHub API для интеграций и несколько внутренних сервисов.

В какой-то момент что-то ломается: истекает API-ключ, перестаёт работать webhook, внешний сервис начинает возвращать ошибки, OAuth-токен теряет доступ или зависает фоновая задача.

И не происходит ничего.

С точки зрения инфраструктуры всё выглядит нормально. Приложение открывается, CPU в порядке, база данных работает, мониторинг показывает зелёный статус. Только пользователи уже не могут выполнить важное действие.

Самый большой ущерб в таких ситуациях часто наносит не сам сбой, а время между двумя событиями: когда проблема появилась и когда кто-то понял, что она существует.

Иногда это занимает несколько минут. Иногда часы. Иногда дни.

За это время теряются платежи, не отправляются письма, перестают синхронизироваться данные, а пользователи начинают писать в поддержку. Именно поэтому многие команды узнают о проблемах не из мониторинга, а от клиентов.

Причина проста: традиционный мониторинг отвечает на вопрос «Живо ли приложение?», но почти не отвечает на вопрос «Работает ли пользовательский сценарий?».

А это разные вещи.

Приложение может быть полностью доступным и при этом бесполезным для пользователя.

Поэтому стоит мониторить не только серверы, но и всё, что влияет на критические бизнес-процессы: внешние API, webhooks, фоновые задачи, OAuth-токены, API-ключи, интеграции и ключевые пользовательские сценарии.

Например, недостаточно проверять, что сайт отвечает. Гораздо полезнее знать:

• доступен ли OpenAI API;

• работает ли Stripe webhook;

• проходит ли авторизация;

• возвращает ли интеграция корректный ответ;

• выполняются ли фоновые процессы.

Чем сильнее SaaS-продукт зависит от сторонних сервисов, тем меньше пользы приносит мониторинг одной только инфраструктуры.

Сегодня продукт состоит не только из вашего кода. Он состоит из десятка внешних зависимостей. И ломаются они гораздо чаще, чем падают серверы.

Поэтому главный вопрос уже не в том, работает ли приложение.

Главный вопрос — работает ли продукт.

P.S. После нескольких подобных инцидентов я решил собрать отдельный инструмент для мониторинга внешних API, интеграций и зависимостей.

Сейчас делаю MVP под названием Checklane. Его задача проста: сообщать о проблемах в OpenAI, Stripe, GitHub, webhooks и других критичных интеграциях раньше, чем о них узнают пользователи.

Если тема мониторинга зависимостей вам близка, буду рад обратной связи:

https://checklane.olisen.studio/ru/

https://checklane.olisen.studio/ru/