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