Привет, %username%! Сегодня поговорим о теме, которая часто остается в тени инфраструктурного мониторинга, но при этом не менее важна — о мониторинге бизнес-метрик. Если ты SRE, DevOps или TeamLead, то наверняка сталкивался с ситуацией: все графики зеленые, CPU не плавится, память в норме, а бизнес приходит и говорит “что-то не работает”. И вот тут начинается самое интересное.

Зачем вообще нужны бизнес-метрики?

Давай начнем с простого вопроса: зачем мы вообще запускаем сервисы? Правильно — чтобы они решали чьи-то проблемы и приносили деньги. И вот тут классический технический мониторинг начинает пробуксовывать. Ты можешь знать, что у тебя загрузка CPU 15%, время выполнения запроса (latency) 50ms, а количество 500-ошибок в пределах нормы. Но ты не знаешь, сколько пользователей прямо сейчас платят за твой сервис, какой процент из них доходит до формы оплаты, и приносит ли вообще твой продукт деньги.

Представь себе ситуацию: твой сайт работает отлично с технической точки зрения, но пользователи не могут найти кнопку оплаты, потому что она потерялась где-то внизу страницы после последнего релиза. Инфраструктурный мониторинг тебе об этом не скажет. А вот бизнес-метрики — скажут сразу, как только конверсия в оплату упадет.

Три слоя мониторинга: от железа до бизнеса

В НСПК (Национальная система платежных карт, те самые ребята, что делают карты “Мир”) придерживаются подхода, который я считаю очень правильным: сервис нужно раскладывать на три слоя, и мониторить строго сверху вниз.

Бизнес-слой — это то, что видит конечный пользователь. Для платежной системы это объемы успешных авторизационных запросов, количество операций по типам, время обработки платежей. Для интернет-магазина — это количество успешных заказов, средний чек, конверсия в покупку. Для SaaS-продукта — количество активных подписок, revenue per user, churn rate.

Прикладной слой — данные о работе приложений: статусы модулей, метрики используемого ПО, технические логи. Тут уже можно задействовать готовые экспортеры и интеграции.

Инфраструктурный слой — классика: CPU, память, диск, сеть, состояние железа.

Почему именно сверху вниз? Потому что бизнес-метрики — это главное. Если у тебя бизнес-метрики в порядке, но один из серверов немного подгружен — это не критично. А вот если бизнес-метрики падают, даже при зеленой инфраструктуре — это уже проблема, которую надо расследовать немедленно.

Методологии мониторинга: USE, RED и UCA

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

USE-метод: следим за ресурсами

USE — это акроним от Utilization, Saturation, Errors (Утилизация, Насыщение, Ошибки). Метод предложил Brendan Gregg, и он отлично работает для низкоуровневых метрик.

Если упростить, то для каждого ресурса системы (CPU, память, диск, сеть) ты смотришь три показателя:

  • Utilization — насколько загружен ресурс (например, CPU загружен на 80%)
  • Saturation — есть ли очередь к ресурсу (например, 10 процессов ждут своей очереди на выполнение)
  • Errors — количество ошибок, которые возвращает этот ресурс

USE помогает быстро выявить узкие места в системе. Если у тебя диск утилизирован на 100%, а очередь на запись растет — вот тебе и проблема.

RED-метод: следим за сервисами

RED — это Rate, Errors, Duration (Скорость, Ошибки, Продолжительность). Метод предложил Tom Wilkie специально для микросервисных архитектур.

Для каждого сервиса ты отслеживаешь:

  • Rate — количество запросов в секунду
  • Errors — количество неудачных запросов в секунду
  • Duration — время обработки каждого запроса

RED дает тебе возможность посмотреть на систему глазами пользователя. Если у тебя растет количество ошибок или увеличивается время ответа — пользователи это сразу почувствуют. Метод отлично работает для веб-сервисов, API, баз данных — везде, где есть концепция “запрос-ответ”.

UCA-метод: следим за бизнесом

И вот мы подходим к самому интересному — UCA (Users, Conversions, Activity). Этот метод предложил Mike Julian, и он целенаправленно нацелен на измерение бизнес-метрик.

Users (Пользователи) — кто является пользователями твоего сервиса? Для разных отраслей это могут быть разные показатели: количество активных пользователей, посетителей на сайте, звонков в колл-центр, покупателей в час.

Conversions (Конверсии) — это про то, как пользователь приносит доход твоему сервису. Купил подписку? Забронировал номер в отеле? Оформил заказ? Это всё конверсии.

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

UCA позволяет собирать метрики, которые показывают, как бизнес себя чувствует. И отталкиваясь от этих метрик, ты уже можешь искать проблемы на уровне USE и RED — понимать, из-за ухудшения каких показателей стоит поднимать инженеров.

Какие метрики собирать на практике

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

Мониторинг бизнес-метрик:

  • Сколько пользователей зарегистрировано в системе?
  • Сколько пользуется приложением раз в день/неделю/месяц (DAU/WAU/MAU)?
  • Какой процент людей после регистрации доходит до формы оплаты?
  • Сколько они платят (средний чек, медианный чек)?
  • Как люди пользуются услугами — какие фичи популярны, а какие нет?
  • Какова общая выручка и прибыль?

