你如何在不确定性下做决策？

考察要点

这道题重点考察你在模糊环境下做出高质量决策的能力。对于 Amazon，它直接映射到 Bias for Action（行动偏好）和 Are Right, A Lot（决策正确率高）。你需要展示的不是赌博，而是在分析了有限信息和潜在风险后，做出最合理的、可控的、可逆的决策。

高分示范答案（STAR）

Situation（背景） 我在上一家电商公司担任支付核心团队的资深工程师（SDE III）。当时正值“黑五”大促的流量高峰夜，团队有 5 位工程师在待命。我的角色是那一周的 on-call 主负责人，负责整个支付链路的稳定性。

Task（任务） 大约在晚上 10 点，我收到警报，显示整体支付成功率从正常的 99.5% 间歇性地掉到 92% 左右。监控面板上我们自身服务的各项指标（CPU、内存、延迟）都处于正常范围，没有明显异常。我的任务是，在不确定根本原因的情况下，必须在 30 分钟内恢复支付成功率，以避免更大的商业损失。

Action（行动） 面对巨大的不确定性和时间压力，我采取了以下几个关键步骤：

1. 我首先快速建立假设并寻找证据。 我没有陷入逐行翻阅海量日志的困境，而是提出了一个假设：问题可能出在外部依赖的某个支付渠道上。我立刻用 Splunk 查询，按支付渠道对失败订单进行分组聚合。我发现，超过 80% 的失败交易都指向了我们当时的主力支付渠道 A，而渠道 B 和 C 的成功率依然正常。虽然这并非 100% 的证据（因为渠道 A 承载了 70% 的流量），但这给了我一个明确的行动方向。

2. 我设计了一个“可逆的、有控制的”实验方案来验证假设。 直接全量切换流量风险很高，万一渠道 B 无法承载突增的流量，可能导致更严重的问题。因此，我决定不进行全量切换，而是设计了一个两步走的方案：首先，我通过动态配置中心，将 20% 的原属于渠道 A 的流量切换到渠道 B。这个决策是基于我之前做过的压测数据，我清楚渠道 B 至少还有 50% 的容量冗余。

3. 我主动沟通并明确了风险。 在执行前，我在作战室里向技术总监和产品负责人清晰地说明了我的计划：“我的假设是渠道 A 不稳定。我准备把 20% 的流量切到 B。最坏的情况是，如果 B 也出现问题，我们可以在 1 分钟内通过配置回滚。但如果我们什么都不做，按当前的掉单率，每小时会损失约 10 万美金的交易额。” 这让他们理解了我的决策逻辑和风险权衡，并获得了他们的支持。

4. 我亲自执行并持续监控结果。 我修改了流量分配配置并立即发布。在接下来的 15 分钟里，我紧盯着聚合支付成功率和渠道 B 的各项监控指标。我们清晰地看到，整体支付成功率开始回升至 97% 以上。这验证了我的假设。随后，我将另外 30% 的流量也切换到了渠道 B，最终将整体成功率稳定在了 99.3%。

Result（结果） 通过这一系列在不确定情况下的决策，我们在 30 分钟内将支付成功率从最低点的 92% 恢复到了 99.3%，基本止住了损失。根据后来的估算，这个快速决策为公司挽回了当晚约 25 万美元 的潜在交易损失。大约一小时后，支付渠道 A 的供应商也发来通知，确认了他们机房网络出现了瞬时抖动。通过这次经历，我深刻理解了在不确定性面前，小步快跑、验证假设和设计可逆方案的重要性。

低分陷阱（常见扣分点）

• 用“我们”代替“我”：例如说“我们团队觉得应该切换流量”，这让面试官无法判断是你做出的决策，还是你只是一个执行者。
• Result 虚化，没有量化：说“问题很快解决了，项目很成功”，而不是“支付成功率从 92% 恢复到 99.3%，挽回了约 25 万美元的损失”。
• Action 只有操作，没有思考：说“我查了日志，改了配置，然后就好了”，这只是流水账。高分答案需要解释“为什么”这么做，比如“我没有全量切换，因为风险太高，而是基于压测数据做了 20% 的灰度切换”。
• 故事过于简单，没有体现“不确定性”：选择一个“bug 很明显，修复很简单”的故事，无法体现你在压力和信息缺失下的判断力。这个问题的核心就是“不确定”。

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

1. 追问：在你提出切换 20% 流量时，如果你的老板或同事反对，认为风险太大，你会怎么办？

   • 要点 1 (重申数据)：我会再次强调我观察到的数据——80% 的失败指向渠道 A，这是一个强烈的信号，我们不能忽视。
   • 要点 2 (强调风险控制)：我会重点解释这个方案的“安全垫”——决策是可逆的（1 分钟内可回滚），且影响范围是可控的（只动了 20% 的流量）。
   • 要点 3 (对比不作为的代价)：我会量化不作为的风险，即每分钟都在损失的交易额，让大家明白“等待”的成本可能比“行动”的风险更高。

2. 追问：你当时还考虑过其他哪些方案？为什么没有选择它们？

   • 要点 1 (方案一：等待)：考虑过等待更详尽的日志分析结果，或者等渠道 A 的技术支持回复。我没有选，因为大促期间时间就是金钱，等待的成本太高。
   • 要点 2 (方案二：重启服务)：考虑过重启我们自己的支付服务，因为有时这能解决一些隐藏的连接池或内存问题。我没有选，因为我们的服务监控指标完全正常，重启是盲目操作，风险极高，可能导致服务在短时间内完全不可用。
   • 要点 3 (结论)：相比之下，小范围切换流量是当时唯一一个既能快速验证假设，又风险可控的方案。

3. 追问：你怎么确定渠道 B 有 50% 的容量冗余？这个数据准确吗？

   • 要点 1 (历史数据来源)：这个数据来自于我在大促前一个月亲自负责的性能压测项目。当时我们对所有支付渠道都进行了极限压测，并记录了它们的安全水位线。
   • 要点 2 (数据交叉验证)：除了压测数据，我当时也快速看了一眼渠道 B 的实时监控，它的 CPU 和交易处理队列长度都远低于警戒值，这交叉验证了它有充足的冗余。这表明我的决策不是凭空猜测，而是基于先前严谨的工作。

故事复用建议

这个故事非常扎实，除了 Bias for Action 和 Are Right, A Lot，还可以根据不同的提问侧重点进行微调，复用于以下几个方面：

• Ownership：作为 on-call owner，你主动承担起责任，在没人能给你明确指令时推动了问题的解决。
• Deliver Results：面对危机，你最终交付了业务结果（恢复成功率、挽回损失）。
• Dive Deep：你没有停留在表面现象，而是快速下钻数据，找到了最可疑的故障点。
• Customer Obsession：你的所有行动都是为了保证用户的支付体验，避免他们因为系统问题无法完成购买。
• Insist on the Highest Standards：即使在紧急情况下，你也没有选择“重启大法”这种低标准操作，而是选择了更严谨、更专业的方案。