Question 1

线上接口突然大面积超时，你的定位链路是什么？

Accepted Answer

我的原则是先止损后归因。第一步看入口指标区分影响面：是全量还是某个分区/版本，错误率和 P99 同时涨说明容量或依赖问题，只有 P99 涨多半是慢查询或 GC。第二步查变更记录——发布、配置、DNS、证书、上游依赖，命中率最高。确认影响面后立刻止损：能回滚就回滚，不能就限流、降级非核心链路、把流量切到健康分区。第三步才是根因：顺着调用链看依赖耗时分布，锁定某一跳后再看那一跳的资源、连接池、数据库慢日志。我做过一次典型案例：接口超时其实是下游连接池被一个新加的同步调用打满，回滚后 5 分钟恢复，根因两小时后定位，最后补的机制是「新增外部调用必须显式设超时和熔断」。

Question 2

怎么定 SLO？错误预算具体怎么用？

Accepted Answer

我定 SLO 从用户关键旅程出发：先问「用户做什么会感知到我们坏了」，比如下单成功率和下单 P95 耗时，再据此选 SLI，而不是把现成的 CPU 使用率当 SLO。目标值我不追求 99.99% 的漂亮数字，而是取「用户不抱怨、成本可承受」的水位，通常参考历史真实达成率再收紧一档。错误预算的价值在仲裁：预算充足时鼓励快速发布和大胆变更；烧掉一半触发告警和复盘；烧完了就冻结非必要发布，团队本迭代优先做稳定性项。这条规则要在事前和业务方达成书面共识，否则真出事时会被推翻。我落地过一次：连续两个月预算超支后按规则冻结发布两周，专项做了重试风暴治理，之后半年预算再没超支。

Question 3

设计一条 CI/CD 流水线，你会放哪些质量门？

Accepted Answer

我按反馈速度分层设计：提交阶段跑 lint、类型检查和单测，目标 5 分钟内出结果，这一层必须阻断；构建阶段产出不可变制品（镜像加不可变 tag），后续所有环境用同一制品，杜绝「测的和上的不是一个东西」；集成阶段跑接口契约测试与数据库迁移预演；端到端与性能基线只在合入主干和发布前跑，因为它们慢且不稳定，其中不稳定的那部分我设成告警门而不是阻断门，否则团队会习惯性重试直到绿灯，门就废了。发布阶段是灰度加自动回滚：按比例放量、盯核心指标和错误预算，超阈值自动回滚。安全门（依赖漏洞、密钥扫描）我放在合入前阻断，因为事后修成本高得多。

Question 4

容器编排里，Pod 频繁重启你怎么查？资源怎么配？

Accepted Answer

我先看重启原因：OOMKilled 就是内存 limit 不够或应用泄漏，要拿堆内存曲线区分是「稳态偏高」还是「持续爬升」；探针失败要看是启动慢被存活探针误杀（这时该加就绪探针和启动探针，而不是简单放宽存活探针），还是依赖不可用导致探针真的该失败；非零退出码就回到应用日志。资源配置上，requests 决定调度和最低保障、limits 决定被杀阈值，我一般按压测得到的 P95 用量设 requests、给 limits 留合理余量；CPU limit 我会谨慎，配太紧会导致节流、表现为莫名的延迟毛刺。我见过一个典型自伤案例：存活探针超时设成 1 秒，GC 停顿一超就被杀，重启又加剧负载形成雪崩——把探针改合理后问题消失，应用本身没动。

Question 5

可观测性的三支柱怎么用？只有日志够不够？

Accepted Answer

我把三者当分工而不是三套并行的日志系统：指标负责「发现」，低成本高基数受限，用来做 SLO 告警和趋势；链路追踪负责「定位」，一个慢请求究竟慢在哪一跳，靠日志人肉拼 traceId 效率极低；日志负责「确认」，看到具体参数和异常栈。只有日志的团队典型症状是：故障时全靠 grep，成本随流量线性涨，还答不出「昨天同一时段是不是也这样」。落地上我会强制统一 traceId 贯穿网关到下游，让三者能互相跳转，这一步比换任何工具都值。成本控制上，链路做头部采样加错误全采、日志分级并对高频 debug 日志采样、指标控制标签基数——我处理过一次标签里放了用户 ID 导致时序库爆掉的事故，这类基数失控比数据量本身更危险。

Question 6

云成本一个月涨了 40%，你怎么查怎么降？

Accepted Answer

我第一步做归因而不是砍成本：按资源标签拆出是哪个服务、哪类资源涨的，同时区分用量涨还是单价涨——比如按需实例替代了预留实例属于单价问题，流量翻倍属于用量问题，前者是采购动作，后者才需要技术优化。第二步按性价比排序处置：先删明显浪费（孤儿磁盘、闲置负载均衡、忘关的测试环境、无生命周期策略的对象存储），这类几乎零风险；再按真实利用率调规格，我要求依据是 P95 用量而不是峰值恐惧；然后才是架构优化（缓存命中率、跨区流量、冷数据分层）；最后谈预留和折扣。我做过一次专项，最大一笔节省其实来自日志留存策略：全量日志存 90 天改成热 7 天、冷 90 天，单项降了两成多，业务侧零感知。

Question 7

一次高风险变更（比如数据库迁移）你怎么设计发布方案？

Accepted Answer

我按可逆性设计。数据库迁移我拆成五步：先加新结构（向后兼容，随时可停）；再双写新旧两侧并对账，这一步跑够长时间拿到差异率；然后影子读，用新侧数据和旧侧比对但不对外返回，验证正确性；确认无差异后按比例切读流量，从内部流量到 1% 到全量；最后才停双写、下线旧结构，这一步之前所有阶段都能立即回退。事前我会写好变更文档：观测哪几个指标、回滚触发阈值是什么、谁有权拍回滚、回滚需要多久，这些必须事前定，因为故障当下人是不理性的。真正不可回滚的操作（比如删数据、结构破坏性变更）我坚持三件事：先在同规模影子库演练一遍、备份做过实际恢复验证而不是只看备份成功、且安排在低峰且有充足人力值守的窗口。

Question 8

讲一个你主导的稳定性项目或线上事故，结果和教训是什么？

Accepted Answer

我讲一次雪崩事故。影响：核心接口错误率从 0.1% 涨到 30%，持续 22 分钟，影响约两成用户请求。处置：值班同学 3 分钟内根据告警定位到某依赖不可用，先降级该依赖的非核心功能，8 分钟后错误率回落，22 分钟完全恢复。根因不是依赖挂了本身，而是我们的客户端重试策略——固定间隔无上限重试，依赖抖动时把请求量放大了近十倍，自己把自己打死了。我主导的机制建设有三条：所有出网调用统一走带指数退避加抖动、带熔断的客户端；关键路径必须有降级开关且开关本身要定期演练；把「重试放大倍数」加入压测项。可量化的结果是之后一年同类依赖抖动发生过四次，均未造成用户可感知故障。复盘我们不追责值班同学，因为问题出在默认重试配置这个系统缺陷上——这也是我坚持无指责复盘的原因，追责只会让下次没人敢报故障。

运维/SRE 高频面试题：8 道必考题与作答要点