Мониторинг состояния приложений:

  • Количество запросов в единицу времени (RPS)
  • Количество активных пользователей в системе
  • Количество записей в БД (общее и новых в единицу времени)
  • Количество ошибок в сервисе
  • Время выполнения запросов или latency (50-й, 95-й, 99-й процентили)

Мониторинг оборудования:

  • Нагрузка на CPU
  • Свободное место в RAM
  • Свободное место на дисках
  • Нагрузка на сеть
  • IOPS на дисках
  • Количество запущенных процессов

Инструменты для мониторинга бизнес-метрик

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

Для бизнес-метрик: Google Analytics и Яндекс.Метрика

Если речь идет о веб-сервисах, то Google Analytics и Яндекс.Метрика — это базовый минимум. Они позволяют отслеживать базовые переходы и конверсии готовыми средствами.

Яндекс.Метрика особенно хороша для российского рынка — она корректнее учитывает трафик из Яндекса, работает в соответствии с ФЗ-152, и у нее интуитивный интерфейс для русскоязычных пользователей. Google Analytics дает больше возможностей для крупных проектов с большими объемами данных (до 200 000 запросов в сутки против 5000 у Метрики).

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

Для прикладных метрик: Prometheus + Grafana

Prometheus — это система сбора и хранения метрик временных рядов, которую изначально разработали в SoundCloud. Она стала стандартом де-факто для сбора метрик в современных инфраструктурах.

Grafana — универсальная обертка для визуализации. Она сама ничего не собирает и не хранит, но умеет красиво отображать данные из Prometheus, PostgreSQL, ClickHouse и еще десятков источников.

Связка Prometheus + Grafana позволяет собирать как технические метрики (через экспортеры — node_exporter для системных метрик, nginx-prometheus-exporter для Nginx и т.д.), так и бизнес-метрики твоего приложения. Да-да, Prometheus прекрасно справляется со сбором бизнес-метрик: выручка за день, количество активных пользователей, количество заказов — достаточно сделать свой endpoint /metrics в приложении и экспортировать туда нужные данные.

Для операционной аналитики: Splunk

В НСПК для комплексного анализа используют Splunk — платформу операционной аналитики. Splunk умеет:

  • Анализировать тысячи метрик в фоновом режиме с использованием статистических анализаторов
  • Обнаруживать аномалии и делать прогнозы с помощью машинного обучения
  • Создавать сложные параметризованные отчеты для дежурной службы
  • Коррелировать данные из разных источников

Splunk — это уже не просто мониторинг, а платформа для принятия решений. Он позволяет не только видеть, что что-то пошло не так, но и понимать, почему это произошло, и как это влияет на бизнес.

Для логирования: ELK Stack

ELK (Elasticsearch, Logstash, Kibana) или его альтернатива EFK (где вместо Logstash используется Fluentd) — это стек для агрегации и анализа логов.

Когда у тебя есть бизнес-метрики и прикладные метрики, логи становятся третьим измерением, которое помогает расследовать инциденты. Ты видишь на графике, что конверсия упала в 14:37, переходишь в логи и находишь, что именно в это время начались ошибки при работе с платежным шлюзом.

Как выстраивать систему мониторинга

Теперь самое важное — как это всё организовать.

Строй ресурсно-сервисную модель

Первый шаг — понять, что именно ты мониторишь. В НСПК разделяют данные на три слоя, а в большой компании нужна еще и ресурсно-сервисная модель (РСМ) — структурированное описание того, какие компоненты обеспечивают работу конкретного сервиса.

Например, сервис “Интернет-магазин” состоит из:

  • Frontend (Nginx, React-приложение)
  • Backend API (несколько микросервисов на Java)
  • База данных (PostgreSQL)
  • Кэш (Redis)
  • Очередь сообщений (RabbitMQ)
  • Платежный шлюз (внешний API)

Для каждого компонента ты настраиваешь сбор метрик на всех трех уровнях. И когда бизнес-метрика “конверсия в оплату” начинает падать, ты уже знаешь, на какие компоненты смотреть.

Используй “зонтичный” мониторинг

Одна из лучших практик — использовать “зонтик”, единый слой, который агрегирует данные от различных систем: Zabbix, Prometheus, ELK, и т.д.. Это дает целостную картину и упрощает анализ.

Представь: у тебя Prometheus собирает метрики приложений, Zabbix мониторит железо, ELK собирает логи, а Google Analytics собирает поведенческие данные. Если у каждой команды свой дашборд в своем инструменте — корреляцию данных не увидеть. А вот если всё это агрегировано в одном месте (например, в Grafana или Splunk) — картина становится прозрачной.

Настраивай алерты правильно

Система оповещений — это компонент мониторинга, который выполняет действия на основе изменений метрик. Основная цель алертов — привлечь внимание человека к текущему состоянию системы.

