3. 延迟诊断核心指标：P50/P90/P99延迟、平均延迟、错误率与吞吐量

在多团队协作的云原生网关延迟诊断场景中，仅凭“慢”或“快”的感性描述无法定位根因。必须建立一套统一的、可量化的核心指标体系，作为火焰图交接与跨团队沟通的“通用语言”。本节将定义延迟诊断的五大核心指标，并阐明其在多团队协作中的实际意义。

3.1 指标全景：从统计到业务

延迟诊断指标可分为统计延迟指标与业务健康指标两大类。前者描述请求的响应时间分布，后者反映系统的整体负载与可用性。

3.2 指标深度解析与火焰图关联

3.2.1 统计延迟：P50、P90、P99 与平均延迟

这四个指标共同构成了延迟分布的“四象限”视图。在多团队协作中，不同角色关注的重点不同：

• SRE 团队：关注 P99 延迟与 SLO 合规性，当 P99 突破阈值时触发告警。
• 业务开发团队：关注 P50 延迟，确保核心业务接口的“典型体验”达标。
• 基础架构团队：关注 P90 延迟，评估网络、DNS、负载均衡等基础设施的稳定性。
• 平均延迟：仅用于宏观趋势监控，不作为根因分析的依据。

火焰图分析时，应优先选择 P99 延迟区间的请求进行采样。因为 P99 请求往往包含了最深的调用栈和最复杂的资源竞争，是发现隐藏性能瓶颈的最佳切入点。

3.2.2 错误率：延迟诊断的“过滤器”

错误率是延迟诊断中容易被忽视但至关重要的指标。高错误率会导致延迟统计失真：

• 快速失败：某些错误（如 503、超时）可能在极短时间内返回，拉低平均延迟，掩盖真实慢请求。
• 重试风暴：客户端重试会人为增加吞吐量并抬高延迟，导致指标“虚高”。

3.2.3 吞吐量：延迟的“放大器”

吞吐量（RPS/QPS）与延迟通常呈正相关。当吞吐量接近系统瓶颈时，延迟会非线性增长。在多团队协作中，吞吐量指标用于区分：

• 负载型延迟：吞吐量上升导致延迟增加，需要扩容或限流。
• 代码型延迟：吞吐量不变但延迟突增，需要排查代码逻辑或依赖服务。

3.3 核心指标与火焰图交接的映射关系

下图展示了在多团队协作的火焰图交接流程中，各核心指标如何被采集、关联并用于根因定位：

3.4 指标选择原则与协作规范

在多团队协作中，为避免指标理解偏差，建议遵循以下原则：

1. 统一分位定义：所有团队使用相同的分位计算方式（如 T-Digest 或 HDR Histogram），避免因算法差异导致指标不一致。
2. 固定时间窗口：火焰图交接时，必须明确标注指标的时间窗口（如“过去 5 分钟 P99 延迟”），防止因窗口不同引发争论。
3. 错误率前置过滤：在生成火焰图之前，先过滤掉错误请求（HTTP 5xx、超时等），确保火焰图仅反映“成功但慢”的请求。
4. 吞吐量基线：每个团队应建立自身服务的吞吐量基线，当延迟异常时，首先判断吞吐量是否超出基线范围。

3.5 指标异常场景与应对策略

下表总结了常见的指标异常模式及其对应的多团队协作应对策略：