Сервер работает. Продукт — уже нет

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

Когда речь заходит о мониторинге, обычно проверяют:

• CPU

• память

• диск

• базу данных

• доступность приложения

Если падает сервер, об этом узнают быстро.

Срабатывают алерты. Дашборды становятся красными. Начинается поиск причины.

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

Приложение доступно

Возьмём типичную SaaS-платформу.

Она использует:

• Stripe для приёма платежей

• OpenAI для генерации контента

• Telegram для уведомлений

• GitHub API для интеграций

• несколько внутренних сервисов

В какой-то момент что-то ломается.

Например:

• истекает API-ключ;

• перестаёт работать webhook;

• внешний сервис начинает отдавать ошибки;

• OAuth-токен теряет необходимые права;

• останавливается фоновая задача.

И что происходит?

На первый взгляд — ничего.

Инфраструктура выглядит абсолютно здоровой.

Сайт открывается. CPU не перегружен. База данных отвечает. Все проверки зелёные.

Только пользователи уже не могут выполнить действие, ради которого пришли в продукт.

Самая дорогая часть любого сбоя

Во многих случаях основной ущерб создаёт даже не сама неисправность.

Проблема — во времени между двумя моментами:

1. Сбой произошёл.

2. Кто-то понял, что он произошёл.

Иногда на это уходят минуты.

Иногда часы.

Иногда дни.

За это время успевают накопиться последствия:

• теряются платежи;

• не отправляются письма;

• перестают синхронизироваться данные;

• пользователи начинают писать в поддержку.

Поэтому многие компании узнают о проблемах не из системы мониторинга, а от собственных клиентов.

Откуда берётся этот разрыв

Потому что традиционный мониторинг отвечает на один вопрос:

«Приложение живо?»

Но почти не отвечает на другой:

«Работает ли пользовательский сценарий?»

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

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

Что стоит контролировать помимо инфраструктуры

Минимальный набор выглядит так:

• внешние API;

• webhooks;

• фоновые процессы;

• OAuth-токены и API-ключи;

• критически важные интеграции;

• ключевые бизнес-сценарии.

То есть недостаточно просто проверять, открывается ли сайт.

Нужно понимать:

• отвечает ли OpenAI API;

• получает ли Stripe webhook события;

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

• возвращают ли интеграции корректные данные.

Вывод

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

Сегодня продукт — это не только ваш код и ваши серверы.

Это ещё и десятки сторонних зависимостей, которые могут отказать в любой момент.

И происходит это гораздо чаще, чем падение самой инфраструктуры.

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

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

P.S.

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

Сейчас делаю MVP под названием Checklane.

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

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

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