Операционный дашборд

(Раздел: Операции и Управление)

1) Назначение и принципы

Операционный дашборд — это «единое окно» для мониторинга здоровья платформы и принятия действий. Он агрегирует метрики, события, алерты и бизнес-показатели в контексте роли пользователя (SRE, Product, Финансы, Compliance, Support, Партнеры).

• Actionable by design: каждый виджет имеет кнопку действия (rollback, pauze, re-run, re-route).
• Role-aware: права и уровни детализации зависят от роли/тенанта/региона.
• Source-of-truth: цифры сходятся с биллингом/журналами/квитанциями.
• Near-real-time + историчность: секунды/минуты для инцидентов, месяцы/годы для трендов.
• Explainability: любой агрегат разворачивается до сырого события с `trace_id`.

2) Роли и сценарии (кто и зачем приходит)

SRE/Платформа: доступность, латентность p50/p95/p99, ошибка/ретраи, capacity, cost per 1k событий.
Продукт/Операции: E2E-Success Rate, конверсия, время онбординга партнеров, фичефлаги.
Финансы/FinOps: выручка/COGS/CM на единицу, egress/ingress, бюджеты и капы, отклонения.
Комплаенс/Безопасность: квитанции/подписи, PII-запросы, SoD-нарушения, статус рецертификаций.
Support/CS: очередь тикетов, MTTA/MTTR, SLA по партнерам и регионам.
Партнеры/Тенанты: собственные метрики SLO, статусы вебхуков, usage и квоты.

3) North Star и ключевые SLI/SLO

North Star: E2E Success Rate по критичным маршрутам при целевых p95 в каждом регионе.

• Доступность per-канал/регион.
• Латентность p50/p95/p99.
• Error-rate и доля ретраев.
• Успешность доставок вебхуков (% с квитанциями).
• Стоимость 1k событий и egress/ingress на единицу.
• Сводка инцидентов: MTTA, MTTR, error-budget burn.

• Доступность ≥ 99.95% / регион / канал.
• p95 ≤ 120 мс (витрина), ≤ 250 мс (checkout/quote).
• Успешность вебхуков ≥ 99.5% за 5-мин. окно.
• Δ между quote и checkout = 0 (±1 minor unit по правилам распределения).
• Время реакции на P1 ≤ 10 мин, MTTR ≤ 60 мин.

4) Архитектура данных дашборда

Событийная шина: телеметрия (traces/metrics/logs), бизнес-ивенты, биллинг, комплаенс.
Стриминг/агрегации: окна T+5s/T+1m для near-real-time; CDC/outbox для гарантированной доставки.
Хранилища: time-series (оперативка), OLAP (долгая история), WORM-журналы (аудит).
Семантический слой: словарь метрик, единицы измерения, нормализация по регионам и тенантам.
Линк на сырье: drill-down до `trace_id`/`event_id` и подписи (receipt_hash).

5) Дизайн интерфейса и виджетов

Глобальная шапка: фильтры (время, регион, тенант, продукт, среда), индикаторы состояния.
Плитки (KPIs): E2E Success, доступность, p95, error-rate, cost/1k, egress.
Графики: sparkline тренды, heat-map по регионам, перцентильные графики.
Таблицы: топ-ошибки, партнеры с деградацией, превышение квот, незакрытые инциденты.
Секции действий: «Пауза промо», «Откат фичи», «Повысить квоту», «Перезапустить доставку».
Context-help: подсказки про метрики/методики и связь с SLO.

6) Модули дашборда (рекомендуемый набор)

1. Здоровье платформы: доступность/латентность/ошибки, burn-down error-бюджета.
2. Партнерские интеграции: статус вебхуков, квитанции, идемпотентные дубли, lag очередей.
3. Checkout & Цены: витрина↔checkout соответствие, `fx_version`, `tax_rule_version`, отказ-кейсы.
4. Контент/Каталоги: время публикации, ошибки кэша/инвалидатора, freshness.
5. RTP & Limits (если применимо): теор. vs observed RTP, срабатывания лимитов, экспозиция.
6. FinOps: COGS/единицу, egress/ingress, compute/storage, бюджеты/кап-алерты.
7. Security/Compliance: SoD, JIT, MFA, подписанные операции, PII-запросы и журналы.
8. Support: очереди, MTTA/MTTR, причины, авто-рунбуки.
9. Release/Feature Flags: статусы релизов, канареечные регионы, автосклейка регрессий с инцидентами.
10. Experiments: A/B guardrails, влияние фич на SLI/ROI.

7) Алерты, руны и эскалации

Алерты уровня P1–P3 с шумоподавлением и дедупликацией по `trace_id`.
Авто-рунбуки: при срабатывании — запуск проверок/фиксов (очистка кэша, переключение роутинга, пауза промо).
Эскалации: матрица 24×7, SLO ответа, каналы (chat/voice/SMS), «красная кнопка».
Post-incident: шаблоны отчетов с причинно-следственными связями и action items.

8) Мультирегиональность и multi-tenant

