日期：2026-07-12
标签：#面试 #八股 #后端 #可观测性 #上线 #场景题
一句话答案
围绕用户体验、业务结果、服务黄金信号、资源饱和度和关键依赖建立上线基线，并通过灰度、对比和自动回滚阈值控制风险。
面试口语版
上线前先定义 SLO 和基线。业务层看注册、下单、支付成功率和金额等核心漏斗；服务层看流量、错误率、P50/P95/P99 延迟和饱和度；资源层看 CPU、内存、GC、线程池、连接池、磁盘、网络和容器限流；依赖层看数据库慢查询/锁/复制延迟、Redis 命中率、MQ Lag、第三方错误和超时。发布层关注实例健康、版本分布、重启和配置变化。先小比例灰度，对照旧版本做指标 Diff，超过阈值自动暂停或回滚，并验证日志、Trace 和告警能定位到版本、区域和租户。
指标清单
- 业务：核心转化率、成功率、订单/金额、数据完整性。
- 黄金信号：Traffic、Errors、Latency、Saturation。
- 运行时：CPU、RSS、GC、线程/连接池、队列。
- 依赖：DB、Redis、MQ、RPC、第三方。
- 发布：健康实例、重启率、版本、回滚和告警。
关键细节
- 指标阈值应基于历史基线和 SLO，不是固定“CPU 80%”。
- 高基数标签会拖垮监控，用户 ID 放日志而非指标。
- 既要看技术指标，也要防“接口成功但业务失败”。
- 告警必须可行动，避免无负责人和无 Runbook。
面试官追问
- 灰度发布如何决定是否继续放量？
- 为什么只看平均延迟不够？
- 技术指标正常但业务指标下降怎么办？
面试官追问参考答案
1. 灰度发布如何决定是否继续放量？
比较新旧版本在相同流量结构下的错误率、P99、资源和核心业务转化，设置观察窗口和最小样本量。指标在阈值内且无新增异常才逐步放量，越界自动暂停或回滚。
2. 为什么只看平均延迟不够？
少量极慢请求会被大量快请求稀释，而这些长尾往往影响高价值用户并占用资源。应看 P95/P99/P999、超时率和按接口/区域/参数分组的分布。
3. 技术指标正常但业务指标下降怎么办？
检查业务埋点、规则、数据和前端交互，沿用户漏斗定位掉点，并按版本/渠道/区域对比。HTTP 200 可能返回业务错误或错误价格，需业务 SLI 和数据对账补充技术监控。
学习清单
- 掌握黄金信号与业务指标。
- 能设计灰度门禁和自动回滚。
维护与整理 · Yihui在 GitHub 上编辑