Модуль 18. Grafana для продуктовой и операционной аналитики

Зачем Grafana BA: где её место

BI (Power BI/Looker/Tableau) — отчётность и бизнес-решения (GM%, выручка, когортная аналитика).
Grafana — телеметрия и эксплуатация: время отклика, ошибки, доступность, логи, инфраструктура, real-time алерты.
Пересечение: Grafana отлично агрегирует операционные SLI/SLO и может прикрутить продуктовые метрики (retention, MAU) из SQL-источников — на одном экране рядом с p95 / error rate и релизами.

Архитектура и источники: как собрать «единый экран»

Источники (data sources):

Prometheus — метрики приложений/инфры (PromQL).
Loki — логи (LogQL).
ClickHouse — событийнка/продуктовые метрики (SQL).
Postgres — транзакционка, справочники, релизы/аннотации (SQL).

Поток:
метрики (Prometheus) + логи (Loki) + продуктовые события (ClickHouse/Postgres) → Grafana → панели, Explore, Alerting, Annotations.

Подсказка BA: заведите переменные $service, $env, $version и везде используйте единую схему меток (service, env, version, region), чтобы панели и алерты не плодились копиями.

SLI/SLO и алерты: теория «ровно сколько нужно»

SLI — измеримая характеристика сервиса: доля успешных запросов, p95 latency, uptime.
SLO — целевое значение SLI за интервал (например, 99.9% успешных запросов за 28 дней).
Error budget = 1 − SLO (для 99.9% это 0.1%).
Burn rate = (фактическая доля ошибок) / (error budget).
Идея алертов — мульти-окна / мульти-пороги: быстро ловим пожары (короткое окно, высокий burn), и замечаем тление (длинное окно, умеренный burn).

Прометей: практические PromQL-формулы (p95, error rate, SLO)

p95 latency (гистограммы)

histogram_quantile(
  0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket{job="$service", env="$env"}[5m]))
)

Частые ошибки: слишком редкие события (пустые корзины), смешивание разных endpoint’ов/методов — агрегируйте осмысленно.

Error rate

sum(rate(http_requests_total{job="$service", env="$env", status=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="$service", env="$env"}[5m]))
Вариант «успехи/все»:
1 - (
  sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
  / sum(rate(http_requests_total[5m]))
)

SLO и burn rate (пример для SLO успехов 99.9%)

# error_ratio за 5 мин
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
# burn_rate
(
  sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
)
/ 0.001   # 0.1% бюджет ошибок

Пример алертов (две ступени)

Пейджинг (быстрый пожар): burn_rate > 14 в окне 5–10 мин и подтверждение в окне 1 ч > 6.
Тикет (тление): burn_rate > 1 в окне 6–24 ч.

Числа подбираются под ваш SLO/трафик. Идея — быстрый сигнал «съедаем бюджет слишком быстро» + долгий «системная деградация».

Loki (LogQL): как связать логи с метриками и релизами

Базовые паттерны:

# error rate по логам (грубая оценка)
sum(rate({app="$service", env="$env"} |= "ERROR" [5m]))
/
sum(rate({app="$service", env="$env"}[5m]))

Корреляция: на панели p95 добавьте exemplars (если включены) или линк «View logs» → Explore с автоподстановкой {trace_id, span_id}/{request_id}.
Релизы из логов: помечайте строкой "deploy version=X.Y.Z" и используйте её для Annotations в Grafana.

ClickHouse/Postgres: продуктовые метрики (retention/кохорты/MAU)

DAU/WAU/MAU (ClickHouse)

SELECT toDate(event_time) AS d, countDistinct(user_id) AS dau
FROM events
WHERE event_time >= now() - INTERVAL 30 DAY
  AND app = 'web' AND env = {{env}}
GROUP BY d
ORDER BY d;

Когортная дневная retention (D0 → D1..D7)

