業務和管理→審計指標和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中減去它們；儲存確認文物。