描述一次你被他人依赖的经历。

考察要点

这道题旨在考察候选人在高压、关键时刻的**担当（Ownership）和交付结果（Deliver Results）**的能力。面试官希望看到你如何在高风险场景下，作为核心依赖点，独立地分析问题、制定方案、推动执行，并最终取得可衡量的成果。

对于 Amazon，这主要考察 Ownership 和 Deliver Results，也可能涉及 Bias for Action。

高分示范答案（STAR）

Situation（背景） 去年第三季度，我在一家电商公司担任支付核心团队的资深工程师（SDE III）。我们团队共 8 人，负责整个交易链路的支付网关服务。当时我正好是那一周的 on-call 工程师，负责处理所有线上生产环境的告警和问题。

Task（任务） 在一个周五的下午，我收到了系统 P0 级别的告警，显示支付成功率在 5 分钟内从 99.9% 暴跌至不足 10%。这意味着几乎所有用户都无法完成支付，每分钟都在造成直接的收入损失。我的任务是作为第一负责人，在最短时间内恢复服务，并定位根因，防止问题再次发生。

Action（行动） 面对这个紧急情况，我采取了以下几个关键行动：

• 我首先迅速建立了“作战室”：我立刻创建了一个视频会议，并拉入了所有相关方，包括我的经理、产品经理、SRE 团队以及客服团队的负责人。我明确了自己是这次故障处理的总接口人（Incident Commander），并建立了每 15 分钟同步一次进展的沟通机制，这避免了信息混乱和重复询问，让我能专注在技术排查上。
• 我通过数据分析快速定位问题边界：我首先排除了外部依赖（如银行渠道）的问题，因为监控显示我们向银行发起的请求本身就失败了。接着，我通过分析服务日志和数据库监控，发现数据库连接池在短时间内被耗尽。我进一步通过 SHOW PROCESSLIST 命令抓取了当时的慢查询，定位到一条来自订单服务的、未经优化的 JOIN 查询导致了数据库锁表。
• 我做出了果断的回滚决策并处理了阻力：定位到是订单服务最近的一次上线引入了这条慢查询后，我判断最快的恢复方式是回滚他们的变更。我立即联系了订单团队的 on-call 工程师，但他对回滚一个已上线的功能感到犹豫。我没有与他争论，而是直接将数据库锁表的截图和支付成功率暴跌的监控图表发给他，并清晰说明了每分钟造成的预估十万级的交易损失。数据面前，他立刻同意并执行了回滚操作。
• 我推动了长期的解决方案落地：服务恢复后，我没有就此打住。我主动发起并撰写了这次故障的根本原因分析报告（RCA）。在报告中，我不仅复盘了事件，还指出了我们服务架构上的一个弱点：缺少对下游服务查询的熔断和隔离机制。我设计了一个基于 Sentinel 的数据库查询熔断方案，并在接下来的两周内，主导开发并上线了该功能，从架构层面杜绝了类似问题。

Result（结果） 通过我的主导，整个故障在 45 分钟内得到了完全解决，支付成功率恢复到 99.9% 以上，将预估的数百万潜在损失控制在了 50 万以内。更重要的是，我后续推动上线的熔断机制，在接下来的半年里成功自动拦截了 3 次来自下游服务的潜在风险查询，没有再发生任何由类似原因导致的线上故障。这次经历也让我成为了团队里公认的故障处理专家。

低分陷阱（常见扣分点）

• 将"我"的责任归于"团队"：反例：“我们团队很快就响应了告警，大家一起排查问题，最终找到了原因。” —— 面试官无法判断你做了什么，是别人找到的原因还是你？
• 结果含糊不清，没有量化：反例：“项目很成功，问题很快就解决了，避免了很大的损失。” —— “很快”是多久？“很大”是多少？这让你的贡献听起来很廉价。
• 行动部分变成流水账：反例：“我先看了日志，然后看了监控，接着问了同事，最后重启了服务。” —— 这只是操作步骤，没有体现你的思考、决策和领导力。要说清楚你为什么这么做。
• 故事过于简单，缺乏挑战：反例：“我负责的一个功能上线后有个 bug，我熬夜修复了它。” —— 这种日常工作很难体现出“别人都依赖你”的独特性和高压场景。
• 缺乏闭环思维，只解决了眼前问题：只说了如何恢复服务，但没有提及事后的复盘、根因分析和长期改进措施，这会让人觉得你缺乏 Ownership 和系统性思考。

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

1. 追问：在联系订单团队时，如果他们坚持不回滚，你有什么后备计划（Plan B）？

   • 要点 1 (技术降级)：我会立即准备执行技术上的降级预案。比如，如果架构支持，我会通过配置中心动态给订单服务降级，暂时切断它对我们数据库的非核心读写权限，虽然会影响部分订单查询功能，但能优先保障核心的支付链路。
   • 要点 2 (向上汇报)：同时，我会立刻将情况升级给我的直属总监和对方的总监。这不是为了告状，而是为了让更高层级的管理者基于更大的业务视角来做决策，打破部门墙，这是处理跨团队僵局的标准流程。

2. 追问：你说你成为了故障处理专家，这具体体现在哪些方面？

   • 要点 1 (流程和工具建设)：在这次事件后，我主导梳理并完善了我们团队的 on-call 标准操作流程（SOP），并开发了一个小工具，能一键拉取关键服务的核心指标，将故障排查的初始时间从平均 15 分钟缩短到 5 分钟以内。
   • 要点 2 (知识分享和培训)：我组织了两次技术分享，一次是关于这次故障的深度复盘，另一次是关于如何优雅地进行故障处理和沟通。我还为新员工制定了 on-call 培训计划，帮助他们更快地熟悉系统。

3. 追问：你是如何预估那 45 分钟造成了 50 万的损失的？这个数字准确吗？

   • 要点 1 (数据来源)：这个数字是基于历史数据估算的。我们有一个实时监控大盘，可以看到正常情况下平均每分钟的交易额（GMV）。我取了故障前一小时的平均分钟 GMV 作为基线。
   • 要点 2 (计算方法)：具体的计算公式是：(故障前一小时的平均分钟 GMV) * (45 分钟) * (支付成功率下跌的百分比)。这当然是一个估算值，但它为我们评估故障的严重性和向管理层汇报提供了一个快速、可量化的依据。事后我们也通过对比当天和前几周的同期数据，验证了这个估算在合理的数量级内。

故事复用建议

这个故事非常扎实，除了回答 "Describe a time you were the person others depended on"，还可以根据不同的侧重点，复用到以下问题：

• Ownership: 整个故事的核心就是你主动承担责任，从头到尾解决问题并推动长期改进。
• Deliver Results: 在高压下交付了明确、量化的业务成果。
• Bias for Action: 面对危机时，没有犹豫，迅速行动并做出关键决策。
• Dive Deep: 深入到数据库层面去分析慢查询，并设计了架构级的解决方案。
• Earn Trust: 通过清晰的沟通和数据，赢得了其他团队和管理层的信任。
• Are Right, A Lot: 在高压下做出了正确的判断（定位问题、回滚决策）。