请讲讲你何时不得不在数据不完整的情况下做出技术决策。

考察要点

这道题重点考察候选人的判断力、风险管理能力和务实精神。在 Amazon，这直接对应 Bias for Action (敢于行动) 和 Are Right, A Lot (决策正确率高)。一个优秀的领导者需要在信息不完整时，也能基于逻辑、经验和少量数据做出“大概率正确”的决定，并为这个决定设置安全网。

高分示范答案（STAR）

Situation（背景） 我在 2022 年担任某电商公司推荐流团队的 Tech Lead，团队约 8 人。我们的核心业务是为 App 首页信息流提供个性化商品推荐，这是一个 QPS 高达 10 万的核心服务。当时，业务方计划上线一个“千人千面”的营销活动，要求我们能根据用户的实时行为（如刚刚加购的商品）在 1 秒内调整推荐结果。

Task（任务） 我的任务是完成推荐系统的技术选型，以支持这个实时计算的需求。目标是将用户行为传递到推荐引擎的端到端延迟控制在 1 秒以内。然而，我们没有任何关于这类实时用户行为数据的流量模式、峰值大小和数据分布的线上历史数据，因为这是个全新的功能。等待数据采集和分析至少需要一个月，但这会让我们错过双十一的上线窗口。

Action（行动） 面对数据缺失的困境，我必须在“等待完美数据”和“承担风险快速决策”之间做选择。我采取了以下行动：

1. 我首先定义了决策的关键未知量：最大的不确定性是实时事件的峰值 QPS。如果选型无法承载峰值流量，系统就会崩溃；如果过度设计，则会浪费大量成本。
2. 我没有凭空猜测，而是寻找了“代理数据”（Proxy Data）。我找到负责用户行为采集的团队，虽然没有“实时加购”事件的数据，但他们有“点击加购按钮”的历史日志。我分析了这些日志，发现其流量模式与大盘流量高度相关，峰值通常出现在晚 8 点，约为日均流量的 5 倍。我基于这个 5x 的峰值因子，结合当前推荐服务的 QPS，估算出新系统的峰值 QPS 大约在 5k 左右。这是一个有根据的推断，而不是纯粹的猜测。
3. 我基于估算的数据，做出了一个“可演进”的技术决策。我排除了需要复杂部署和高昂成本的 Flink，因为它对于 5k QPS 的场景来说过于笨重。我最终选择了 Kafka + 一个轻量级自研流处理服务。我的决策逻辑是：这个架构足以应对预估的 5k QPS，且成本低、部署快。更重要的是，如果未来流量远超预期，这个架构可以平滑地迁移到 Flink——Kafka 可以直接作为 Flink 的数据源，我们现有的流处理逻辑也可以复用。
4. 为了管理风险，我设计了“安全阀”。在我的设计里，Kafka 消息队列本身就是一个缓冲层。我还加入了一个动态采样机制，如果下游处理不过来，可以临时降低事件采样率（比如从 100% 降到 50%），保证核心系统的稳定，而不是完全崩溃。这让我的决策变得“可逆”且“安全”。

Result（结果） 我们团队用 3 周时间就完成了这套轻量级实时推荐系统的开发和上线，成功赶上了双十一。

• 量化结果：上线后，系统平稳运行，线上真实峰值 QPS 约为 4.5k，与我的估算（5k）非常接近。端到端延迟稳定在 800ms，完全满足了业务小于 1 秒的要求。
• 业务影响：新的实时推荐功能使双十一期间的首页点击转化率提升了 5%。
• 我的收获：我学到在数据不完备时，寻找代理数据进行推断，并设计可演进、有安全垫的架构，是推动项目在不确定性中前进的关键。

低分陷阱（常见扣分点）

