Почему ваш сервер работает, а продукт — нет

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

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

• CPU

• память

• диск

• базу данных

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

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

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

Но за последние годы в Olisen Studio мы заметили интересную закономерность: самые неприятные инциденты редко связаны с падением серверов.

Гораздо чаще ломается что-то другое. И именно такие проблемы обычно остаются незамеченными дольше всего.

Когда приложение работает, а пользователи уже сталкиваются с проблемами

Современный SaaS-продукт редко существует изолированно.

Даже относительно простое приложение может зависеть от десятков внешних сервисов:

• Stripe

• OpenAI

• Telegram

• GitHub

• Notion

• Slack

• внутренних API

Отказ любой из этих зависимостей способен затронуть критически важную функцию продукта.

Например:

• истёк API-ключ OpenAI;

• webhook Stripe перестал доставлять события;

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

• GitHub API начал возвращать ошибки;

• перестала выполняться фоновая задача;

• интеграция перестала получать события.

При этом с точки зрения инфраструктуры всё выглядит нормально.

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

Но часть функциональности уже недоступна.

Почему такие проблемы обнаруживаются слишком поздно

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

Работает ли система?

Но для пользователя важнее другой вопрос:

Работает ли функция, ради которой он пришёл?

Представим сервис, который автоматически публикует контент через сторонний API.

Если этот API перестанет принимать запросы:

• приложение продолжит работать;

• пользователи смогут входить в систему;

• сервер не покажет критических ошибок.

Однако основная ценность продукта исчезнет.

Иногда подобные сбои обнаруживаются через несколько часов. Иногда через несколько дней. А иногда только после обращения клиента в поддержку.

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

Зависимости стали новой точкой отказа

Ещё несколько лет назад большинство отказов происходило внутри собственной инфраструктуры компании.

Сегодня ситуация изменилась.

Даже небольшой SaaS может зависеть от десятков внешних компонентов, и каждый из них становится потенциальной точкой отказа.

При этом многие из этих сервисов находятся вне зоны контроля команды разработки.

Нельзя исправить ошибку в OpenAI. Нельзя повлиять на инфраструктуру Stripe. Нельзя заставить GitHub API работать быстрее.

Но можно значительно быстрее узнать о проблеме.

А скорость обнаружения напрямую влияет на масштаб последствий.

Что действительно стоит мониторить

На практике имеет смысл следить не только за инфраструктурой, но и за критическими бизнес-процессами.

Внешние API

Важно контролировать не только доступность сервиса, но и корректность его работы.

API может отвечать кодом 200, но возвращать ошибочные данные или неполный результат.

Webhook-интеграции

Многие процессы строятся вокруг входящих событий.

Если события перестанут поступать, продукт может выглядеть полностью работоспособным ещё долгое время.

Авторизация и доступы

Истёкшие токены, потерянные разрешения и некорректные учётные данные остаются одной из самых частых причин скрытых отказов.

Фоновые задачи

Очереди, планировщики и cron-задачи часто выходят из строя незаметно для инфраструктурного мониторинга.

Бизнес-функции

Полезно проверять реальные пользовательские сценарии:

• проходит ли оплата;

• создаётся ли контент;

• доставляются ли уведомления;

• синхронизируются ли данные;

• работают ли ключевые интеграции.

Новый взгляд на мониторинг

Инфраструктурный мониторинг по-прежнему остаётся необходимым.

Но сегодня его уже недостаточно.

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

«Работает ли сервер?»

постепенно уступает место другому:

«Работает ли продукт целиком?»

Именно на уровне зависимостей, интеграций и пользовательских сценариев сегодня возникает значительная часть инцидентов.

И именно там многие команды всё ещё остаются слепыми.

В Olisen Studio мы столкнулись с этой проблемой во время работы над SaaS-проектами и внутренними инструментами. Поэтому сейчас исследуем подходы к мониторингу внешних зависимостей, API, webhook-интеграций и фоновых процессов.

Если вам близка эта тема или вы сталкивались с похожими инцидентами, будем рады обсудить ваш опыт.

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