WITH
first AS (
  SELECT user_id, min(toDate(event_time)) AS d0
  FROM events
  WHERE event = 'signup' AND env = {{env}}
  GROUP BY user_id
),
active AS (
  SELECT e.user_id, toDate(e.event_time) AS d
  FROM events e
  ANY INNER JOIN first f USING (user_id)
  WHERE e.event IN ('session_start','purchase','key_action')  -- что считаем «возвратом»
)
SELECT
  d0,
  count() AS cohort_size,
  countIf(d = d0) AS d0_users,
  countIf(d = d0 + 1) AS d1_users,
  countIf(d = d0 + 2) AS d2_users,
  countIf(d = d0 + 7) AS d7_users
FROM first
LEFT JOIN active USING (user_id)
GROUP BY d0
ORDER BY d0

Показ в Grafana: панель «Table» + преобразования (calculate/percent of) → «heatmap»/«state timeline» для визуализации удержания.

Postgres как источник аннотаций релизов

Таблица release_notes(released_at timestamptz, version text, author text, notes text).
В Grafana → Annotations → Data source: Postgres → запрос по released_at BETWEEN $__from AND $__to.

Explore & Correlations: что делать в инцидент

Шаги BA/дежурного:

Панель p95 ↑ и error rate ↑ → клик «Explore».
Split view: слева PromQL (по метрике), справа LogQL для {request_id} или {service="$service"}.
Фильтр по версии $version/региону $region — локализуем проблему.
Аннотации релиза видны? Сверяем время деплоя и всплеск.
Если есть трейсинг (Tempo/OTel) — «View trace» → узкое место (DB/кэш/внешний API).

Панели: макет «p95 + retention + релизы»

Цель: свести эксплуатационные и продуктовые сигналы.

Секции:

KPI-плашки: p95, error rate, SLO-compliance (за 30 дней), MAU/DAU, D1/D7 retention.
График p95 (PromQL) + Annotations по релизам + thresholds (SLO-budget).
График error rate (5xx/все); рядом — rate по таймаутам.
Когортная retention (ClickHouse) — таблица/тепловая карта.
Логи (Loki) — быстрый просмотр последних ошибок/stack traces.
DQ/Freshness-виджет: up{job="prometheus"} + «последний пинг» из ClickHouse/PG (чтобы понимать, не устарели ли данные).

NFR панели: p95 рендер ≤ 2–3 сек при 30 днях истории; аннотаций < 2000 на окно; переменные $service/$env/$version.

Alerting: единые правила, маршруты и «тишина»

Правила (Grafana Alerting): храните в папке «SLO», группируйте по сервисам.
Контакты: Slack/Email/PagerDuty; маршрутизация по $service.
Политики: no_data = OK (если используется or on() vector(0)), execution error = Alerting (чтобы не пропустить).
Silences: авто-окно «на релиз 15 мин» по тэгу $version (если договорено).
Runbook link: у каждого правила — ссылка «что делать» и «как выключить шум».

Пример alert rule (словами):

Condition A: burn_rate_5m > 14 5 мин подряд.
Condition B: burn_rate_1h > 6.
Evaluate: A AND B. Лейблы: service, env, severity=critical. Аннотации: «Release: $version».

Аннотации релизов: как сделать надёжно

Варианты:

Из Postgres (таблица релизов) — надёжно/исторично.
Из Loki — быстрый путь (пишем в лог «deploy X.Y.Z»).
Из GitHub/GitLab Releases — через webhook → PG, либо напрямую как annotations datasource.
Практика: стандартизируйте событие деплоя: service, version, env, author, commit, ticket.

Риски и как их снять

Риск	Симптом	Решение
Кардинальность меток	Панели «умирают», Prometheus ест память	Контроль меток (не класть user_id в label), recording rules, drop/keep relabel
Неправильная p95	«Прыгает» при низком трафике	Достаточные bucket’ы, агрегация по endpoint/методу, минимум трафика
Дубли алертов	Шум: Grafana и Alertmanager дублируют	Единый контур алертинга (либо Grafana, либо Prometheus→Alertmanager), маршрутизация
Временные зоны	«Релиз позже, чем всплеск»	Единый UTC внутри, локаль только на отображении
Устаревшие аннотации	Нет релиза на графике	Источник аннотаций = «единственный» (PG), процессы публикации
Недоверие к retention	Считают «неправильным»	Чёткое «что такое возврат», антибот-фильтры, timezone пользоват., лаг ETL
Нет связи метрик и логов	Долго искать корень	request_id/trace_id в метриках/логах, exemplars/trace sampling
Секреты в логах	Утечки	Сканер секретов, маскировка в логировании, policy «PII off»

