请描述一次你在数据不完整的情况下做出判断的经历。

考察要点

这道题旨在评估你在模糊环境下做出高质量决策的能力，直接对应 Amazon 的领导力准则（LP）：Are Right, A Lot (决策正确)。

这并非要求你拥有预知未来的水晶球，而是考察你如何利用手头有限的信息、经验和逻辑，结合不同的观点，做出最合理的判断，并设计可验证、可回滚的方案来管理风险。

高分示范答案（STAR）

Situation（背景） 去年 Q3，我是公司电商业务核心交易组的一名资深工程师。我们团队（5 人）负责维护一个关键的订单处理微服务，该服务处理所有用户的下单和支付流程。当时，我们刚刚上线了一个新功能，允许商家在商品中附加一些定制化的元数据（存储在 PostgreSQL 的一个 JSONB 字段里）。

Task（任务） 新功能上线后的第二个周一早高峰，我收到警报，订单服务的 P99 延迟从平时的 200ms 飙升到 1500ms 以上，错误率也从 0.1% 上升到了 5%。这意味着每 100 个用户下单，就有 5 个会失败，直接导致收入损失。我的任务是立即定位问题并恢复服务，但挑战在于：监控面板只显示数据库 CPU 负载过高，却没有任何一条具体的慢查询日志，我们无法立刻知道是哪个查询出了问题。

Action（行动） 面对数据不完整的紧急情况，我采取了以下行动：

1. 我首先基于经验形成假设：我立刻召集了 on-call 同事和 DBA 组成线上应急小组。虽然没有直接证据，但我怀疑问题出在新上线的 JSONB 字段。因为在之前的 Code Review 中，我曾指出 ORM 框架在处理这类动态字段时，可能会生成低效的查询计划，尤其是在高并发下。这是一个基于第一性原理和过往经验的“直觉”。

2. 我快速寻找代理数据（Proxy Data）来验证假设：等待 DBA 抓取慢查询日志可能需要 20-30 分钟，我们等不起。于是，我立刻写了一个简短的脚本，去分析应用服务器的访问日志（access log），计算包含新版“定制化元数据”请求的平均响应时间和不包含该数据请求的平均响应时间。这个脚本虽然不能定位到具体 SQL，但可以快速验证我的假设。

3. 我基于不完整但强相关的信号做出决断：脚本在 3 分钟内就跑出了结果：包含新元数据的请求，平均延迟高达 2200ms；而老版本的请求，延迟仍在 200ms 左右。这个相关性极强。此时，DBA 团队建议再观察一下，希望能抓到具体的 SQL。我判断，业务损失的风险远大于技术上“完美归因”的需求，因此我做出了决断：立即通过我们预设的功能开关（Feature Flag）在配置中心禁用这个新功能。

4. 我执行决策并清晰沟通：我亲自执行了禁用操作，并立即在应急小组和管理层群里同步了我的决策、背后的数据（日志分析结果）和推理过程。我强调这只是一个止血的临时措施，目的是恢复主流程，后续我们会进行详细的根因分析。

Result（结果）

• 即时效果：在禁用功能开关后的 5 分钟内，订单服务的 P99 延迟降回 210ms，错误率恢复到 0.1% 以下，核心业务完全恢复正常。
• 业务影响：根据估算，这次快速决策为公司挽回了每小时约 30 万元人民币的潜在交易损失。
• 后续验证：事后的根因分析也证实了我的判断：在高并发下，ORM 对 JSONB 的查询触发了全表扫描。我从这次经历中学到，在危机处理中，寻找强相关的“代理数据”来做决策，远比等待“完美数据”更有效。

低分陷阱（常见扣分点）

• 用“我们”模糊个人贡献：反例：“我们觉得可能是新功能的问题，所以我们决定回滚。” -> 面试官会想：是你想到的还是别人？是你做的决定还是你老板？
• 只有直觉，没有逻辑：反例：“我感觉就是那个新功能有问题，就把它关了。” -> 这听起来像赌博，而不是“Are Right, A Lot”。你需要解释你的“感觉”从何而来（经验、代码审查的印象等），以及你如何快速验证它。
• 结果没有量化，空洞无力：反例：“项目很成功，问题解决了。” -> 应该说：“延迟从 1500ms 降至 210ms，挽回了 XX 万/小时的损失。”
• 选择的故事过于简单：反例：“我发现一个配置写错了，改过来就好了。” -> 这没有体现出在“信息不完整”的情况下做“判断”的复杂性，无法展现你的能力。
• 没有体现权衡（Trade-off）：一个好的决策故事往往包含冲突和权衡。比如本例中，在“DBA 建议继续观察”和“立即止损”之间做出了权衡。

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

1. 追问：如果你的判断是错的呢？你有没有备用计划（Plan B）？

   • 要点 1 (风险隔离)：强调我的决策本身就是风险可控的。我选择的是“禁用功能开关”，这是一个非常安全、可逆的操作。如果禁用后问题依旧，我可以在 1 分钟内重新打开开关，对用户几乎无感知。
   • 要点 2 (并行路径)：说明在做这个决策的同时，我并没有让 DBA 团队停止工作。我的建议是“先止血，再诊断”。如果我的方案无效，DBA 的深入排查就是 Plan B，我们没有浪费任何时间。

2. 追问：你如何说服希望继续观察的 DBA 团队？

   • 要点 1 (聚焦共同目标)：我会先肯定他们的专业性，表示“我理解并尊重你们希望找到根本原因的专业精神”。然后，我会把讨论的焦点从“技术诊断”转移到“业务影响”上，拿出数据说：“根据目前的错误率，我们每分钟都在流失 X 个订单，我们必须先止住这个损失。”
   • 要点 2 (建立信任)：向他们承诺，这只是一个临时措施，一旦服务稳定，我会全力配合他们进行根因定位，并确保在事后复盘中找到长期的解决方案。这表明我不是在挑战他们的权威，而是在和他们并肩解决一个更大的业务问题。

3. 追问：为了防止这类问题再次发生，你做了什么？

   • 要点 1 (技术层面)：我推动团队为这类涉及新数据结构或复杂查询的功能，建立了一套新的性能测试标准。具体来说，我们引入了基于生产流量回放的压测，确保在上线前就能发现潜在的性能瓶颈。
   • 要点 2 (流程层面)：我主导了事后复盘（Postmortem），并将这次事件的分析和经验教训整理成文档，在整个技术部门进行了分享。特别强调了“功能开关”作为线上应急预案的重要性，推动了多个团队将此作为新功能的标配。

故事复用建议

这个故事非常扎实，除了 Are Right, A Lot，还可以根据面试官的提问侧重点，进行微调后复用于以下维度的考察：

• Ownership (主人翁精神)：你在事故发生时主动站出来，承担起责任，推动问题解决。
• Bias for Action (崇尚行动)：面对不确定性，你没有陷入分析瘫痪，而是快速行动以降低业务损失。
• Deliver Results (交付成果)：你最终成功恢复了服务，并量化了你的成果。
• Dive Deep (深入钻研)：你没有停留在“数据库慢了”的表面现象，而是通过日志分析去挖掘更深层次的关联。
• Earn Trust (赢得信任)：你通过清晰的沟通和尊重他人的专业，赢得了 DBA 和管理层的信任。