Основы мониторинга для основателей: метрики и оповещения для старта

Что такое мониторинг (и почему основатели чувствуют себя слепыми без него)

Мониторинг — это способ узнать, что ваше приложение болеет, прежде чем об этом скажут пользователи. Это сигналы и оповещения, которые быстро отвечают на один вопрос: работает ли продукт прямо сейчас для реальных людей?

Основатели чувствуют себя слепыми, потому что большинство сбоев не выглядят как полный аутейдж. Сайт загружается, но вход не работает. У части пользователей таймаутится оплата. Фоновая задача перестаёт отправлять письма. Без мониторинга вы узнаёте об этом по злым сообщениям, потере выручки или коллеге, который говорит: «Что‑то стало медленным».

Цель не в идеальной панели. Цель — раннее предупреждение. Хороший мониторинг тих в хорошие дни и громок в плохие.

Как минимум вы должны знать:

• Пользователи терпят ошибки (и сколько их)
• Где это ломается (какая страница, endpoint или задача)
• Когда это началось (чёткая метка времени и тренд)
• Кто должен действовать (оповещение, доходящее до нужного человека)

Если вы вынесете из мониторинга только одно правило, пусть это будет такое: ответ на «Сломалось ли это прямо сейчас и становится ли хуже?» должен занимать менее минуты.

Начните с малого, а затем улучшайте каждую неделю. Добавляйте по одной метрике, одному оповещению или одной детали в лог за раз. Если вы унаследовали кодовую базу, сгенерированную ИИ, это становится ещё важнее. Приложение может «работать» в демо, скрывая проблемы вроде сломанной аутентификации, открытых секретов или фоновых задач, которые тихо падают.

Стартовый набор: четыре сигнала, которые ловят большинство сбоев

Большинство ранних инцидентов в продакшене проявляются как одна из четырёх проблем: пользователи получают ошибки, страницы замедляются, приложение недоступно или фоновая работа перестаёт выполняться.

Стартовый набор, покрывающий эти режимы отказа:

• Ошибки (частота и типы ошибок)
• Задержка (сколько времени занимают ключевые запросы)
• Доступность (доступно ли приложение извне вашей сети)
• Глубина очереди (накопились ли фоновые задачи)

Эти четыре сигнала покрывают как «парадную дверь», так и «закулису». Ошибки и задержка показывают то, что пользователи чувствуют прямо сейчас. Доступность ловит полные аутейджи и очевидные сбои при деплое или в сети. Глубина очереди ловит тихие отказы, которые не проявляются в UI часами.

Сопоставление с пользовательской болью:

• Ошибки: «Я не могу войти» или «Оплата не прошла».
• Задержка: «Он загружается вечно», хоть технически всё работает.
• Доступность: «Сайт упал».
• Глубина очереди: «Мой отчёт так и не пришёл» или «Письма перестали отправляться».

Логи и трассировки отличны для диагностики, но их сложнее использовать для оповещений на старте. Метрики плюс простые оповещения обычно быстрее приведут вас к пониманию «что сломалось».

Ошибки: самый быстрый способ понять, что пользователи заблокированы

Если вы отслеживаете только одну вещь сначала — отслеживайте ошибки. Это самый явный сигнал, что реальные люди не могут завершить задачу.

Начните с двух чисел:

• Частота ошибок: процент запросов, которые упали
• Количество ошибок: сколько случилось неудач

Процент показывает влияние. Количество — объём. Небольшой процент всё равно может сильно бить по бизнесу при большом трафике.

Разделите ошибки на клиентские и серверные уже на старте:

• 4xx (ошибки клиента) часто означают неверный ввод, просроченные сессии или устаревшие маршруты.
• 5xx (ошибки сервера) обычно означают, что система упала: упавшее API, сломанный запрос, плохой деплой или конфиг.

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

Оповещения должны фокусироваться на паттернах, а не на единичных событиях. Одиночный 500 может быть шумом. Всплеск или устойчиво высокий процент — это пожар.

Практичный стартовый набор:

• Внезапный всплеск: частота ошибок поднимается над базовой линией на 5–10 минут
• Устойчивая проблема: частота ошибок держится выше порога 15–30 минут
• Фокус на 5xx: оповещение по серверным ошибкам даже если общее число ошибок невелико

