操作儀表板

（部分： 業務和管理）

1）任命和原則

操作儀表板是監視平臺健康和采取行動的「單一窗口」。它在用戶角色（SRE，產品，財務，合規性，支持，合作夥伴）的上下文中匯總度量，事件，Alerta和業務指標。

• 可通過設計進行操作：每個小部件都具有一個動作按鈕（滾回、pauze、re-run、re-route）。
• Role-aware：權限和詳細程度取決於角色/tenant/區域。
• 真相來源：數字與賬單/日誌/收據收斂。
• 近實時+歷史性：事件/分鐘、趨勢/年。
• Explainability：任何集合都在「trace_id」的原始事件之前展開。

2）角色和劇本（誰來為什麼）

SRE/Platform：可用性，p50/p95/p99的潛在性，錯誤/retrai，capacity，cost per 1k事件。

產品/操作： E2E-Success速率,轉換,合作夥伴登機時間,ficheflagi.

財務/FinOps：單位收入/COGS/CM，egress/ingress，預算和上限，偏差。
合規性/安全性：收據/簽名,PII請求,SoD違規,退位狀態。
支持/CS：按合作夥伴和地區分列的tiket隊列，MTTA/MTTR，SLA。
合作夥伴/Tenants：自己的SLO度量，webhook狀態，使用和配額。

3）北極星和關鍵SLI/SLO

北極星：在關鍵路線上E2E成功率，每個地區的目標p95。

• 通道/區域可用性。
• 潛伏期p50/p95/p99。
• Error-rate和retraes的份額。
• Webhook交付成功（帶收據的百分比）。
• 每單位1k事件和egress/ingress的成本。
• 事件摘要：MTTA，MTTR，error-budget burn。

• 可用性≥ 99。95%/地區/頻道。
• p95 ≤ 120毫秒（店面），≤ 250毫秒（checkout/quote）。
• Webhooks的成功率≥ 99。5分鐘5%窗口。
• quote和checkout=0之間的Δ（根據分配規則± 1個小單位）。
• 對P1 ≤ 10分鐘的反應時間，MTTR ≤ 60分鐘。

4） dashboard數據體系結構

事件總線：遙測（traces/metrics/logs），業務活動，計費，合規性。
流/聚合：T+5s/T+1m窗口用於近實時；CDC/outbox用於保證交付。
存儲：時間系列（操作），OLAP（歷史悠久），WORM日誌（審計）。
語義層：度量詞典，度量單位，按區域和tenant歸一化。
原材料鏈接：drill-down到「trace_id」/「event_id」和簽名（receipt_hash)。

5）接口和小部件設計

全局帽：過濾器（時間，區域，tenant，產品，環境），狀態指示器。

圖塊（KPIs）： E2E成功,可用性,p95, error-rate, cost/1k, egress.

圖表：火花線趨勢，按地區排列的熱圖，胡椒圖。
表：頂級錯誤，降級合作夥伴，配額過多，未解決事件。
行動部分：暫停促銷、回滾狂歡、提高配額、重新開始交付。
上下文幫助：關於度量/技術的提示以及與SLO的聯系。

6） dashboard模塊（推薦套件）

1.平臺健康狀況：可用性/潛在性/錯誤,burn-down錯誤預算。
2.合作夥伴集成：webhook狀態，收據，偶數雙打，排隊。
3.Checkout&Price： vitrina↔checkout合規性、'fx_version'、'tax_rule_version'、故障案例。
4.內容/目錄：發布時間，緩存/殘障人士錯誤，新生。
5.RTP&Limits（如果適用）：theor。vs觀察到RTP，觸發極限，曝光。
6.FinOps：COGS/單位，egress/ingress，compute/storage，預算/上限。
7.安全/合規性：SoD，JIT，MFA，簽名操作，PII查詢和日誌。
8.支持：隊列，MTTA/MTTR，原因，自動符文。
9.Release/Feature Flags：發布狀態、金絲雀地區、事件回歸自動滑塊。
10.實驗：A/B guardrails，幻想對SLI/ROI的影響。

7）Alerta，符文和升級

