操作和管理→性能指标

性能指标

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），您可以管理体验的质量和交付成本-可预测且可扩展。