业务和管理→审计指标和SLA

审核指标和SLA

1）为什么需要它

如果指标不正确-解决方案不正确，则SLA将"在纸上"被打破，反之亦然地隐藏问题。度量和SLA审核可确保对用户和合作伙伴的承诺的可比性，可信性和法律安全性。

• 提供单一的"真相来源"（SSOT）和可重现的计算。
• 减少行车记录/报告/计费之间的差异。
• 使SLA可行且可验证（基于evidence）。
• 在测量中检测降解的时间与服务中的降解时间一样早。

2）责任的基本概念和界限

度量（度量）：可测量的量（RPS，p95，CR，GGR，成功率）。
KPI/OKR：指标绑定的目标。
SLO：目标服务质量（例如"p99 ≤ 400 ms 99"。9％的时间"）。
SLA：外部承诺；具有法律意义,基于SLO。
OLA：团队/供应商之间的内部协议，支持SLA。
SSOT：其数据被视为报告参考的系统/存储。

3）分类学指标（层）

1.基础架构：CPU/Memory/IO/Net，Pod/节点，HPA/VPA。
2.平台：队列/流（lag，throughput），DB/缓存（连接，命中），API（p95/p99，5xx）。
3.业务流：存款/收款,投注,游戏启动,授权,KYC。
4.产品/营销：转换，ARPPU/LTV，广告系列。
5.流程质量：MTTA/MTTR,更改故障率,清单覆盖。

规则：每个度量必须具有层，所有者和公式。

4）数据来源和"真相"

在线电视计量学：Prometheus/OTel，logi（ELK/ClickHouse），跟踪。
活动和会计：Kafka/Outbox，DWH/日期发布会（BigQuery/ClickHouse）。
手工制品：验尸、滴答作响、事件登记册。
外部注册：提供商报告（PSP/KYC/工作室），计费。

冲突解决方案：对于"Online vs DWH"的差异，有优先权规定（例如，对于SLA，来自DWH的聚合具有源跟踪性）。

5）度量审计过程（管理轮廓）

1.清单：指标目录/SLO/SLA（名称，所有者，层，公式，来源，计算频率）。
2.公式验证：将SQL/prom查询与定义（单位计算测试）进行对账。
3.采样和重新排序：抽样事件/日志行和手动对账。
4.轮廓映射：比较在线行车记录和DWH报告。
5.更改控制：在电路/逻辑发布时通过公式的评论。
6.SLA审核：验证装配和异常是否正确（计划维护、不可抗力）。
7.报告和改进：发现的差异和截止日小说的列表。

6）定义和公式（样本）

Success Rate (API):

`success = requests - (5xx + timeouts + circuit_open)`

`success_rate = success / requests`

Latency p95/p99:

SSOT包含一个窗口定义（滚动5m/1h）和聚合定义（HDR/TDigest）。

• "SLO_availability_month=（时间_工作是有效的_例外）/一般_时间"

