4、延迟（Latency）信号详解
延迟是衡量系统响应速度的核心指标，直接反映服务处理请求所花费的时间。在 Golden Signals 中，延迟不仅是性能的晴雨表，更是故障定位中最早暴露问题的信号之一。本节将深入解析延迟的定义、成功与失败请求的差异化分析，以及高延迟对用户体验的量化影响。
4.1 延迟的定义与测量维度
延迟通常定义为从客户端发出请求到收到完整响应所经过的时间。在服务端视角，延迟包括网络传输、队列等待、业务逻辑处理、I/O 操作等环节。常见的测量维度如下：
| 维度 | 说明 | 典型测量点 |
|---|---|---|
| 端到端延迟 | 客户端发出请求到收到响应的总耗时 | 浏览器、移动端 SDK |
| 服务端延迟 | 请求到达服务网关到响应离开的时间 | API Gateway、反向代理 |
| 数据库延迟 | 数据库查询或写入操作的耗时 | 数据库中间件、慢查询日志 |
| 网络延迟 | 数据包在网络中传输的往返时间 | ping、traceroute、eBPF |
实践要点：在 SRE 监控中，建议同时采集 p50、p90、p99 分位延迟，而非仅关注平均值。平均值容易掩盖尾部延迟问题，而 p99 能更真实地反映最差体验。
4.2 成功请求与失败请求的延迟区分
许多监控系统将成功与失败请求的延迟混在一起统计，这会导致严重的误导。例如，当服务返回 500 错误时，响应可能非常快（几毫秒），但用户实际并未获得正确服务。因此，必须将两类延迟分开分析。
关键结论：成功请求的延迟反映系统真实性能；失败请求的延迟往往偏短，但大量快速失败会拉低整体延迟，造成“系统性能良好”的假象。SRE 必须将两类延迟分开监控，并分别设置告警阈值。
4.3 高延迟对用户体验的影响
延迟对用户体验的影响并非线性，而是呈现明显的阈值效应。以下是业界公认的延迟与用户体验对应关系：
| 延迟范围 | 用户感知 | 业务影响 |
|---|---|---|
| 0 – 100ms | 即时响应，无感知 | 用户保持专注，转化率正常 |
| 100 – 300ms | 轻微延迟，可接受 | 部分用户开始注意，但通常不流失 |
| 300 – 1000ms | 明显等待，体验下降 | 用户耐心降低，跳出率上升 10-20% |
| 1 – 3s | 长时间等待，烦躁 | 跳出率可达 30-50%，品牌信任受损 |
| > 3s | 不可接受，放弃操作 | 大部分用户流失，业务收入显著下降 |
注意：移动端用户对延迟更敏感。在弱网环境下，300ms 的延迟可能已经导致用户放弃操作。建议针对不同网络类型（WiFi、4G、5G）分别采集延迟数据。
4.4 延迟故障定位实战要点
当延迟信号出现异常时，SRE 需要快速定位瓶颈。以下是基于延迟的故障排查步骤：
- 确认延迟范围：查看 p50、p90、p99 分位延迟，判断是整体升高还是尾部恶化。
- 区分成功/失败：分别查看成功请求与失败请求的延迟曲线，排除快速失败干扰。
- 分层下钻：从客户端 → 网关 → 应用 → 数据库逐层分析，定位延迟最高的环节。
- 关联资源指标：检查 CPU、内存、磁盘 I/O、网络带宽是否成为瓶颈。
- 检查依赖服务：外部 API、缓存、消息队列等依赖是否出现延迟抖动。
实战技巧：在应用层注入分布式追踪 ID（如 OpenTelemetry），将一次请求的完整链路延迟拆解为各子模块耗时。当 p99 延迟飙升时，通过追踪系统快速定位是哪个模块贡献了最多的延迟增量。
4.5 延迟告警策略建议
基于延迟的告警应避免单一阈值，推荐使用多维度组合策略：
- 分位告警：p99 延迟超过基线 2 倍时触发告警，p50 延迟超过基线 3 倍时触发告警。
- 成功/失败分离告警：成功请求 p99 延迟超过 500ms 告警；失败请求占比超过 5% 且延迟异常时告警。
- 趋势告警：延迟在 5 分钟内持续上升超过 30% 时触发，避免瞬时抖动干扰。
- 业务维度告警：针对核心 API（如登录、下单、支付）设置更严格的延迟阈值。