Вопрос–ответ (FAQ)

Q: Зачем смешивать продуктовые метрики с эксплуатационными?
A: Чтобы видеть влияние релиза/инцидента на пользователей: p95↑ → D1 retention↓, MAU↓ — аргумент для приоритизации фикса.

Q: Можно ли строить когорты в Grafana как в амплитуде/метабейзе?
A: Да, если источник (ClickHouse/PG) хранит события, а запрос считает когорты. Визуализация проще, но достаточно для BA.

Q: Где хранить SLO — в коде или в Grafana?
A: SLO — договорённость команды (документ). В Grafana — панели/алерты. Метрики и правила — под версионирование.

Q: Почему p95, а не среднее?
A: Среднее прячет «хвост». p95 отражает пользовательский опыт. Часто смотрят p90/p95/p99.

Q: Нужен ли отдельный дашборд для релизов?
A: Полезно иметь журнал релизов (таблица) и аннотации на основных графиках. Так быстрее коррелировать проблемы с релизами.

Q: Можно ли без Prometheus — только ClickHouse?
A: Можно для продуктовых метрик, но операционные SLI (p95/error rate) удобнее и дешевле в Prometheus.

Практика (что сдать по итогу модуля)

A. Панель «p95 + retention + релизы» (макет)

Переменные $service, $env, $version.
График p95 (PromQL из §4.1) с аннотациями релизов (PG) и порогами SLO.
График error rate (PromQL из §4.2).
Когортная retention (ClickHouse, §6.2) — heatmap/таблица.
Быстрые логи (Loki) с фильтром {app="$service", env="$env"}.
DQ/Freshness-виджет для источников.

B. Алерты

Burn-rate пейджинг: быстрый + долгий окна (пример из §4.4/§9).
p95 SLO breach: если p95 > целевого порога X ms 3 из 5 интервалов.
Контакты/маршруты/тихая зона релиза.

C. Аннотации релизов

Таблица release_notes в PG и настройка Annotation Query в Grafana.
Конвенция лог-строки в Loki «deploy version=X.Y.Z».

D. Acceptance-чек (минимум 10)

p95 считает histogram_quantile корректно (сверка эталона).
error rate совпадает с nginx/app-логикой (±допуск).
Аннотации отображаются для выбранного $service/$env.
Burn-rate алерт триггерится на тестовой деградации.
Silence на 15 мин при релизе работает.
Retention-таблица обновляется и корректно считает D1/D7.
Панель рендерится ≤ 3 сек при 30 днях.
Переменные фильтруют все панели консистентно.
Explore открывается из p95 на логи.
Нет чувствительных данных в логах (проверка фильтров/маскировки).

Чек-листы готовности

Метрики/этикетка

Единая схема меток (service, env, version, region).
Записаны recording rules для тяжёлых запросов (p95, success ratio).
SLO документирован (значение, период, владелец).

Данные/источники

Prometheus/Loki/CH/PG подключены, тестовые запросы «зелёные».
Аннотации тянутся из единого источника (PG или Loki-pattern).
Freshness-виджет и health-проверки источников есть.

Alerting

Контакт-поинты и маршруты настроены.
Мульти-окна/мульти-пороги для SLO.
Runbook ссылки у каждого правила.

Безопасность

Маскирование логов, запрещённые поля — отфильтрованы.
Роли/папки Grafana (viewer/editor/admin) настроены.
Бэкапы/экспорт дашбордов под версионирование (JSON в Git).

Вы собираете операционные SLI/SLO (p95, error rate) и продуктовые метрики (retention/MAU) на одной панели Grafana, добавляете аннотации релизов, настраиваете мульти-оконные алерты на burn rate и обеспечиваете «туннель» в Explore → логи. Это делает релизы и инциденты прозрачными: видно не только что сломалось, но и как это сказалось на пользователях.

