请分享一个你在信息不完整的情况下做出艰难决定的经历。

考察要点

这道题旨在考察你在信息不完整、时间紧迫的情况下，如何进行逻辑推理、权衡风险并果断行动的能力。

对于 Amazon，这道题直接考察 Bias for Action (崇尚行动) 和 Are Right, A Lot (决策正确)，同时也体现了 Ownership (主人翁精神)。

高分示范答案（STAR）

Situation（背景） 去年 Q3，我在一家电商公司的支付核心团队担任后端技术负责人（Tech Lead）。当时我们团队（6名工程师）刚上线了一个新的聚合支付网关，旨在统一处理来自 App、H5、小程序等多个渠道的支付请求。上线初期，系统整体运行平稳。

Task（任务） 上线后第二周的周一下午，我收到告警，系统 P99 延迟从平时的 150ms 飙升到 800ms，并且开始出现少量（约 1%）的支付失败。监控面板上只能看到是数据库的 CPU 负载异常增高，但日志中没有任何明显的错误信息。我作为该项目的负责人，必须在不影响用户支付体验的前提下，尽快定位并解决问题，将失败率降至 0.1% 以下。

Action（行动） 当时信息非常有限，我面临一个艰难的抉择：是立刻回滚到旧系统（但会丢失两天的新交易数据和新功能），还是在生产环境上冒险排查。我采取了以下行动：

• 第一，我没有立刻选择回滚。 因为回滚操作本身有风险，且会造成业务损失。我判断，虽然有延迟和少量失败，但主流程尚未瘫痪。我决定先用 15 分钟进行快速的“影响面评估”。我通过临时的 SQL 查询分析了受影响的订单特征，发现出问题的订单都与一个新上线的“银行卡快捷支付”渠道有关，其他支付渠道（如支付宝、微信支付）均正常。
• 第二，我基于这个不完整的线索，形成了一个假设： 问题可能出在新渠道的数据库交互逻辑上，可能是一个未被测试覆盖的慢查询或锁竞争。但由于没有确切证据，我无法直接修改代码上线。
• 第三，我做出了一个关键决策：执行“灰度降级”。 我没有全量下线新渠道，而是在配置中心修改了路由规则，将 90% 的“银行卡快捷支付”流量切回旧的、独立的支付服务，只保留 10% 的流量在新网关上用于问题排查。我之所以这么做，是为了在最小化业务影响（保住 90% 的用户）和保留问题现场（留出 10% 的流量）之间取得平衡。
• 第四，在隔离了大部分流量后， 数据库负载果然迅速下降。我利用保留的 10% 流量，开启了更详细的 SQL 日志和性能剖析（profiling）。很快，我就定位到一个在特定条件下被触发的、针对优惠券表的 JOIN 语句没有命中索引，导致了全表扫描。在修复并验证了这个问题后，我才将全部流量切回新系统。

Result（结果） 在做出降级决策后的 20 分钟内，整体支付服务的 P99 延迟从 800ms 恢复到了 150ms，支付失败率从 1% 降至 0.08%，成功避免了一次可能导致数百万交易额损失的重大故障。这次经历也让我推动团队建立了一套标准的“灰度降级”和“流量染色”机制，作为未来处理线上紧急故障的标准预案。

低分陷阱（常见扣分点）

• 没有体现“不完整信息”的压力： 候选人可能会说“我一看日志就知道问题了”，这完全没有体现出在信息缺失情况下的判断力。
• 决策过程过于简单，缺少权衡： “我们决定回滚”，这是一个选项，但不是一个好的故事。面试官想听的是你为什么不回滚，你考虑了哪些因素，你如何创造性地解决了问题。
• Action 变成团队流水账： “我们开会讨论”、“我们一起排查”、“我们修复了 bug”。面试官无法判断你的个人贡献。必须说“我提出了什么假设”、“我做出了什么决策”、“我执行了什么操作”。
• 结果含糊不清： “问题解决了，系统恢复了正常。” 这等于没说。必须量化：“失败率从 X% 降到 Y%”、“影响了多少收入/用户”、“节省了多少时间”。
• 选择的故事太小： “我不知道用 A 框架还是 B 框架，最后猜了一个。” 这类故事缺乏业务影响力和技术深度，无法体现你的资深水平。

高概率追问（3 个 + 示范回答要点）

1. 追问：你当时为什么有信心只降级那一个支付渠道，而不是更保守地回滚整个系统？万一判断错了怎么办？

   • 要点 1 (数据驱动的风险评估): 强调虽然信息不完整，但并非完全瞎猜。我通过 15 分钟的快速数据分析，发现问题订单与新渠道有强相关性，这是一个关键信号，让我有 80% 的把握问题出在这里。
   • 要点 2 (预备方案): 说明这是一个经过计算的风险。我的降级方案本身就是可逆的。如果降级后问题依旧，我的 Plan B 就是立即执行全量回滚。我向团队和上级清晰地沟通了这一点，我们做好了最坏的打算。

2. 追问：在做“灰度降级”决策时，有没有人提出反对意见？比如产品经理担心影响用户体验？

   • 要点 1 (清晰的沟通与对齐): 承认有阻力。产品经理确实担心即便是 10% 的用户也会受影响。我的应对方式是，向他清晰地展示了两个选择的利弊：A) 立即回滚，100% 的用户无法使用新功能，且有数据丢失风险；B) 我的方案，90% 的用户体验完全恢复正常，我们能更快定位问题，最终让 100% 的用户受益。
   • 要点 2 (建立信任): 强调这是在展现技术担当。我向他承诺，我会全程监控，并设定了明确的时间盒（Timebox），比如 30 分钟内如果还未定位问题，就立刻启动下一个预案。这种有计划、有担当的沟通方式，最终赢得了他的信任。

3. 追问：你说你后来推动建立了一套标准机制，能具体讲讲你在其中扮演的角色和这个机制是什么样的吗？

   • 要点 1 (展现 Ownership 和影响力): 说明我不仅仅是解决了一个问题，更是把经验变成了机制。我主动发起了这次复盘会（Post-mortem），并撰写了技术方案文档。
   • 要点 2 (具体化机制): 描述机制的核心。例如，我设计的机制包括：1) 流量染色：给特定用户或渠道的请求打上特殊标记，方便全链路追踪。2) 动态配置中心：允许我们在不发版的情况下，通过开关实时调整流量路由策略。3) 标准操作手册(SOP)：定义了不同等级故障下的标准降级、隔离流程，让任何 on-call 工程师都能快速响应。

故事复用建议

这个故事非常扎实，可以轻松改编用于回答以下问题：

• Ownership: "讲一个你主动承担责任，并超出预期的故事。" (主动发起复盘并建立机制就是超出预期)
• Deliver Results: "讲一个你在困难情况下交付成果的例子。" (在压力下恢复核心业务)
• Dive Deep: "讲一个你深入挖掘技术难题的例子。" (从模糊的表象深入到 SQL 索引层面)
• Customer Obsession: "讲一个你如何为客户着想的例子。" (所有决策都围绕着如何最小化对用户支付体验的影响)
• Are Right, A Lot: "讲一个你依靠判断力做出正确决策的例子。" (在信息不足时做出正确的降级判断)