操作和管理→性能指標

性能指標

1）為什麼需要性能指標

• 在事件發生前發現退化，
• 預測能力和預算，
• 比較替代解決方案（緩存vs DB，gRPC vs REST），
• 管理發布後的回歸。

原則：單一度量詞典，按筆錄匯總（p50/p90/p95/p99），「熱」和「冷」路徑的單獨計算，上下文（版本，區域，提供商，設備）。

2）分類學指標

2.1基本的SRE框架

四個金信號是：Latency，Traffic，Errors，Saturation。
RED（用於微服務）：Rate, Errors, Duration。

USE（用於鐵）： Utilization, Saturation, Errors.

2.2個級別

基礎架構：CPU，RAM，驅動器，網絡，容器，節點。
平臺/服務：API結束、隊列、緩存、DB、事件總線。
客戶體驗：Web Vitals，移動SDK，流媒體，CDN。
數據平臺：ETL/ELT，流，店面，BI延遲。
業務關鍵漏洞：授權，KYC，存款/付款，遊戲回合。

3）關鍵指標和公式目錄

3.1個API和微服務

RPS (Requests per second).

Latency p50/p95/p99（ms）-最好是「端到端」和「僅後端」。
Error Rate（%）=5xx+驗證的4xx/所有查詢。
Aturation：平均用戶隊列長度,「飛行中」查詢。
冷啟動率（適用於FaaS）。

Throttling/Dropped Requests.

SLO示例： 在歐盟-東部地區，RPS為2k的p95 latency ≤ 250 ms；錯誤≤ 0。5%.

3.2個數據庫

QPS/Transactions/s, avg/median query time, p95 query time.

Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.

RepLag（復制），Checkpoint/Flush時間，Autovacuum lag。
Hot Keys/Skew在負載方面排名前N。

內核查詢公式：QPS/ vCPU_core_count →信號進行緩和。

3.3緩存和CDN

Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.

Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.

3.4隊列/流

Ingress/egress msg/s, Consumer Lag（消息/時間）,Rebalance rate。

Processing Time p95, DLQ Rate.

3.5基礎設施/集裝箱

CPU Utilization %, CPU Throttle %, Run Queue length.

Memory RSS/Working Set, OOM kills, Page Faults.

Disk IOPS/Latency/Throughput, Network RTT/ retransmits.

Node Saturation: pods pending, pressure (CPU/Memory/IO).

3.6 Web客戶端（UX）

Core Web Vitals: LCP, INP, CLS.

TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).

Error Rate (JS), Long Tasks, SPA route change time.

CDN Geo-Latency（胡椒粉）。

3.7移動客戶

App Start time (cold/warm), ANR rate, Crash-free sessions %.

Network round-trips/session, Payload size, Battery drain/session.

離線成功率（腰帶操作）。

3.8數據平臺和報告

Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.

Cost per TB處理,Skew按批次處理,Late events%。
BI Time-to-Render p95用於關鍵行車記錄儀。

3.9域臨界浮動（iGaming為例）

Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.

Game Round Duration p95, RNG call latency, Provider RTT p95.

Payment PSP success rate, Chargeback investigation SLA.

4）正常化，滲透和歸屬

Percentili與平均值：固定p50/p90/p95/p99-平均值消除峰值疼痛。
切口：應用程序版本、區域、提供商、網絡通道（4G/Wi-Fi）、設備。
相關：我們鏈接因果鏈的「僅後端」和「real-user」度量。
Exemplars/Traces：將極端感應與追蹤聯系起來。

5）急流和急流（大致網格）

Latency p95 （core API）：警告>250 ms, critical> 400 ms 5 mins連續。
Error rate: warning > 0.5%, critical> 2%（非全球）。

DB RepLag: warning > 2 s, critical > 10 s.

Kafka consumer lag (time): warning > 30 s, critical > 2 min.

Web LCP (p75): warning > 2.5 s, critical > 4 s.

Mobile ANR: warning > 0.5%, critical > 1%.

ETL Freshness: warning > +15 min, critical > +60 min от SLA.

使用靜態+自適應閾值（季節性、白天模式）、重復數據消除和按服務/發行版分組差異。

6）性能測試

