线上问题排查实战与面试
目标：线上出问题知道先看哪，能把「指标 / 日志 / 链路」讲成人话，不背名词表。
面试高频问法
- 线上接口变慢，你怎么排查？
- 服务 CPU/内存打满怎么查？
- 你们监控看哪些核心指标？告警怎么做？
- 日志一般看什么字段？会不会把敏感信息打进日志？
- 有没有做过一次真实故障复盘？
口述参考（短版）
排查顺序（实用版）：
- 先确认范围：单个用户 / 单个接口 / 全站？从什么时间开始？
- 看可用性：服务是否存活、实例是否重启、部署是否刚好发生
- 看黄金信号：延迟、流量（QPS）、错误率、饱和度（CPU/内存/连接数）
- 看日志：错误堆栈、慢 SQL、超时、依赖调用失败
- 再下钻：线程、GC、DB、Redis、下游超时
可观测三件套（人话）：
- 指标：现在快不快、错不多、资源紧不紧
- 日志：具体报了什么错
- 链路追踪（有的话）：慢在哪一跳
面试有 Prometheus/Grafana/ELK 经验就点名；没有就强调排查思路，比堆产品名重要。
实战：一套最小可用监控心智
应用最少要暴露的感觉
- 接口 QPS、P95/P99 耗时、5xx 比例
- JVM：堆内存、GC 次数/耗时（Java 岗很常见）
- 依赖：DB/Redis 连接、超时次数
日志最少规范
- 带
traceId/requestId（没有也要说「应该有」） - 错误打堆栈，但密码、token、身份证不要明文
- 关键路径单独关键字，方便 grep
告警最少原则
- 告警要能行动：不是「CPU 高了」就完，要知道找谁、先看哪
- 先保命：服务挂、错误率飙升、磁盘满
- 避免告警风暴：合并、降噪、分级
一道题练口述：接口突然变慢
可以这样答：
先确认是否刚发版、是否个别接口。然后看该接口耗时和错误率，再看 DB/Redis 耗时。若是慢 SQL 就 explain 和索引；若是下游超时就看依赖和线程是否打满；同时用日志定位具体异常。处理完会补监控项和告警，避免同样问题第二次才发现。
结合你简历怎么讲
业务系统 / MES 现场交付可以说：
联调和上线后更关注服务是否稳定、接口是否超时、采集链路是否中断。问题一般从日志和资源占用入手，先恢复再复盘。
有大盘/告警经验再补工具名；没有就别硬编完整 ELK 体系。
常见坑
- 只看 CPU，不看错误率和依赖耗时
- 日志巨多但没有 requestId，无法串一次请求
- 告警太多没人理 = 等于没告警
自测清单
- [ ] 能按顺序说：范围 → 存活 → 黄金信号 → 日志 → 下钻
- [ ] 能举一个自己排查过的慢接口/发版问题
- [ ] 知道日志里不该打什么
- [ ] 能说出 3～5 个你认为必须盯的指标