• `SLA_month = 99.UTC窗口上有90％的药房，不包括计划窗口（T-48通知），可证明的过境运营商事故（文件）"

7）数据质量： 验证和异同

• Полнота (completeness): `received_events / expected_events ≥ 0.99`.
• 及时（时效）：加载时差≤ N分钟。
• 唯一性（uniqueness）：不使用按键（idempotency-key）。
• 一致性（一致性）：金额/货币/符号。
• 线性（monotonicity）-计数器不会"回滚"。

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8）SLA/OLA审计： 方法

1.收集例外日历：计划窗口、商定的降级、供应商行为。
2.Uptime计算：通过一个时间区,依靠SSOT。
3.事件核对：时间线、门票、验尸。

4.归因： 自身故障,提供商,过境,DDoS,管理工作.

5.SLA外围：用户体验（E2E） vs一个特定的API。
6.报告：月份/季度报告：事实、拒绝、赔偿（如适用）、纠正措施。

9）验证计算的可重复性

公式验证：具有SQL/PromQL/基座规范的 Git存储库。
单位度量测试：在合成数据上（边缘桉例：跳过、双打、日期边界）。
数据线：从行车记录仪回到源表和事件。
Snapshots：将数据冻结到截止点，以便笔计算可比。

10）控制样本（采样）

每天：按关键流（押金/利率/KUS）进行10-20个事件-手动跟踪对账↔ DWH。
每周：1％的样本用于比较"Online vs DWH"。
每月：一组SLA效应事件-详细重建。

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11）审核行车记录和警报

单一度量词典：直接在行车记录仪上的词汇表。
版本/活动注释：查看偏差的原因。
发布前/发布后比较：自动回归面板。
双重/差异：识别"两个不同的p99"-编辑公式/窗口。
面板可用性：权限、备份、链接/版本控制。

12）指标变更管理

RFC过程：更改公式/窗口/源-通过RFC评估对SLA/报告的影响。
迁移"expand → migrate → contract"：暂时运行两个版本，我们进行比较，然后关闭旧版本。
通信："通过新方法"提前通知产品/企业值变化。

13） iGaming/fintech的细节

需求峰值：度量必须承受爆炸载荷（聚集不是"扎根"）。
提供商：SLA依赖供应商的OLA →保留其报告，事件状态和配额。
成本："cost_per_1k_calls"和"成功成本"是必备的面板。
防冻风险：对延迟和"误报"指标的敏感性。

14） Dashbords审计（最低设置）

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.

SLO/SLA Evidence：计算的SLO，实际的SLA，例外，事件/行为引用。
Online vs DWH Compare：p95/p99/Success率、偏差和趋势。
Vendor SLA：按供应商划分的药房/配额/超时/成本。
Release Impact：放置/打开幻灯片后的指标回归。

15）审计支票清单（运营）

• 具有所有者和公式的指标/SLO/SLA目录是相关的。
• SSOT是为每个报告/面板定义的。
• 公式的统一测试是绿色的，计算的管道已记录下来。
• 对数据质量的Alerta是活跃的（完整性/时效性/双重性）。
• "Online vs DWH" ≤允许阈值的差异（例如≤2％）。
• 统一的SLA豁免已记录下来，并附在报告中。
• 进行了检查抽样并确定了行为。
• 所有公式更改均通过RFC和迁移。

16）示例（片段）

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17）反模式

不同面板上两个不同的"相同"度量公式。
更改未迁移和通知的度量标准是OKR/SLA中的"跳跃"。
本地Excel中的报告为"真相"（不可复制）。
SLA计算中时区和日历的混合。
SLA例外没有记录在案。
测量质量没有差异。

18）测量成熟度KPI

漂移率Online↔DWH（目标≤2％）。
Metrics Health Uptime（没有最大/ETL降解的时间）。
时间到修复公式（解决公式错误的时间）。
SLA Dispute Rate（与合作伙伴发生有争议案件的频率）。
Coverage SLO/SLA（正式描述为SLO/SLA的关键路径比例）。

19）角色和责任

度量/服务的所有者：公式，来源，dashbord，alertes。
Observability/SRE：SSOT/平台，公式测试，数据质量差异。
数据/BI： DWH,报告可重现性,lineage。
律师/合伙人经理：SLA安排和例外。
事件经理：与SLA的事件归因和捆绑。

20）快速启动（30天）

第一周：度量清单/SLO/SLA和所有者；指定SSOT。
第二周：包括数据质量差异和"Online vs DWH"面板。
第3周：进行控制抽样，平整p95/p99的视线。
第4周：将公式的RFC过程正式化，编写带有应用程序的月度SLA报告。

21) FAQ

Q： SSOT对于SLA算什么?

A：可重复计算存储（DWH）和全线存储；在线面板-用于操作控制,不用于法律行为。

问：如何对抗"两个p99"？
答：将窗口/聚合方法锁定在度量目录中,迁移面板,在漂移中添加警报。

问：如何考虑计划工作？
答：维护例外日历，并根据合同规则自动从SLA中减去它们；储存确认文物。