通過「trace_id」進行降噪和重復數據消除的P1-P3級別變量。
Auto-runbooks：觸發時-啟動檢查/虛假（清除緩存、切換路由、暫停促銷）。
上報：矩陣24 × 7，響應SLO，通道（聊天/聲音/SMS），「紅色按鈕」。
事後事件：具有因果關系和動作項的報告模板。

8）多區域性和多區域

切片：區域/tenant/頻道/提供商，獨立的SLO和預算。
信任區：PII/財務數據-僅在相關區域可見，其余為集合。
Cost-aware：以相同的p95價格比較路線；優化建議。

9）安全和隱私

RBAC/ABAC：可見性和角色動作；ReBAC 擁有產品/tenant。
簽名和收據：對於財務/關鍵事件-哈希和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/webhooks dashboard

「POST/ingest/metrics」-接受度量（電路，限制，身份驗證）。
「POST/ingest/events」-業務事件（版本/簽名）。
`GET /kpis?filters……'是小部件的集合。
'GET/traces/{trace_id}-深層旋轉。

Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookDeliveryLag`, `SecuritySoDViolation`.

12）數據質量和測試

數據合同：接收時的電路和驗證，檢查（「expand → migrate → contract」）。
異常：監視通行證/跳躍，「flatline」/」noise」閾值。
采樣：對於高QPS，度量是滾動的，具有代表性。
Backfill：標記版本的安全反向下載。

13）dashboard本身的度量（度量標準）

UI/API可用性≥ 99。9%.

Latency p95對API的查詢≤ 300毫秒。

完整性： 向窗口發送數據的源的比例≥ 99。5%.

Freshness：一次增量更新≤ 30秒。

Correctness： 與參考報告的差異≤ 0。1%.

14）經濟和FinOps在dashboard

按供應商/區域分解的1k事件成本。
Egress/Ingress熱卡，緩存/漫遊建議。
預算/上限：80/90/100％，自動旋轉和優先級。

15）可用性和UX

夜間主題，簡短簽名，狀態圖標。
鍵盤導航和a11 y：對比，alt，aria標簽。
保留的預期：「SRE職責」，「財務」，「合作夥伴」。
Snapshots和Sharing：使用過濾器和鏈接/導出記錄狀態。

16）風險和反模式

Dash-sprawl：20個不同的行車記錄儀沒有單一的度量詞典。
名利度量：美麗的圖形,沒有鏈接到SLO/活動。
數字不一致：報告≠賬單/審計。
嘈雜的Alerts：疲勞和通過P1。
缺少drill-down：不可能達到主要原因和原因。

17）實施支票

• 定義角色和情景；北極星和SLI/SLO協調。
• 建立指標和單位詞典；正式化數據合同。
• 自定義ingest （metrics/events/traces）、OLAP和WORM審核。
• 實現關鍵模塊（健康、合作夥伴、檢查、FinOps、安全）。
• 包括帶有符文和升級的Alerta；「紅色按鈕」。
• 添加操作：rollback/pause/re-route/raise-limit。
• 按地區/特南特繪制熱圖；過濾器和預設。
• 核對賬單/收據中的數字。
• 遊戲日（GameDay）：禁用提供商、雪崩、價格同步。
• SLO和mortem後質量的每周評論。

18) RACI

19) FAQ

可以用行車記錄板替換所有報告嗎?

沒有。Dashbord-用於操作和動作；正式報告/審計-個別工件。

需要多少「實時」？
對於事件-秒/分鐘，對於經濟-分鐘/小時；一致性而不是絕對的「在線性」很重要。

我該如何處理噪音?

基於SLO的條件，聚合，「trace_id」重復數據消除，優先級和自動符文。

如何驗證指標是否正確?

定期與參考報告，測試樣本，控制樣本和WORM日誌進行對賬。

摘要：操作儀表板不是「漂亮的棋盤」,而是控制工具：單個SLI/SLO、界面操作、原材料跟蹤以及嚴格的計費和審計一致性。在事件體系結構上構建它，根據角色給出上下文，添加符文和升級-並且您將獲得可預測的操作，快速的解決方案和穩定的增長。