(BA-фокус). Grafana для продуктовой и операционной аналитики

Где здесь бизнес-аналитик и зачем он нужен

Цель BA в теме Grafana — не «строить графики», а:

Перевести проблемы бизнеса (жалобы, падение конверсии, снижение удержания) в измеримые сервисные цели (SLO) и рабочие панели/алерты, которые реально меняют поведение команд.
Связать продуктовые метрики (MAU, retention, конверсия) с операционными SLI (p95, ошибки, аптайм), чтобы видеть причинно-следственную связь: «как деградации влияют на пользователей и деньги».
Снять шум: договориться об алерт-политике (кто/когда/куда/по какому порогу), чтобы инциденты находились быстро, а Pager не «кричал по любому поводу».
Обеспечить принятие (adoption): паспорт панели, словарь метрик, обучение, процесс аннотаций релизов, регламент UAT и эскалаций.

Результат для бизнеса: меньше падений и «слепых зон», быстрее восстановление (MTTR), меньше обращений в поддержку, выше конверсия/удержание во время релизов.

Карта стейкхолдеров и RACI

Роль	Интерес	Ответственность BA
Продукт/маркетинг (PO/PM)	Конверсия, MAU/WAU, retention, выручка	Связать продуктовые KPI с SLI/SLO; показать эффект инцидентов/релизов на воронку
SRE/DevOps	Доступность, p95, ошибки, инциденты	Согласовать SLI/SLO, алерт-пороги, runbooks, тишину на релиз
Инженеры	Качество релизов, трейсинг	Требования к аннотациям релизов, request_id/trace_id, теги версий
Саппорт/CX	ТТ обращения, CSAT/NPS	Панель симптомов, единый словарь, триггеры эскалаций
Data/BI	Продуктовые события, MAU/retention	Источники (ClickHouse/PG), методика когорт, согласованность с BI
Руководство	Риски/эффекты	Одностраничник «SLO ↔ бизнес-эффекты», ROI

RACI на проект «Единая панель p95 + retention»

R (делает): SRE/Инженерия (метрики/логирование), Data (события), Дизайнер панели.
A (ответственность): Владельцы сервиса/продукта.
C (консультирует): BA, саппорт.
I (информируем): руководство, смежные команды.

От бизнес-цели к метрике: «перевод» BA

Пример: «Утром падает оплатa в мобильном приложении → уходит выручка».
BA раскладывает:

Lag-метрика: конверсия checkout→оплата (продукт).
Lead-метрика: p95 API /payments/authorize, доля 5xx и timeouts (операционная).
SLO: 99.9% успешных запросов и p95 ≤ 800 мс за 28 дней.
Алерт-логика: если burn rate «съедает» бюджет за 1–2 часа → пейджинг.
Аннотации: релизы/фич-флаги рядом с графиками.
Решение: заморозка фич-флага при деградации, откат/фикса.

BA-артефакт: одностраничный Value Case — «Если повысим SLO checkout с 99.5% до 99.9%, ожидаем −30% тикетов саппорта и +0.2 п.п. конверсии → +X ₽/мес».

Словарь простыми словами (для заказчиков)

SLI — «как мы меряем здоровье сервиса» (доля успехов, p95).
SLO — «наше обещание» (99.9% за 28 дней).
p95 — «скорость для требовательных 5% пользователей»: 95% запросов быстрее этого значения.
Error budget — «сколько можем упасть, не нарушив обещание».
Burn rate — «как быстро сжигаем запас ошибок».

Миссия BA — добиться, чтобы все в комнате одинаково понимали эти определения и видели их на панели и в глоссарии.

Что именно BA описывает в требованиях (BRD/SRS-уровень)

