题干与适用场景
假设平台用户和业务量增长，团队同时面对可用性、延迟、数据正确性、合规风险和新功能需求。请说明你如何识别最重要的可靠性问题、估算影响和投入、选择路线图顺序，并向利益相关者解释取舍。
Google SRE 将 error budget 作为可靠性与发布速度之间的共同决策机制；AWS Well-Architected Tool 建议按业务重要性和实施努力排序，并持续跟踪改进。回答重点是把可靠性翻译为用户和业务结果，不是罗列监控指标。
它不同于“如何定义新功能成功指标”：本题要在资源有限时做跨团队投入排序；也不同于“事故复盘”：重点是事前如何分配下一阶段资源。
面试官考察点
- 是否从关键用户旅程和业务影响定义可靠性。
- 是否使用 SLO、错误预算、风险和成本形成可解释框架。
- 是否能比较立即修复、缓解、架构改造和接受风险。
- 是否给出负责人、里程碑和验证指标。
- 是否能在数据不足时先做低成本学习，而不是假装精确。
回答前需要澄清的问题
- 哪些用户旅程或客户承诺最重要？
- 当前 SLO、错误预算和主要故障类别是什么？
- 问题造成的是流失、收入损失、合规风险、支持成本还是工程负担？
- 可靠性改进的工程量、依赖和机会成本是多少？
- 哪些风险可以短期缓解，哪些必须根治？
- 谁拥有产品、工程、财务和合规决策权？
- 投入成功如何验证？时间窗口多长？
- 是否存在必须立即停止发布的错误预算政策？
30 秒回答框架
“我先按关键用户旅程定义 SLO，并把事故、延迟、数据错误和合规问题映射到业务影响。然后用错误预算、影响范围、风险严重度、工程努力和学习价值排序。我会先处理高影响且可快速降低风险的项目，同时为根治性改造设里程碑；若错误预算耗尽，暂停非必要发布。每项投入都有负责人、目标指标和复查日期，向产品和工程共同说明放弃了什么。”
分步骤深入解答
步骤一：定义用户与业务后果
从支付、登录、发布、数据导出等关键旅程出发，区分可用性、延迟、正确性和隐私。不要把所有内部告警都当作同等优先级。
步骤二：建立可靠性基线
确认 SLO、错误预算消耗、故障频率、影响用户数、恢复时间和支持工单。指标必须能连接到用户体验或业务承诺。
步骤三：拆分解决方案
把候选工作分成止血、缓解、根治和监测四类。止血可能是限流或降级，根治可能是数据模型或架构改造；两者应在路线图中关联。
步骤四：比较影响、成本和学习价值
AWS 建议同时考虑改进重要性和实施努力，并用迭代里程碑跟踪结果。比较时要把机会成本也写出来。
| 决策维度 | 需要回答的问题 | 证据例子 |
|---|---|---|
| 用户影响 | 谁会受影响，频率和严重度如何？ | 关键旅程失败率 |
| 风险 | 是否有安全、合规或不可逆损害？ | 事故与审计记录 |
| 投入 | 工程量、依赖和维护成本？ | 人周与里程碑 |
| 速度 | 能否先做可逆缓解？ | 降级或限流实验 |
| 学习 | 哪个小实验能减少不确定性？ | 分阶段观测 |
步骤五：使用错误预算做发布决策
当服务在预算内，可继续推进高价值功能并安排可靠性债务；预算耗尽时，暂停非必要变更，优先恢复 SLO。错误预算不是无限授权，仍需考虑安全和合规硬约束。
步骤六：协调路线图与资源
给每个项目指定负责人、目标、依赖和完成条件。把可靠性工作放入与功能相同的规划节奏，明确本季度不做的事项和原因。
步骤七：验证结果和调整
跟踪 SLO、错误预算、故障恢复时间、支持量、客户留存或成本变化。若改进没有降低用户影响，重新评估假设，而不是继续投入沉没成本。
步骤八：向利益相关者讲清取舍
用一页决策记录说明选择、证据、风险、替代方案和复查日期。不要把可靠性描述成工程团队的偏好；说明它保护了哪个用户结果和业务承诺。
高质量示范回答
“我会先把平台拆成登录、核心交易和报表三个用户旅程，为每个旅程确认 SLO、错误预算和影响用户。接着按错误预算消耗、关键客户影响、合规风险、工程努力和可逆性排序。
假设核心交易的错误预算连续两周被消耗，我会先做限流和降级，恢复关键路径，再安排根因改造；报表延迟若只影响低频用户，可以先记录并设定里程碑。我会和工程负责人确认人力与依赖，把每项工作写成目标、负责人和验证指标。预算耗尽期间暂停非必要发布，并向销售说明客户承诺的影响。
每两周复查错误预算、恢复时间和支持工单。如果短期缓解已经消除影响，就重新评估根治项目；如果指标没有改善，就停止原方案并寻找新路径。这样可靠性投入与用户结果、发布节奏和机会成本保持一致。”
常见错误
- 把所有告警按技术严重度排序，不看用户影响。
- 只说“可靠性很重要”，不给 SLO 或错误预算。
- 只做永久架构改造，忽略可逆缓解和学习价值。
- 把错误预算当成允许忽略安全、合规的额度。
- 没有负责人、里程碑和复查日期。
- 只报告延迟和可用性，不验证客户和业务结果。
- 只讲工程团队，不说明产品和商业取舍。
追问及应对
追问一：业务方坚持先做新功能怎么办？
把错误预算、客户影响和替代方案量化；若预算耗尽，提出明确的变更冻结规则，并由有权限的人做风险决定。
追问二：没有足够数据怎么排优先级？
先做低成本埋点、故障分类或小范围实验，明确学习目标和停止条件，避免用假精度排序。
追问三：可靠性改进永远没有终点怎么办？
用 SLO 和错误预算定义足够好的边界，比较边际收益与机会成本，并定期复查是否仍匹配用户承诺。
追问四：短期缓解会增加长期债务怎么办？
记录债务、负责人和到期条件，把缓解与根治里程碑绑定；若到期仍未完成，降低范围或升级风险。
追问五：如何证明投入带来价值？
比较改进前后的 SLO、故障恢复、支持量、客户影响、留存或成本，并说明对照窗口和不确定性。
追问六：不同客户的可靠性需求不同怎么办？
按关键旅程、合同承诺和客户影响分层，必要时提供不同 SLO 或隔离容量，但不能让低优先级客户承担不可接受风险。