Добавьте одно оповещение для «денежного пути» — флоу, который важен больше всего: вход, регистрация или оформление заказа. Если после релиза 500‑е на входе поднялись с 0.1% до 5%, вы хотите узнать об этом до писем от клиентов.

Задержка: ловите тормоза до того, как накопятся тикеты в поддержку

Задержка — это время, которое пользователь ждёт после клика, тапа или обновления. Даже когда приложение «включено», высокая задержка ощущается как поломка. Люди уходят со страницы, повторяют действие или думают, что их аккаунт заблокирован.

Двух чисел достаточно, чтобы понять картину:

• p50: типичный опыт
• p95: «наихудший обычный» опыт

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

Не мониторьте все маршруты в первый день. Разбейте задержку по действиям, которые важны бизнесу. Медленная страница настроек — неприятно. Медленный вход останавливает рост.

Распространённые стартовые точки:

• Вход и регистрация
• Оформление заказа или подтверждение оплаты
• Поиск и страницы результатов
• Любое действие «создать» (новый заказ, тикет, пост)

Оповещения работают лучше, когда они фиксируют изменение, а не единичную плохую минуту. Простое правило: оповещать, когда p95 вырастает значительно относительно нормы или держится достаточно долго, чтобы пользователи это почувствовали.

Полезный стартовый набор:

• p95 вырос в 2 раза относительно базовой линии в течение 10 минут
• p95 превысил жёсткий лимит (например, 2–3 секунды) в течение 5–10 минут
• p50 постепенно растёт в течение 15 минут (часто проблемы с мощностью или базой данных)
• p95 вырос только на одном endpoint (часто проблема в кодовом пути или внешнем API)

Пример: главная страница всё ещё быстро грузится, но p95 для endpoint’a входа поднимается с 400 мс до 4 с после деплоя. В быстрой проверке вы этого можете не заметить, но новые пользователи это почувствуют.

Доступность: проверьте, доступно ли приложение снаружи

Доступность отвечает на вопрос: может ли реальный пользователь сейчас добраться до вашего приложения? Она ловит полные аутейджи, плохой DNS, истёкший SSL или деплой, после которого сервис не вернулся.

Доступность не значит, что продукт работает. Вы можете отдавать 200 OK, пока вход сломан, оплата падает или страница пуста из‑за упавшего скрипта. Рассматривайте доступность как дымовую сигнализацию, а не как инструмент для расследования.

Используйте внешнюю проверку, которая запускается вне вашей инфраструктуры, так же, как это делает клиент. Она может обращаться к домашней странице, лёгкому health endpoint’у или простому route‑у, подтверждающему быстрый ответ сервера.

Чтобы избежать шума, алертьте по последовательным ошибкам, а не по одиночным всплескам.

Стартовая настройка:

• Проверка каждые 1–5 минут из как минимум двух локаций
• Триггер оповещения после 2–3 последовательных неудач
• Сначала уведомить человека (push или SMS), затем эскалировать при отсутствии подтверждения
• В оповещении указывать URL, код статуса и время ответа

Планируйте и запланированные простои: приостановите оповещения или пометьте окно, чтобы не паниковать из‑за ожидаемых сбоев.

Пример: вы делаете хотфикс в пятницу, и конфигурация reverse proxy неверная. Приложение «запущено», но ничего не доступно из публичного интернета. Внешняя проверка поймает это за несколько минут.

Глубина очереди: заметьте фоновые задачи, которые тихо застревают

Некоторые из самых болезненных ошибок не проявляются как явная ошибка. Они показываются накоплением работы в фоне: письма для сброса пароля, импорт файлов, webhook’и по платежам, задачи обработки, ночные отчёты. UI может выглядеть нормально, пока пользователи ждут часы.

Глубина очереди — это сколько работы ждёт обработки. Также отслеживайте возраст задания (как долго самая старая задача в очереди). Глубина показывает объём. Возраст показывает влияние на пользователя.

Что отслеживать

Держите набор маленьким и видимым:

• Размер очереди (ожидающие задачи)
• Возраст самой старой задачи (время с момента постановки в очередь)
• Скорость обработки (задач в минуту), если доступно

Оповещения, которые ловят проблему рано

Начните с порогов, которые потом можно уточнить:

• Размер очереди держится выше 100 в течение 10 минут
• Возраст самой старой задачи превышает 5 минут (предупреждение) или 15 минут (срочно)
• Размер очереди растёт 15 минут при нормальном трафике

Если у вас несколько очередей (письма vs импорты), оповещайте по каждой очереди отдельно. Одна застрявшая очередь не должна скрываться за другой, здоровой.

Когда глубина или возраст растут, обычно причина в одном из: воркер упал, цикл повторов постоянно добавляет одну и ту же падающую задачу, или зависимость медленная (провайдер почты, БД, внешний API).

Пример: «письма перестали отправляться». Доступность в порядке. Но возраст очереди вырос до 40 минут, потому что воркер упал после деплоя. Оповещение по возрасту поймало бы это раньше, чем клиенты начали писать в поддержку.

Как настроить первые оповещения за 60 минут (пошагово)

В первый день не нужна сложная система. Самый быстрый результат — маленький набор оповещений, привязанных к тому, что реально делают клиенты.

Шаг 1: выпишите действия, которые приносят вам деньги

Выберите 3–5 ключевых пользовательских действий. Если любое из них ломается, пользователи быстро застрянут.

• Регистрация
• Вход
• Начало оформления заказа или оплата
• Создание основного объекта в приложении (проект, заказ, пост)
• Экспорт, приглашение или шаринг

Шаг 2: добавьте по одной метрике и одному оповещению на действие

Держите минимализм: одна метрика, показывающая, что действие ломается, и одно оповещение, которое вы действительно увидите.

• Для регистрации и входа: оповещение по частоте ошибок (или по неудачным запросам) на коротком окне
• Для платежей: оповещения по всплескам 4xx и 5xx и по задержке (медленные платежи часто тихо падают)
• Для создания/экспорта: оповещения по ошибкам фоновых задач или по здоровью очереди, если это асинхронно

Шаг 3: ставьте пороги по норме

Используйте последние несколько дней нормального поведения. Если ошибки входа обычно около нуля, порог вроде «больше 5 неудач за 5 минут» часто ловит реальные проблемы без шума. Для задержки начните с «в 2 раза медленнее обычного», вместо поиска идеального числа.

Шаг 4: отправляйте оповещения туда, где вы их точно увидите

Оповещение, которое лежит в дашборде — не оповещение. Рутируйте его в командный чат, на телефон или туда, где вы проверяете уведомления в течение дня.

Шаг 5: просматривайте каждую неделю и настраивайте

Еженедельно смотрите, что сработало.

• Если оповещение шумит — повышайте порог или добавляйте условие по длительности (оповещать только если длится, например, 10 минут).
• Если вы пропустили инцидент — понижайте порог или добавьте флоу‑специфичное оповещение.

Частые ошибки, которые делают мониторинг бесполезным

Самый быстрый способ испортить мониторинг — относиться к нему как к галочке. Мониторинг меньше про красивые панели и больше про несколько чётких сигналов, которые приводят к действию.

Усталость от оповещений

Если телефон вибрирует при каждом мелком всплеске, вы начнёте игнорировать всё. Ставьте пороги так, чтобы оповещение значило «кто‑то, вероятно, заблокирован» или «это скоро станет видимо пользователю», а не «график немного сдвинулся».

Только аптайм

Приложение может быть «включено», пока самый важный флоу сломан (вход, оплата, сброс пароля). Если у вас есть только ping, вы будете думать, что всё в порядке, пока пользователи смотрят на вращающуюся кнопку.

Оповещения без следующего шага

Оповещения должны указывать следующий шаг, а не только страшную цифру.

• Назначьте владельца для каждого оповещения (даже если это «on‑call на этой неделе»).
• Давайте контекст: endpoint, временное окно, насколько плохо.
• Добавляйте контекст деплоя: «новый релиз 12 минут назад» меняет реакцию.
• Храните одно‑строчное руководство: «Если 500s растут — откатнуть и проверить логи аутентификации».

