Бизнес-метрики: заказы и оплаты

Зелёный дашборд с латентностью — и ноль заказов за час: так выглядит сломанный платёжный провайдер при совершенно здоровом приложении. Технические метрики отвечают на вопрос «жив ли сервис», бизнес-метрики — «работает ли бизнес»; второе при первом не гарантировано. Разница в устройстве небольшая, в последствиях большая: на заказы смотрят продукт и аналитики, от них считают конверсию и выручку, по ним ставят самые дорогие алерты — «заказы упали до нуля» будильник громче любого CPU. Приятный бонус: те же четыре типа метрик из второго урока, тот же client_golang, только имена и лейблы теперь из языка предметной области. Осторожность нужна в двух местах. Первое — семантика: бизнес-числа любят сверять с базой, поэтому у каждой метрики должно быть ясное определение, что именно посчитано. Второе — кардинальность: искушение положить в лейбл id заказа или пользователя здесь даже сильнее, чем в HTTP-метриках, и разбирать её будем ещё раз в конце.

Счётчик заказов почти всегда вектор: платят картой и наличкой, подписками и разовыми покупками — лейбл payment_type с двумя-четырьмя значениями ничего не стоит и открывает срезы для продукта. Имя строится от домена: shop_orders_total, shop_revenue_rubles_total — префикс сервиса, сущность, единица измерения в имени. Выручка — тоже Counter: деньги суммируются и только растут, Add(amount) ложится идеально; единицу кладут прямо в имя, чтобы рубли не спутать с копейками и центами. Средний чек отдельной метрикой не заводят: это частное rate(revenue) на rate(orders) в PromQL, и производная в коде создала бы вторую правду об одном числе. Инкременты живут в сервисном слое, сразу после успешного завершения бизнес-операции: не в HTTP-хендлере, который может не знать исхода транзакции, и не до записи в базу. Порядок «сначала коммит, потом Inc» — половина всех драм этой темы, и ниже у него отдельный разбор.

Классическая ловушка: инкремент стоит до записи в базу, сетевая ошибка уводит обработчик в ретрай — счётчик прибавил два, заказ в базе один. Правильный порядок только один: успешный коммит, затем Inc; упавшая попытка счётчик не трогает. Реверс тоже правда: выручку из метрик никогда не сверяют с бухгалтерией — это инструмент тренда и алертов, источник истины живёт в базе. Второе обязательное знание: счётчики живут в памяти процесса и после рестарта обнуляются. Prometheus компенсирует сброс в rate, но «выручка с начала суток» на графике будет прыгать после каждого деплоя — абсолютные суммы считают в базе, а метрика отвечает на «как сейчас относительно обычно»: rate за окно, сравнение с прошлой неделей, дельта после релиза. Третье: очередь платежей и их длительность — не счётчики. Число платежей в обработке меняется в обе стороны, это Gauge; время проведения платежа — распределение, это Histogram с сеткой под таймауты провайдера.

Ошибка интерпретации, из-за которой спорят с бухгалтерией. Руководитель смотрит график выручки за сутки: после обеденного деплоя линия резко упала и пошла ниже — «мы потеряли деньги». Реальность: рестарт обнулил счётчик в памяти; скорость rate компенсирует, но наивный график накопленной суммы рисует обрыв, и всё, что было до обеда, из суммы за сутки исчезло. Отсюда два чтения одного графика: прирост за окно честен всегда, абсолютный накопленный уровень после рестарта — нет. Практическое следствие: суммы за период считает база, метрика отвечает за динамику относительно нормы; дельта «сегодня против прошлой среды» корректна, а «выручка с начала месяца» в Prometheus не существует. Когда такой вопрос возникает регулярно, это сигнал завести отчётную систему рядом, а не изобретать изощрённые запросы: у счётчика память заканчивается на рестарте, и это не исправить ничем.

Бизнес-метрики дают алерты, которых не бывает у технических. Первый — тишина: заказов нет. Если днём rate(shop_orders_total[5m]) стабильно не ноль, а упал до нуля, приложение может быть здоровым — сломался провайдер, кончились лимиты, отвязался платёжный вебхук; такой алерт ставят с учётом времени суток, ночью пороги другие. Второй — аномалия величины: выручка в час заметно ниже скользящей недели при живом трафике — растёт доля отмен или обесценился средний чек. Третий — застревание: shop_payments_pending растёт и не убывает десятки минут, значит, платежи висят, и скоро это увидит поддержка через жалобы. Правило баланса: алерты на бизнес-события дороже технических и ложно срабатывают чаще — ставьте их на события с реальными деньгами и не заводите на каждое колебание, иначе дежурный научится их игнорировать, а это хуже, чем их отсутствие.

Инцидент из разряда «сам себя наказал». На витрине заказов поставили алерт: rate(shop_orders_total[5m]) ниже порога — сообщение в чат дежурному. В четыре утра воскресенья витрина законно пустела, алерт разбудил человека, человек отключил канал, а через две недели настоящая поломка платёжного провайдера прошла незамеченной — ровно потому, что канал уже никто не читал. Ошибка не в метрике и не в пороге — в отсутствии сезонности: у бизнеса есть суточный и недельный ритм, и порог, честный для вторника днём, лжёт ночью. Рабочая схема: сравнение с тем же часом прошлой недели, а не с абсолютным нулём; отдельный тихий алерт на полное отсутствие событий через absent; и правило: каждое ложное срабатывание либо чинится, либо алерт гасится вовсе — молча игнорируемый алерт хуже его отсутствия.

Вариация примера, которая экономит месяцы: прежде чем заводить новую метрику, проверьте, что срез не получается из существующей. Продукт спрашивает «сколько заказов с доставкой в регионы» — если лейбл delivery_region существовал с первого дня, ответом будет суммирование rate по нему; если нет — метрика даётся дорого: релиз, накопление истории заново, тихие графики. Отсюда практика первого дня: сядьте с аналитиком и выпишите срезы, которые точно спросят — способ оплаты, регион, платформа клиента, — и заведите их лейблами сразу. Спорная граница: не больше пяти-шести лейблов на метрику и только с малым числом значений, иначе кардинальность съест выигрыш. Список срезов живёт рядом с кодом метрик и пересматривается раз в квартал: срез, который никто не открывал за квартал, — кандидат на удаление.