操作仪表板

（部分： 业务和管理）

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、界面操作、原材料跟踪以及严格的计费和审计一致性。在事件体系结构上构建它，根据角色给出上下文，添加符文和升级-并且您将获得可预测的操作，快速的解决方案和稳定的增长。