Следить за размером очереди, но игнорировать возраст

Маленькая очередь всё ещё может быть сломанной, если самая старая задача ждёт 20 минут. Размер показывает объём. Возраст показывает, двигается ли работа.

Пример: воркер потерял доступ к базе после смены учётных данных. Длина очереди остаётся почти неизменной, потому что задачи быстро падают и повторяются, но возраст очереди растёт, и пользователи видят «отчёт будет отправлен позже» вечность. Если оповещать по возрасту и по retry’ам, вы поймаете это рано.

Быстрый чек‑лист: вы готовы к следующему инциденту?

Если вы ничего не сделаете на этой неделе, убедитесь, что вы можете быстро ответить на вопрос: «Заблокированы ли пользователи прямо сейчас?»

Выберите цели, которые подходят вашему приложению сегодня, затем ужесточайте их позже.

• Ошибки: оповещение по устойчивым 5xx и чёткий «это плохо» порог на основном флоу (например, >1% в течение 5 минут).
• Задержка: p95 для 2–3 ключевых endpoint’ов (вход, оплата, поиск или ваш основной API) с терпимым для пользователей порогом (например, p95 >1.5 с в течение 10 минут).
• Доступность: внешняя проверка, которая оповещает только после последовательных неудач (например, 3 падения подряд).
• Здоровье очереди: видимость того, успевают ли задачи обрабатываться. Оповещение по возрасту самой старой задачи и по длительному росту глубины очереди.
• Люди/процессы: один человек отвечает, когда срабатывает оповещение, с простым путём эскалации.

Быстрый тест реальности: попросите знакомого зайти в приложение с телефона и проделать основное действие. Если оно падает, скажите, покажет ли мониторинг это за 5 минут? Поймёте ли вы, виноваты ли ошибки, медлительность, недоступность или застрявшие задачи?

Пример: поймать сломанный вход до жалоб клиентов

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

Через несколько минут два сигнала заметно двигаются:

• Всплеск ошибок на auth endpoint’е.
• Одновременный рост задержки, потому что бэкенд повторяет вызов к БД (или внешней проверке) перед падением.

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

Чистая реакция выглядит так:

• Откатить последний деплой
• Убедиться, что ошибки вернулись к норме
• Перевыпустить исправление позже

После этого вы добавляете два таргетных оповещения для флоу входа:

• Оповещение при пересечении небольшого порога ошибок на endpoint’e входа в течение 5 минут.
• Отдельное оповещение при резком росте задержки относительно базовой линии.

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

Следующие шаги: держите набор маленьким и затем чиним корень проблемы

Начните с малого набора сигналов, затем пусть реальные инциденты подскажут, что добавить. Цель не в «идеальном покрытии», а в том, чтобы замечать поломки рано и иметь понятный следующий шаг.

Начните с четырёх сигналов (ошибки, задержка, доступность, глубина очереди). Держите их пару недель. Когда что‑то ломается, не добавляйте сразу пять новых оповещений. Запишите, что произошло и что могло сделать это очевиднее раньше.

Короткая заметка по инциденту достаточно:

• Что видели пользователи и когда это началось
• Что изменилось перед поломкой (деплой, конфиг, сбой третьей стороны)
• Исправление, которое вы применили (или откат)
• Один шаг предотвращения (тест, защитный механизм, настройка оповещения, недостающий лог)

Добавляйте новое оповещение только если вы можете ответить: «Если это сработает, кто и что делает в следующие 10 минут?» Если действие — «разобраться потом», это место на дашборде, а не в пейджере.

Когда оповещения постоянно указывают на одни и те же проблемы (вход ломается после мелких изменений, секреты просачиваются в логи, фоновые задачи каждую ночь накапливаются), это чаще проблема кодовой базы, а не мониторинга. Если вы унаследовали приложение, сгенерированное инструментами вроде Lovable, Bolt, v0, Cursor или Replit и оно ведёт себя в продакшене иначе, чем в демо, фокусированный аудит экономит много попыток угадывания. FixMyMess (fixmymess.ai) делает диагностику и ремонт кодовой базы именно для таких случаев, включая укрепление безопасности и подготовку к деплою.