Важные моменты:

  • Алерт должен содержать информацию о том, что пошло не так и где найти дополнительную информацию
  • Не алерть на всё подряд — это приводит к “усталости от алертов”
  • Настраивай алерты сначала на бизнес-метрики, потом на прикладные, и только в конце — на инфраструктурные

Например, алерт “CPU загружен на 80%” — это информационный сигнал. А вот “Конверсия в оплату упала на 50% за последние 10 минут” — это уже критический инцидент, который требует немедленного реагирования.

Делай метрики прозрачными для всех

Один из ключевых принципов — все члены команды должны видеть одну и ту же информацию из одного источника. QA, разработчики, админы, аналитики, менеджеры продукта — все должны смотреть на одни и те же дашборды.

Когда у всех единая точка входа, начинает работать коллективный разум. Разработчик может заметить, что после его релиза упала конверсия. Админ увидит, что в момент падения бизнес-метрики начались таймауты при обращении к базе. Аналитик обратит внимание, что падение началось после того, как изменилась логика расчета скидок. Вместе они найдут причину быстрее.

Ошибки, которых стоит избегать

Давай поговорим о том, чего не надо делать.

Ошибка 1: Отсутствие связи между бизнес-задачами и аналитикой

Самая частая проблема — когда ты собираешь метрики “потому что так надо”, но не понимаешь, зачем ты их собираешь.

Правильный подход: начинай с бизнес-целей. Бизнес хочет увеличить выручку на 20%? Отлично, декомпозируй это на метрики: нужно увеличить количество заказов или средний чек? Если заказы — то нужно больше пользователей или выше конверсия существующих? И так далее.

Ошибка 2: Мониторинг без проверок качества данных

Представь: ты построил красивый дашборд, но данные в него приходят с ошибками. Счетчик установлен не на всех страницах. Конверсионные события дублируются. В результате твои метрики показывают 30% конверсии, а на самом деле она 3%.

Проверяй качество данных: делай периодические проверки полноты и согласованности, тестируй бизнес-правила, отслеживай источники данных и трансформации.

Ошибка 3: “Плавающее” руководство по сбору данных

Когда у тебя нет четкого стандарта, как называть метрики, как их собирать, и где их хранить — начинается хаос. Один разработчик называет метрику orders_count, другой — order.count, третий — OrdersTotal. В итоге ты не можешь нормально искать и агрегировать данные.

Установи стандарты: naming conventions для метрик, формат лейблов, структуру дашбордов. И следи, чтобы все их соблюдали.

Ошибка 4: Разрозненные данные

Когда метрики инфраструктуры хранятся в Zabbix, прикладные — в Prometheus, бизнесовые — в Google Analytics, а логи — в ELK, и всё это никак не связано между собой — ты не можешь проводить корреляцию.

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

Ошибка 5: Исправление ошибок “по факту”

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

Мониторинг — это профилактика. Гораздо дешевле обнаружить проблему на графике и исправить её до того, как она повлияла на пользователей, чем тушить пожар, когда половина клиентов уже не может сделать заказ.

Практический чек-лист

Если ты хочешь построить нормальную систему мониторинга бизнес-метрик, вот тебе чек-лист для самопроверки:

Базовый уровень:

  • Определен список основных бизнес-метрик (выручка, количество заказов, конверсии)
  • Бизнес-метрики декомпозированы от уровня руководства до команд
  • Определены сопутствующие метрики (MAU, количество товаров в чеке и т.д.)
  • Определен список прикладных метрик (RPS, latency, error rate)
  • Для каждой метрики определен период обратной связи (как часто проверять)

Продвинутый уровень:

  • Определены и автоматизированы источники данных по всем метрикам
  • Определены события/встречи, на которых обсуждаются метрики
  • Планирование работы осуществляется на основании метрик
  • Для каждой задачи есть понимание, на какую метрику она влияет
  • Все заинтересованные лица имеют доступ к метрикам
  • Есть система алертинга на критические изменения метрик

Экспертный уровень:

  • Используется зонтичный мониторинг, агрегирующий данные из всех систем
  • Настроена корреляция между метриками разных уровней
  • Внедрены проверки качества данных
  • Существует документированный стандарт сбора и именования метрик
  • Метрики используются для принятия бизнес-решений

Выводы

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

Ключевые мысли:

  1. Мониторь сверху вниз: начинай с бизнес-метрик, потом прикладные, и только в конце инфраструктурные
  2. Используй правильные методологии: USE для ресурсов, RED для сервисов, UCA для бизнеса
  3. Стремись к единой точке анализа: все команды должны смотреть на одни и те же данные
  4. Автоматизируй сбор данных: ручной сбор метрик — это прошлый век
  5. Делай метрики основой для принятия решений: не просто смотри на графики, а делай выводы и действуй

Управление проектом без метрик — это как плавание ночью на корабле без карты и навигации. Ты вроде бы куда-то плывешь, но рано или поздно это закончится плохо.

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

Полезные ссылки

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

О способах отблагодарить автора можно почитать на странице “Донаты”.