Цели и решения: какие управленческие решения принимаются по панели/алертам (заморозка релиза, откат, масштабирование).
Метрики и методология: формулы SLI, окно SLO, правила подсчёта (что такое «успех»), связи с продуктовыми метриками (MAU/retention).
Источники и свежесть: Prometheus/Loki — real-time, ClickHouse/PG — ≤5–15 мин; поведение при задержках («черновик»/баннер).
Алерт-политика: пороги, окна, каналы (Slack/PagerDuty), «тишина на релиз», runbooks и владельцы.
Аннотации релизов: единый источник (таблица релизов), обязательные поля (service, version, env, author, commit).
RLS и приватность: кто что видит, без пользовательских PII/секретов в логах/панелях.
Acceptance-критерии: сверка эталонов, скорость панели, бесшумность при норме, корректная корреляция «метрика→логи».

Две аудитории — два «этажа» одной панели

Этаж 1 — для продукта/менеджмента:

KPI: MAU/DAU, D1/D7 retention, конверсия checkout, «влияние инцидентов на воронку».
Аннотации релизов и A/B-флажков.
Сигналы «красно-жёлто-зелёно» по SLO (без технического шума).

Этаж 2 — для эксплуатации:

p95/p99, успехи/ошибки/таймауты, burn rate, распределение по эндпоинтам/региону.
Быстрые логи/трейсы и фильтры $service/$env/$version.
DQ-виджет: свежесть, up/health источников.

BA следит, чтобы визуальный язык был единым (цвета, подписи, единицы) и чтобы из «этаж 1» кликом можно было спуститься на «этаж 2».

Как BA снижает шум и ускоряет реакцию

Шум (too many alerts) → Правило: «мульти-окна/мульти-пороги», разные маршруты для критичных/минорных; «тишина на релиз».
Долгий MTTR → Требование: request_id/trace_id в логах и метриках, «Explore» из графика в логи за один клик; runbook-ссылка в каждом алерте.
Разночтения → Словарь/паспорт панели с версиями методики и владельцами.

Экономика для руководства (простая модель)

До: 4 крупных инцидента/мес × 45 мин MTTR → 180 мин простоя или деградации; 300 тикетов саппорта; −0,2 п.п. конверсии в день инцидента.
После SLO-проекта: MTTR 20 мин, −30% тикетов, «заморозка релиза» при тревоге → +Х ₽/мес (считаем по вашей воронке).
BA поставляет расчёт, допущения и мониторинг после внедрения (виджет «эффект»).

Риски (бизнес-углы) и как их закрывает BA

Риск	Проявление	Действие BA
Метрики «для галочки»	Панель есть, решений нет	В BRD записать «какое решение по какому сигналу»; чек-лист adoption
Шум алертов	Дежурные игнорируют Pager	Мульти-окна/пороги, тест-день алертов, de-dup, runbooks
Ссора о цифрах	p95 «не сходится»	Эталонные выборки, единая формула успеха/ошибок, версия методики
Невидимость релиза	«После 14:00 всё упало, почему?»	Единый реестр аннотаций релизов на графиках
Нет связи с продуктом	«p95 зелёный, retention красный»	Панель-связка: лаг- vs лид-метрики, когортная таблица рядом
PII/секреты в логах	Риск утечки	Политика маскировки, запрет на PII в дашбордах, аудит

Скрипт BA для discovery (коротко)

«Какие бизнес-решения вы хотите принять по панели/алертам?»
«Какие симптомы вы хотите ловить в первых 5 минут?»
«Какой уровень сервиса мы обещаем пользователю? Что будет, если не выполняем?»
«Кто получает первую страницу (pager) и где runbook?»
«Какие релизные события должны быть аннотированы? Кто owner?»
«Какие метрики продукта меняются при инцидентах? Как мы это покажем?»
«Где граница ответственности (внешние API, платёжка)? Как это отмечаем?»

Примеры артефактов BA

Паспорт панели (выжимка)

Цель: «Сократить MTTR на 50% и снизить FPR алертов на 30%».
Метрики: p95 /checkout, success ratio, burn rate; MAU, D1/D7 retention.
Методология: определения «успеха», окно SLO 28 дней, время/таймзоны.
Владелец: SRE-лид; продуктовый владелец: PM Checkout.
Freshness: Prometheus/Loki — ≤1 мин, ClickHouse — ≤10 мин; поведение при срыве свежести.
Релизы: источник — таблица release_notes.
RLS: отдел/сервис; экспорт — только агрегаты.