Срезы: регион/тенант/канал/провайдер, независимые SLO и бюджеты.
Зоны доверия: данные PII/финансы — видны только в соответствующих областях, остальным — агрегаты.
Cost-aware: сравнение маршрутов по цене при одинаковом p95; рекомендации по оптимизации.

9) Безопасность и приватность

RBAC/ABAC: видимость и действия по ролям; ReBAC для владения продуктом/тенантом.
Подписи и квитанции: для финансовых/критичных событий — хеши и DSSE-квитанции.
PII-гигиена: токенизация, маскирование, доступ только через утвержденные джобы.
Аудит: WORM-журналы для изменений конфигов/ролей/лимитов, воспроизводимость.

10) Модель данных метрик (пример)

`metric` `{name, unit, type: counter/gauge/hist, owner, sla_ref}`

`dim` `{region, tenant, product, provider, version, environment}`

`point` `{metric, value, ts, dims{}, trace_id, signature?}`

`event` `{type, severity, subject_id, payload_hash, receipt_hash, ts}`

`slo` `{name, target, window, burn_rate, owners[], runbook_url}`

`alert` `{slo_ref, condition, status, ack_by, acknowledged_at, runbook_step}`

11) API/вебхуки дашборда

`POST /ingest/metrics` — прием метрик (схема, лимиты, аутентификация).
`POST /ingest/events` — бизнес-события (версии/подписи).
`GET /kpis?filters…` — агрегаты для виджетов.
`GET /traces/{trace_id}` — глубокая раскрутка.
Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookDeliveryLag`, `SecuritySoDViolation`.

12) Качество данных и тесты

Data contracts: схемы и валидация на приеме, версионирование (`expand → migrate → contract`).
Аномалии: мониторинг пропусков/скачков, пороги «flatline»/«noise».
Сэмплирование: для high-QPS метрик — скользящее, с сохранением репрезентативности.
Backfill: безопасные обратные загрузки с пометкой версии.

13) Метрики самого дашборда (метрики метрик)

Доступность UI/API ≥ 99.9%.
Latency p95 запросов к API ≤ 300 мс.
Completeness: доля источников, которые прислали данные в окно, ≥ 99.5%.
Freshness: лаг инкрементальных обновлений ≤ 30 с.
Correctness: расхождение с эталонными отчетами ≤ 0.1%.

14) Экономика и FinOps в дашборде

Cost per 1k событий с разложением по провайдеру/региону.
Egress/Ingress тепловые карты, рекомендации кэширования/роутинга.
Бюджеты/кап-алерты: 80/90/100%, автотротлинг и приоритизация.

15) Доступность и UX

Ночная тема, краткие подписи, иконки статусов.
Клавиатурная навигация и a11y: контраст, alt, aria-метки.
Сохраненные пресеты: «дежурство SRE», «финансы», «партнер».
Снапшоты и шэринг: зафиксировать состояние с фильтрами и ссылкой/экспортом.

16) Риски и анти-паттерны

Dash-sprawl: 20 разных дашбордов без единого словаря метрик.
Vanity-метрики: красивые графики без связи с SLO/действиями.
Несходимость цифр: отчеты ≠ биллинг/аудит.
Шумные алерты: усталость и пропуски P1.
Отсутствие drill-down: невозможно добраться до первички и причин.

17) Чек-лист внедрения

• Определить роли и сценарии; согласовать North Star и SLI/SLO.
• Завести словарь метрик и единиц; формализовать data contracts.
• Настроить ingest (metrics/events/traces), OLAP и WORM-аудит.
• Реализовать ключевые модули (здоровье, партнеры, checkout, FinOps, Security).
• Включить алерты с рунами и эскалациями; «красная кнопка».
• Добавить действия: rollback/pause/re-route/raise-limit.
• Построить heat-map по регионам/тенантам; фильтры и пресеты.
• Верифицировать сход цифр с биллингом/квитанциями.
• Игра-день (GameDay): отключение провайдера, лавина ретраев, рассинхронизация цен.
• Еженедельные ревью SLO и post-mortem-качество.

18) RACI

19) FAQ

Можно ли заменить все отчеты дашбордом?
Нет. Дашборд — для оперативки и действий; формальная отчетность/аудит — отдельные артефакты.

Сколько «реального времени» нужно?
Для инцидентов — секунды/минуты, для экономики — минуты/часы; важна согласованность, а не абсолютная «онлайн-ность».

Как бороться с шумом алертов?
SLO-ориентированные условия, агрегация, дедупликация по `trace_id`, приоритизация и авто-рунбуки.

Как проверить корректность метрик?
Регулярные сверки с эталонными отчетами, тестовые фиды, контрольные выборки и WORM-журналы.

Резюме: Операционный дашборд — не «красивая доска», а инструмент управления: единые SLI/SLO, действия из интерфейса, трассировка до сырья и строгая согласованность с биллингом и аудитом. Постройте его на событийной архитектуре, дайте контекст по ролям, добавьте руны и эскалации — и вы получите предсказуемые операции, быстрые решения и устойчивый рост.