题目重点：从用户症状与可证伪假设进入排查，用切片、关联链和对照验证避免在平均指标正常时过早结案。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 这是本人经历题，不是要求现场诊断一个给定系统；题目没有实际故障数据。
- 故障根因须区分触发条件、放大因素与检测缺口；恢复服务和确认根因可以不同时间完成。
- 下面缓存例为训练情境，不冒充真实面经的候选人事故。
解题路线
- 先量化可观察症状：哪些用户、何时、频率、错误表现与业务影响。指标全绿只说明已有监控未捕获，不能据此否定用户报告。先采取安全止损措施，再诊断。
- 列可证伪假设，例如某版本、区域、租户、输入大小或重试路径。将平均值拆为尾延迟、错误类型和小群体，使用request/correlation id串联日志trace，但控制采样与敏感数据。
- 说清第一假设与排除证据：某组件看起来相关但对照样本同样有该信号。保持时间线，把相关性与因果验证分开，避免在多个团队间凭感觉转工单。
- 重现最小条件或做安全回放/对照试验，定位导致症状的代码/配置/资源路径。修复后用触发样本和独立正常样本验证，不仅看总体错误率下降。
- 报告发现、临时恢复和永久修复分别用了多久，说明本人决策及他人协助。补监控覆盖、回归用例和runbook，使同类问题下次更早被发现。
手动走一遍
虚构训练例平均请求延迟正常，但旧版本少数客户在缓存失效时失败。按客户端版本和缓存miss切片后发现问题集中在这条路径，回放复现边界字段为空，排除初始网络假设；修复后检验旧版回放与正常请求，并新增该切片错误告警。
规模与取舍
非算法题。至少两项假设、一个反证、一个最小复现/对照、时间线和检测机制改进；只报‘看日志发现bug’没有Dive Deep证据。排查成本用事故时长、样本量和影响面表述。
易错点与追问
容易失分的边界
- 只看平均值与全局成功率。
- 把相关日志当根因，没有复现/对照。
- 只讲最终正确判断，省略初始错误假设。
- 有修复但没有补监控与回归。
继续深挖
- 日志采样漏了故障请求怎么办？
- 怎样知道关注的是正确组件？
- 为什么原指标没有报警？
- 重做时哪个排查动作应更早？
