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

(Розділ: Операції та Управління)

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 & Ціни: vitrina↔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, дії з інтерфейсу, трасування до сировини і сувора узгодженість з білінгом і аудитом. Побудуйте його на подієвій архітектурі, дайте контекст за ролями, додайте руни і ескалації - і ви отримаєте передбачувані операції, швидкі рішення і стійке зростання.