Политика алертов (отрывок)

Критический: burn_rate>14 (5–10 мин) и burn_rate>6 (1 ч) → PagerDuty, тэг severity=critical.
Минорный: p95>800мс 3 из 5 интервалов → Slack #ops.
Тишина: 15 мин по тэгу релиза $version.
В каждом алерте: владельцы, ссылка на runbook, «как временно отключить».

DoR/DoD для «панели p95+retention»

DoR: согласованы SLO/SLI, есть реестр релизов, источники подключены, глоссарий обновлён.
DoD: панель ≤3 сек p95, аннотации видны, 10 UAT-кейсов пройдены, алерты протестированы, runbooks привязаны, обучение проведено.

Вопрос–ответ (FAQ)

Q: Зачем BA, если SRE и так всё настроят?
A: SRE настроит метрики. BA связывает их с бизнес-решениями, снижает шум, обеспечивает принятие, формализует SLO как часть value case и контролирует эффект после релиза.

Q: Почему совмещать продуктовые и операционные метрики?
A: Чтобы видеть влияние: деградация p95 → падение конверсии/удержания. Это аргумент для приоритизации (фикс > новая фича).

Q: Что делать, если «ретеншн не бьётся с BI»?
A: Единая методология и словарь, сверка на эталонах, указание версии методики на панели, ссылка на глоссарий.

Q: Как объяснить руководителю «почему p95 важнее среднего»?
A: Среднее скрывает «хвост боли». p95 — «что видит требовательный пользователь». Если p95 плох, жалобы и отток растут, даже когда «в среднем всё ок».

Q: Где хранить аннотации релизов — в логах или БД?
A: Надёжнее — в БД/реестре релизов (история, права, единый формат). Логи — как резерв/быстрый старт.

Практика (именно BA-задачи)

A. Одностраничник «SLO ↔ бизнес»

Опишите 3–5 ключевых пользовательских путей (signup, search, checkout), согласуйте SLI/SLO и решения «что делаем при тревоге». Добавьте оценку эффекта (MTTR↓, тикеты саппорта↓, выручка↑).

B. Паспорт панели и глоссарий

Сформируйте паспорт (цели, метрики, методология, владельцы, Freshness, RLS) и 15–20 терминов (p95, success, burn rate, MAU, D1/D7).

C. Политика алертов и UAT

Напишите правила (критический/минорный), маршруты, тишину на релиз, 10 UAT-кейсов: от «обрыв БД» до «деградация внешнего API», включая «ретеншн не обновился».

D. План обучения и adoption

1-часовой тренинг для продукта/саппорта: «как читать панель», «когда эскалировать», «где методология». Критерий успеха: 80% команды прошли, 70% правильных ответов на мини-квиз.

Чек-лист готовности BA

Цели/решения по панели согласованы и записаны.
SLI/SLO, окна и пороги — в глоссарии и на панели.
Алерты «двумя окнами», runbooks привязаны, «тишина на релиз» описана.
Аннотации релизов из единого источника, обязательные поля заданы.
Панель показывает и продуктовые (MAU/retention), и операционные (p95/error) метрики.
UAT-кейсы пройдены; скорость панели в норме.
Обучение проведено; паспорт/глоссарий доступны из панели.

Роль BA — сделать так, чтобы Grafana стала инструментом управленческих решений, а не «красивыми графиками». Вы определяете язык (глоссарий и методология), задаёте цели (SLO), оформляете правила (алерты/аннотации/эскалации), связываете эксплуатацию с продуктом (retention/MAU), доказываете ценность (ROI через MTTR и конверсию) и обеспечиваете принятие командой.

← Предыдущая статья

Модуль 17. Бизнес-аналитика в медицине (Healthcare)

Следующая статья →

Модуль 19. Техническое задание (ТЗ) для закупок и аутсорса