類型：基線，壓力，長時間（肥皂），混亂（degrade links/PSP）。
負載配置文件：通過真實的步道（基於分配），「bursts」，區域高峰。
目標：通過目標RPS和混合操作實現SLO，驗證後壓。
運行度量：Throughput、Error%、p95 latency、GC暫停、CPU throttle、queue lag、cost/run。

回歸規則：如果p95在同等配置文件下未降級>10%,並且請求成本（CPU-ms/查詢）未升高>15%,則該發布被認為是成功的。

7）容量規劃和價格/性能

點播模型：按小時排列的RPS ×平均操作/查詢（CPU-ms，IO-ops）。
Headroom：關鍵路徑的30-50%庫存，P95自動計分。
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p.p.LCP改進。
緩存/非歸一化：計數「cache ROI」=（CPU-ms節省−緩存成本）。
溫暖和寒冷的地區：在CDN/edge中脫載，復制「僅讀」。

8）可觀察性和分析實踐

跟蹤：通過所有流行音樂分布的trace-ID；采樣聰明（基於尾巴）。
度量標準：Prometheus/OpenTelemetry，名稱和標簽的統一表示法。
Logs：與trace/span相關聯,budget by log噪音,編輯PII。
分析儀：CPU/Heap/Alloc/Lock profiles,連續分析（eBPF）。
示例實例：將p99爆發鏈接到特定的span/SQL/PSP coll。

9）發布和命令的度量（完整性）

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.

SPACE：滿意度、性能、活動、溝通、效率。
這些指標不是關於鐵，而是直接影響性能的可持續性。

10）反模式

追逐中等：忽略p95/p99。
「全球」錯誤率：隱藏痛苦的殘局。
沒有歸因於版本：無法捕獲客戶端回歸。
Alert垃圾郵件：沒有滯後和季節性糾正的閾值。
「盲目」優化：不進行剖析和跟蹤。
UX和後端後端的混合：對客戶體驗的錯誤推斷。

11）支票單

統一度量標準

• 公式、單位、所有者的度量詞典
• 強制性percentiles p50/p90/p95/p99
• Trace相關和日誌相關性
• 標簽：區域、版本、提供商、設備、網絡通道
• 磁滯和重復數據消除閾值

發布前

• Baseline p95/p99在牛排和銷售上
• 金絲雀流量+A/B指標比較
• 快速回滾的Ficha標誌
• 監視計劃（監視運行圖）

定期

• 最慢的前N 查詢/SQL咆哮
• 審核緩存策略和TTL
• 驗證新生和DB復制
• 外部提供商（PSP, KYC）降解測試)

12）迷你花花公子（示例）

p95/api/payments降解

1.檢查錯誤百分比和外部PSP計時器。
2.檢查collbeck隊列的消費者。

3.查看p99示例的跟蹤： SQL/HTTP瓶頸?

4.啟用參考/限制緩存,降低N+1。
5.預算：暫時將采購商資源提高20%，包括自動售貨機。
6.後修復：索引（psp_id，status，created_at)，retrai-jitter。

RepLag在DB中的增長

1.檢查「繁重」請求和長期交易。
2.增加復制並行性,調節checkpoint。
3.將讀取負載移至緩存/副本僅讀取。
4.在峰值窗口中，是部分denorm+batchi。

13） 公式/SQL示例（簡化）

按殘局計算的錯誤率

sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;

Latency p95 (TDigest/Approx)

sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;

消費者Lag（時間）

sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;

Web LCP p75

sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;

14）嵌入行車記錄儀和報告

KPI卡：p95 latency, error%, RPS, saturation with WoW/DoD趨勢。
前N「最差」endpoint/SQL/resource，點擊式驅動→跟蹤。
客戶端版本相關性：圖形「p95 l → CP/INP版本→轉換」。
世界地圖：geo-latency（CDN），PSP latency按地區。
SLO面板：SLO的時間份額，SLO的離職，「錯誤預算」。

15）結果

性能指標是系統學科：單一字典，筆記，歸屬，良好的可觀察性和嚴格的SLO。結合技術（潛在性，滯後，kesh-hits）和產品信號（KYC時間，p95存款，LCP），您可以管理體驗的質量和交付成本-可預測且可擴展。