线上出过什么问题？怎么排查和修复的
1️⃣ 考察意图
面试官想看你是否具备系统化的故障排查能力，而非只靠“重启大法”或“拍脑袋”解决。这道题考察的是实战经验与工程思维：能否清晰描述一个具体线上问题（如响应时间从200ms飙升至5s），并展示从监控、定位、根因分析到修复、复盘的整条链路完整流程。刁钻点在于：你是否能区分“症状”和“根因”，比如流量突增是症状，连接池耗尽才是根因。答好了，能展示你的故障响应速度、系统化排查流程、以及长期改进意识，这是大厂P6+的核心素质。
2️⃣ 标准答
问题描述：某RAG系统线上故障，用户反馈答案质量骤降，检索结果出现大量无关内容。监控显示，某时段P99响应时间从200ms飙升至5s，同时错误日志中“Invalid vector dimension”报错激增。
排查过程（系统化流程）：
- 第一步：监控大盘快速定位。先看Grafana大盘，CPU和内存正常，但QPS从1000突增到3000，同时数据库连接池使用率从30%飙到95%。这提示可能是流量冲击或资源瓶颈。
- 第二步：链路追踪缩小范围。用Jaeger追踪请求，发现耗时主要卡在Embedding服务，平均推理时间从50ms增加到2s。同时，日志中频繁出现“Embedding model version mismatch”警告。
- 第三步：日志与版本对比。查看最近一次模型部署记录，发现运维在凌晨4点升级了Embedding模型（从
text-embedding-ada-002切换到text-embedding-3-small），但未同步更新向量数据库的索引维度（从1536维变为3072维）。这导致检索时维度不匹配，所有向量距离计算失效，返回随机结果。
根因定位：模型版本升级未做兼容性验证。新模型输出维度变化，但向量数据库（Milvus）的索引schema未更新，且没有自动化测试检测维度一致性。同时，流量突增（可能由新功能上线引发）放大了问题，因为每次请求都触发错误重试，进一步耗尽连接池。
修复措施（分紧急和长期）：
- 紧急修复：立即回滚Embedding模型到旧版本（
text-embedding-ada-002），耗时5分钟，服务恢复。同时，扩容数据库连接池（从50到200）以消化积压请求。 - 短期优化：在模型部署流水线中加入维度一致性检查脚本，每次新模型上线前自动比对向量维度，不一致则阻断部署。同时，增加版本号校验，请求中携带模型版本，服务端拒绝不匹配的请求。
- 长期改进：引入金丝雀发布，新模型先灰度5%流量，监控检索准确率（Recall@10）和响应时间，稳定后再全量。此外，建立压测机制，用Locust模拟峰值流量，确保系统能扛住3倍QPS。
实际落地的坑：回滚后，发现旧模型缓存了错误向量，导致部分用户仍看到乱码。解法是清除缓存并重建索引，用milvus compact命令合并段文件，耗时30分钟。这提醒我：故障修复不能只停服务，还要清理脏数据。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，问题描述——某RAG系统因Embedding模型升级导致向量维度变化，检索结果全错，P99响应时间飙升至5s。第二，排查过程——先看监控大盘定位到连接池耗尽，再用Jaeger追踪到Embedding服务耗时异常，最后对比日志发现模型版本不兼容。第三，修复与改进——紧急回滚并扩容，长期加入维度校验、金丝雀发布和压测。总结一句：线上问题排查的核心是‘症状-根因-修复-复盘’的完整流程，而预防比修复更重要。”
4️⃣ 高频追问 & 应对
追问 1：如果回滚后问题依然存在，你怎么进一步排查？
首先检查回滚是否彻底：确认旧模型镜像已完全替换，且缓存未污染。如果问题仍在，可能是数据层问题：比如向量数据库的索引损坏。我会用
milvus query检查索引状态，并用milvus rebuild_index重建。如果还不行，考虑网络层面：用tcpdump抓包看是否有丢包或延迟，或者检查DNS解析是否指向了错误的服务实例。最后，如果所有手段都无效，我会回滚到更早的版本（比如前一天的快照），并启动全量数据恢复。
追问 2：如何设计一个自动化测试来防止类似问题？
核心是端到端回归测试。我会在CI/CD流水线中加入三步：1）维度一致性测试：新模型上线前，用固定输入（如“你好”）生成向量，比对维度是否与数据库索引一致。2）检索质量测试：用预定义的100个query，计算新模型下的Recall@10和MRR，与旧模型对比，偏差超过5%则阻断。3）性能压测：用Locust模拟1000并发请求，确保P99响应时间不超过500ms。这些测试必须在预发环境运行，通过后才能部署到生产。
追问 3：如果流量突增是正常业务增长，而非故障，你怎么优化？
这是容量规划问题。我会先分析流量增长曲线，用指数平滑法预测未来1个月的QPS。然后，针对瓶颈点做优化：1）Embedding服务：用GPU推理（如T4卡）替代CPU，吞吐量提升10倍；或者用模型蒸馏（如DistilBERT）降低推理延迟。2）向量数据库：增加分片数（从4到16），并用HNSW索引替代IVF_FLAT，提升检索速度。3）缓存层：引入Redis缓存高频query的向量结果，命中率可达30%。最后，设置自动扩缩容策略，QPS超过阈值时自动增加Pod。
5️⃣ 避坑 · 常见错误答法
- ❌ “我直接重启服务，问题就解决了。” → ✅ “重启只是临时缓解症状，必须找到根因（如模型版本不兼容），否则问题会复发。我会先看日志和监控，再决定是否回滚或扩容。”
- ❌ “我用了很多工具，但说不清具体步骤。” → ✅ “我会按‘监控大盘→链路追踪→日志分析’的顺序排查，并给出具体工具名（如Grafana、Jaeger、ELK），展示系统化思维。”
- ❌ “我只修复了问题，没做长期改进。” → ✅ “修复后必须复盘，加入自动化测试、金丝雀发布和压测，避免同类问题再次发生。这体现了工程化能力。”
6️⃣ 简历呼应
- 如果你有RAG项目：从Embedding模型升级导致向量维度不匹配切入，展示你如何设计维度校验脚本和金丝雀发布流程。强调你用过Milvus和Jaeger，能快速定位问题。
- 如果你只做过传统NLP：类比为“模型版本升级导致特征维度变化”，比如从BERT-base切换到BERT-large时，输出维度从768变到1024，导致下游分类器报错。展示你如何用自动化测试检测维度一致性。
- 如果你是校招无项目：聚焦论文复现demo，比如复现DPR时发现检索结果差，排查发现是索引参数（如HNSW的efConstruction）设置不当。展示你如何通过调参和日志分析解决问题。
- 《Site Reliability Engineering》by Google（故障排查方法论）
- 《Building Microservices》by Sam Newman（链路追踪与监控设计）
- Milvus官方文档：索引类型与维度管理
- Jaeger分布式追踪实战指南
- 《Designing Data-Intensive Applications》by Martin Kleppmann（故障恢复与一致性）