• 把“没数据”当成“纯靠猜”：反例：“我们当时没数据，我就凭经验觉得用 Kafka 应该没问题。” -> 这体现不出你的判断力和分析能力。你需要解释你是如何通过逻辑推断、寻找替代数据来缩小不确定性范围的。
• Action 变成“我们做了什么”：反例：“我们团队讨论后，决定用 Kafka。然后我们一起搭建了系统。” -> 面试官想知道“你”在其中的关键作用。是你提出分析代理数据？是你做出最终的技术选型决策？是你设计了风险预案？
• 结果含糊不清，没有量化：反例：“项目很成功，系统运行稳定，业务也很满意。” -> 这毫无说服力。必须给出数字，比如“预估 QPS 是 5k，实际上线后是 4.5k，延迟从无法实现降到 800ms，转化率提升 5%”。
• 选择了一个没有风险的决策：如果你的决策没有任何潜在的负面影响，那就说明这个问题本身太简单，无法体现你的能力。你需要说明你权衡了哪些风险（比如成本、稳定性、开发周期）。
• 没有体现决策的可逆性或风险控制：一个资深工程师的决策会包含“如果我错了怎么办”的预案。比如例子中的“动态采样”和“架构可演进”就是很好的风险控制措施。

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

1. 追问：你当时还考虑了哪些其他的技术方案？为什么没有选择它们？

   • 要点 1 (Flink/Spark Streaming)：解释为什么这些重型框架不合适。比如：“我考虑过 Flink。它的功能强大，但对于我们当时预估的 5k QPS 来说，部署和维护成本太高，属于‘杀鸡用牛刀’。我们的团队也没有 Flink 的运维经验，学习曲线会拖慢项目进度。”
   • 要点 2 (直接调用 API)：解释为什么轮询或直接调用的方案不行。比如：“也想过让客户端直接调用推荐引擎的更新接口，但这会让推荐服务直接暴露在流量洪峰下，耦合度太高，一旦出问题会拖垮核心服务。使用消息队列可以很好地解耦和削峰填谷。”

2. 追问：如果你的流量预估错了，比如实际流量是预估的 5 倍，你的架构会发生什么？你会如何应对？

   • 要点 1 (触发安全阀)：首先说明你设计的“安全阀”会生效。“首先，我设计的动态采样机制会自动启动，比如临时将采样率降至 20%，保证即使在极端流量下，下游服务也能在处理能力范围内运行，避免雪崩。”
   • 要点 2 (利用缓冲层)：“同时，Kafka 作为缓冲层会开始积压消息，这为我们赢得了宝贵的应对时间，而不是立即丢失用户行为数据。”
   • 要点 3 (紧急扩容与长期演进)：“在赢得的时间里，我会立即对自研的流处理服务进行水平扩容。长期来看，如果确认流量持续在高位，我会启动预案，将处理逻辑迁移到 Flink，因为我们早期的架构设计保证了这种迁移的平滑性。”

3. 追问：你是如何说服你的团队和老板，在没有确切数据的情况下接受你的技术方案的？

   • 要点 1 (展示你的分析过程)：“我没有直接给结论，而是把我的整个分析过程分享给了他们。我解释了我是如何找到‘点击加购按钮’这个代理数据的，以及我是如何基于它推导出 5x 峰值因子的。这让他们相信我的决策不是拍脑袋，而是基于现有信息的最佳推断。”
   • 要点 2 (强调风险控制)：“我重点强调了方案中的风险控制措施，比如 Kafka 的缓冲能力和动态采样这个‘安全阀’。我让他们明白，即使我们的预估有偏差，系统也不会崩溃，我们有预案。”
   • 要点 3 (沟通收益与成本)：“最后，我清晰地对比了两种选择的利弊：方案A（我的方案）能让我们按时上线，抓住双十一的机会，且风险可控；方案B（等待数据）虽然更稳妥，但会 100% 错失业务窗口。这样权衡下来，大家都很容易接受我的方案。”

故事复用建议

这个故事的核心是“在不确定性中做决策”，非常万能。除了本题，它至少还可以用于回答以下问题：

• Ownership：你主动承担了解决业务难题的责任，而不仅仅是执行。
• Deliver Results：你克服困难，按时交付了有巨大业务价值的项目。
• Bias for Action：你没有因为数据不完备而瘫痪，而是主动寻找方法推进。
• Are Right, A Lot：你的预估和决策被证明是正确的。
• Invent and Simplify：你选择了一个简单、可演进的架构，而不是过度设计的复杂方案。
• Tell me about a time you took a calculated risk. (这个故事完美契合)
• Describe a complex technical challenge you faced. (不确定性本身就是一种复杂性)