面试官说：“订单页面开始变慢，但错误率没涨。你当班，接下来怎么看？”这类题在考查能否界定影响、选择证据和做可恢复的决策。Google SRE 的监控章节讨论延迟、流量、错误和饱和度。OpenTelemetry 的文档把一次请求中的操作表示为可关联的 span。两类材料一大一小，能分别回答多少请求受影响和某一条请求在哪里等了很久。 Google SRE 监控章节 · OpenTelemetry Traces
先从用户动作定义影响
在模拟场景里，用户需要打开订单详情。过去五分钟内，订单详情接口的 P95 延迟从 280 毫秒升到 1.8 秒，错误率保持在原来的水平。面试里先问数据来自前端、网关还是下游。网关看到成功响应，用户仍可能因等待太久主动关闭页面。前端收到请求前也可能在加载脚本，若前端等待变长而网关延迟稳定，排查方向就不同。
确认异常从什么时候开始、集中在全部订单还是某个类别、发生在一个地区还是多个地区。避免先把所有服务都标成故障。可以向面试官说明你会查看订单详情的实际请求量、用户可见错误和延迟分布，再与近期基线比较。对于低流量路由，先看样本数。两条慢请求足以提示继续观察，却不等同于大量用户同时遭遇问题。
给同一时间窗配齐四类信息
| 信号 | 模拟观察 | 下一步 |
|---|---|---|
| 延迟 | P50 变化小，P95 明显上升 | 分订单类型与地区 |
| 流量 | 请求总量没有明显变化 | 查流量是否从某类请求移到另一类 |
| 错误 | HTTP 失败率稳定 | 看客户端超时、取消和慢成功 |
| 饱和度 | 数据库连接池接近上限 | 核对排队、查询耗时和连接占用 |
把四项拉到同一时区和相同的采样粒度。异常开始时间若接近某次部署，记录关联，但先核对是否只有新版本接收到慢请求。如果某类大订单碰巧集中在当时，同样可能改变延迟分布。拿上一个同等流量时段作对照，看看当时的连接池和订单类型分布。这个步骤让后续回滚决定有比“刚刚发过版”更具体的理由。
用调用链提出可证伪的猜测
设想慢链里网关 1.8 秒，订单服务 1.7 秒，库存查询本身 100 毫秒，等待连接约 1.4 秒。另一条快链同样访问库存，等待不到 20 毫秒。可以提出“等待连接是该样本的主要时间消耗”，再去看更多同类样本和连接指标。需要确认慢链是否被单独采样，平均连接占用能否解释突发等待，以及等待发生在连接池、网络握手还是其他步骤。
在面试里可以说你会用请求标识对照日志，查该时间窗内是否有超时、异常释放或重试。若链路没有覆盖某个依赖，说明那里还是未知。你可以考虑补一个只记录耗时和结果类别的 span，在受控环境复现；生产日志中避免把认证信息、完整订单号或客户数据写入。仅靠一个字段缺失也不能推断调用根本没发生，先核对采集覆盖。
恢复动作要跟着实际影响走
若已确认只有带新功能的请求会占住连接，团队可以先把该功能从一小部分流量撤下，验证延迟和积压是否下降。若等待来自共享资源耗尽，可以临时降低低优先级批任务的并发，给用户请求腾出连接，再看上下游指标。服务依赖共享数据库时，把连接池调得更大有可能把压力转给数据库，需要先明确资源上限。急于重启实例也可能让排队中的请求重试，引发更大的突发流量。
面试官问何时通知他人，可以给出一条接地气的回答。影响已经确认、需要协调数据库或产品侧暂停一项功能时，及时报出时间窗、受影响流程、目前证据和下次更新时间。团队应知道你正在尝试什么，以及如果动作失败如何撤回。可见的用户降级也要和业务团队对齐，例如仅暂缓展示次要信息，并明确用户仍可查看核心订单状态。
用恢复验证说明故障是否真的结束
假设暂停批任务后 P95 回到 330 毫秒，连接池等待也下降。接着看失败、取消、积压和受影响订单类型，确认问题没有被迁移到另一个地区。若统计流程被暂停，补跑前先检查工作量和阈值，避免在服务刚恢复时重新把资源用满。可以观察一个与正常业务周期相符的时段，再按团队约定结束事件。写复盘时列出触发、影响范围、证据和追踪项，给每项改进指定验证方式。
练习时可以做一个只有三个服务的小程序，手工加延迟或限制资源。记录故障前后同样的请求，分别比较中位和较慢的一组，再用一条链路证实等待位置。面试讲案例时，解释为什么先确认影响、又是哪个对照改变了你打算采取的措施。一个能复现的微型场景足以练习沟通，不需要把本地程序称作大规模线上系统。
延迟排查还要留意没有进入样本的请求
假设客服举例的两个用户，都在页面显示成功前关闭了浏览器。网关日志里也许仍能看到成功的 200，因为后端最终生成了结果；客户端却已经取消等待。要先按同一个操作定义“成功”。比如浏览器提交请求并在两秒内看到可用的订单内容，才算达成体验目标。服务端和前端都可以分别统计，尽量通过允许记录的关联标识判断二者差别。若只能在服务器侧测量，就说明暂时只知道系统响应，用户是否看到仍需补证据。
如果面试官只给你平均延迟，向他要一组有代表性的样本。比如五条分别为 100、110、120、130 和 1,900 毫秒。均值为 472 毫秒，中位数为 120 毫秒，已经可以看见有一个明显慢样本。小样本不适合估一个稳定的高分位值。实际线上用足够数据计算分位数，并按地区、接口和版本对照。阅读工具预设图表时，确认聚合方法，别把各实例的 P95 简单平均就当成全体请求的 P95。
给接班同事留下三条可以执行的信息
模拟值班交接时可以说：“从十点零三分起，订单详情的一类请求变慢，未见明确错误率上升。已比对两条调用链，较慢的一条主要在等待连接，正在查批任务启动时间。若连接等待继续高于约定值，请先确认低优先级任务能否暂停，恢复后重跑固定请求并观察用户取消情况。”这段信息同时有影响、证据和下一步，还保留了原因尚需核实的空间。
让同学扮演接班人追问两个问题。第一，是否已排除数据库本身变慢？你可以说在示例链里实际查询耗时较短，还会看数据库指标与更大样本。第二，怎样避免告警每天重复？可以考虑同时要求较长等待持续一段窗口，并将告警指向受影响的用户操作。避免给自己定一个脱离业务的固定阈值，阈值来自团队愿意接受的响应和耗时目标。最后用一次恢复测试接回第一个问题，说明哪些现象已经消失。
交接记录最好附上查询窗口、影响范围和样本时间，让下一班的人可以用相同方式复核现状。
常见问题（FAQ）
P95 变慢就说明所有人都受影响吗？
它反映一定比例的观测边界。结合流量、时段、请求类型、地域和成功率才能界定影响。
有调用链还需要日志和指标吗？
指标帮助定位规模和时间窗，调用链帮助观察请求路径，日志能补充具体状态。三者可以交叉验证。
要直接重启服务吗？
先确认影响、可逆措施和系统会怎样恢复。重启可能清除现场或加剧积压，应依据证据和团队流程。
- Monitoring Distributed Systems· Google SRE
- Traces· OpenTelemetry
选择你了解的服务，画出依赖关系并准备一组指标、调用链和恢复验证。