Большинство команд мониторят не то, что действительно ломается.
Когда говорят о мониторинге, обычно имеют в виду 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 и других критичных интеграциях раньше, чем о них узнают пользователи.
Если тема мониторинга зависимостей вам близка, буду рад обратной связи:
