一句话总结
在亚马逊，遗留系统不是需要被立刻清除的技术债务，而是承载着核心业务逻辑与高额迁移成本的商业既得利益体。平庸的产品经理试图通过全面重构来证明自己的存在感，而顶尖的亚马逊产品经理则通过控制爆炸半径、解耦依赖关系和设计向后兼容的网关，在不触动核心代码的前提下实现业务增长。
能否成功驾驭并逐步蚕食这些复杂的遗留系统，是决定一个产品经理在亚马逊是止步于L5/L6，还是晋升为L7/L8 Principal PMT的分水岭。
适合谁看
本文适合正在准备亚马逊L6/L7 PM/PMT面试，需要在Loop中展现出深厚系统架构理解与跨团队协作能力的资深候选人。同时，也适合刚刚加入亚马逊、面临复杂的内部服务依赖而感到寸步难行的新晋产品经理，以及在大型科技公司工作，深陷重构泥潭却无法推动跨团队配合，急需一套可落地、可量化的系统迁移与解耦框架的资深产品专家。
为什么亚马逊的遗留系统不是技术债务，而是商业护城河？
在亚马逊的工程世界里，很多刚入职的PM会犯一个常识性错误：把那些运行了十年以上、使用陈旧框架、文档缺失的系统定义为技术垃圾。他们看着那些臃肿的Coral服务或早期的Sable存储，心中充满了技术洁癖式的鄙夷，恨不得立刻写一份1-Pager将其全部重构。这种想法不仅幼稚，而且极其危险。
亚马逊的遗留系统不是技术落后的产物，而是业务极度成功的历史见证。这些系统在过去的十几年里，支撑了数亿次的高并发调用，经历过了无数次双十一和Black Friday的极限压测。更重要的是，它们内部沉淀了极其复杂的业务规则。
这些规则包括了不同国家之间复杂的跨境税率计算逻辑、历史遗留的特殊退款渠道处理、以及针对特定大客户的定制化结算协议。这些细节根本没有记录在任何PRD中，它们唯一的载体就是那些正在运行的、看起来丑陋的代码。
在亚马逊，处理遗留系统不是一个技术重构问题，而是一个多方利益博弈的组织行为学问题。当你提议重写一个Tier-1的结账服务时，你面对的不是几万行代码，而是每年数百亿美元的GMV流动。亚马逊的系统设计原则是高可用和极致的低延迟。一个Tier-1的服务，每延迟100毫秒，就意味着1%的销售额流失。在这样的背景下，任何激进的重构都是对股东利益的渎职。
这些看似老旧的系统实际上构成了亚马逊的商业护城河。它们运行成本极低，折旧已经完毕，且极其稳定。优秀的亚马逊PM会意识到，你的价值不是去寻找完美的终极架构，而是去寻找系统在当前业务增速下的临界承载点。
你必须学会与这些遗留系统共存，将其视为一种既定的物理定律，而不是可以随意抹去的草稿。只有理解了这一点，你才能在写6-Pager时，把重点从技术美感转向业务连续性和风险控制。
> 📖 延伸阅读：PM Salary Comparison: Google vs Amazon
亚马逊PM在面对老旧系统时，最致命的认知偏差是什么？
大多数在亚马逊折戟沉沙的PM，都死于一种救世主心态。他们带着前公司的光环，拿着优渥的薪资，急于在第一个季度交付成果。当他们发现现有的业务流程受限于一个十年前的Legacy System时，他们的本能反应是：这个系统太烂了，上游团队不作为，我们需要重新发起一个项目，用最新的AWS无服务器架构重新写一套。
这种认知偏差的致命之处在于，它忽略了亚马逊的去中心化组织架构（Two-Pizza Teams）所带来的极高协同成本。在亚马逊，没有一个中央决策机构可以强迫十五个不同的团队配合你进行系统迁移。
每一个团队都有自己的OP1（年度业务规划）和核心指标。当你在1-Pager里写道，这个重构能让我们的系统架构更加现代化，其他团队的PM和SDM只会冷笑着把你的需求排到最低优先级。
在亚马逊的组织文化中，优秀的PM不是去寻找完美的终极架构，而是去寻找系统在当前业务增速下的临界承载点。不是因为旧系统代码优雅，而是因为它在过去十年里经历过了无数次Sev-2（二级故障）的洗礼，把所有能踩的坑都踩过了。新系统在没有经历过同等量级的流量洗礼前，它的稳定性在Bar Raiser和Principal Engineer眼里就是一个巨大的问号。
让我们来看一个真实的场景。一个L6 PMT在汇报新项目时说：由于旧的Order Pipeline系统限制了我们新增促销属性的灵活性，我建议启动一个为期六个月的重构计划，将该模块彻底迁移到DynamoDB上。这种汇报在亚马逊的Debrief会议上会被直接判死刑。
正确的认知和汇报方式应该是：我们面临的瓶颈是促销属性的扩展性问题。为了在不触动核心Order Pipeline的前提下实现这一业务目标，我们将在外围构建一个Metadata Adapter。通过这个适配器，我们可以在不改变旧系统Schema的前提下，实现新促销属性的注入。这不仅将项目的交付时间从六个月缩短到两周，还将整体系统的爆炸半径控制在万分之一以内。
这就是本质的区别：平庸的PM试图通过改变世界来解决问题，而优秀的PM则通过精妙的解耦和妥协，在旧世界的框架内优雅地拿到业务结果。
如何在不重构系统的前提下，推动跨团队的Legacy迁移？
在亚马逊，推动跨团队的项目迁移是一门高级的行为艺术。当你的业务发展被上游的遗留系统卡住，而对方团队明确表示没有排期配合你时，你绝对不能寄希望于向VP告状。在亚马逊的扁平化管理体制下，VP只会让你和对方团队去写一份COE（错误纠正报告）或在OP1中重新对齐。
最有效的战术是采用绞杀者模式（Strangler Fig Pattern）。这种模式的核心思想是：不要试图去拆除那座旧大楼，而是在旧大楼旁边建新楼，然后把旧大楼里的居民分批、无感地转移过来，最后让旧大楼自然荒废。
具体的落地步骤需要PM在文档中极其精确地定义。首先，你需要在遗留系统和你的新业务之间设计一层薄薄的API网关或适配层。这层网关的作用是双向翻译：对内，它用最现代化的JSON协议和微服务架构与你的新功能通信；对外，它用陈旧的XML或SOAP协议与遗留系统交互。
在这个过程中，PM必须扮演好数据侦探的角色。你需要拉上SDE-III去梳理那份可能已经五年没更新过的Data Dictionary。你不能指望别人给你提供现成的API文档，你必须主动去翻看旧系统的DDB（DynamoDB）表结构，甚至去分析S3里的历史Log。
当你准备开始迁移流量时，你必须设计一个严密的双写（Dual-write）和影子流量测试（Shadowing）方案。在debrief中，Principal Engineer最关心的问题永远是：如果新系统挂了，你如何一键回滚（Rollback）？
你的6-Pager里必须有一章专门阐述Rollback Plan。具体的设计是：新旧系统同时接收线上流量，但新系统的输出仅用于比对（Verification），实际的业务决策仍然由旧系统做出。当比对结果在连续两周内达到五个九（99.999%）的一致性时，你才开始以1%、5%、20%、100%的梯度将实际读写流量切换到新系统。
在推动跨团队配合时，你沟通的筹码不是你的业务有多重要，而是你能帮对方省去多少维护成本。你需要拿着数据去找对方的SDM：如果我们完成这个适配器的建设，你们团队每年因为这个旧模块产生的Sev-2工单将减少40%，你们的On-call压力将大大降低。只有把你的迁移目标转化为对方的减负指标，你才能在没有行政命令的情况下，撬动其他团队的工程资源。
> 📖 延伸阅读：[](https://sirjohnnymai.com/zh/blog/zh-**-buying-decision-amazon-pm-interview-playbook-vs-coaching-2026)
亚马逊面试中如何向Bar Raiser证明你具备处理复杂遗留系统的架构思维？
在亚马逊的Loop面试中，Bar Raiser（BR）是决定你生死的人。BR通常是一个经验极其丰富的其他部门的总监或资深PM，他们对虚无缥缈的技术概念天然免疫。当你在System Design或Behavioral面试中提到你主导过系统重构时，BR的雷达会立刻拉响。
BR最喜欢追问的，不是你用了什么时髦的技术栈，而是你在面临新旧交替时的决策框架和折中方案（Trade-offs）。他们想听的不是你如何用一个完美的现代化系统替代了旧系统，而是你如何在保留核心业务逻辑的前提下，以最低的摩擦成本完成数据的平滑过渡。
在回答这类问题时，你必须使用极其具体的数字和场景来构建你的STAR故事。你需要精准地说出当时的系统负载：当时的TPS（每秒事务数）是多少？数据的Blast Radius（爆炸半径）有多大？如果系统宕机一分钟，会给公司带来多少万美金的损失？
在描述你的行动（Action）时，不要使用“我们团队决定重构”这种模糊的词汇。你必须明确指出你作为PM在其中的独特价值：是我通过分析过去六个月的Sev-2工单，发现80%的故障都集中在旧系统的订单状态机（State Machine）上，从而说服了SDM放弃整体重构，转而只针对状态机进行解耦。
是我主持起草了数据迁移的Backward Compatibility协议，确保了上游二十个依赖团队在零感知、零修改代码的前提下，完成了底座的平滑升级。
如果在面试中，你表现出对技术债务的极度排斥，一味地贬低前人留下的系统，BR会认为你缺乏组织同理心（Organizational Empathy）和务实精神。在亚马逊看来，一个优秀的PMT不仅要懂技术，更要懂得在商业限制、时间压力和技术不完美之间寻找最优解。你需要向面试官证明，你具备在泥泞中前行的能力，而不是只有在白纸上画画的本事。
真实的Amazon Loop面试是如何拆解遗留系统处理能力的？
在亚马逊针对L6/L7 PMT的正式Loop面试中，评估候选人对遗留系统和复杂架构的处理能力是一项系统性工程。整个面试流程通常由一轮Phone Screen和五轮Onsite Loop组成，每一轮都经过精心设计，背后有着严格的考察维度和时间分配。
第一轮是电话初筛（Phone Screen），时长60分钟。这一轮通常由Hiring Manager或同组的资深PMT主持。前10分钟用于破冰和背景对齐，接下来的45分钟会直接切入一个与系统设计或遗留系统迁移相关的实际案例。
面试官会给出类似这样的场景：我们的核心支付系统是一个单体应用，现在需要上线一个新的订阅付费功能，但旧系统无法支持高频的扣款尝试，且开发排期需要一年。你作为PM如何解决？最后5分钟留给候选人提问。
通过初筛后，候选人将进入最残酷的Onsite Loop，共五轮，每轮60分钟，分别对应不同的考察重点：
第一轮：System Design / Technical Integration（技术系统设计）。这一轮不考写代码，而是考察你对大系统架构的理解。面试官会要求你设计一个类似Amazon Prime Day期间的流量分流与降级系统。
你必须在白板上清晰地画出负载均衡、缓存层、消息队列以及最核心的——如何处理那些无法承载高并发的后端遗留数据库。时间分配上，前10分钟明确业务场景和非功能性需求（如延迟、可用性），中间40分钟进行架构设计与深度追问（Deep Dive），最后10分钟讨论容灾与回滚策略。
第二轮：Dive Deep & Deliver Results（深入免俗与交付结果）。这一轮主要考察你在复杂、模糊环境下的数据分析和落地能力。面试官会深挖你简历中写过的最复杂的一个项目。
你必须准备好回答：你当时是如何定义关键指标的？你如何通过数据发现遗留系统中的性能瓶颈？当项目因为技术债务延期时，你采取了什么 Bias for Action 的行动来确保按时交付？
第三轮：Customer Obsession & Invent and Simplify（客户至上与开拓创新）。遗留系统的存在往往损害了客户体验，但重构又会带来短期风险。这一轮考察你如何在客户体验和系统稳定性之间做平衡。面试官会观察你是否能提出创新的、轻量级的解决方案来绕过系统限制，而不是直接向客户说不，或者给出一个两年的重构计划。
第四轮：Bar Raiser Round（BR轮）。BR通常由不属于招聘部门的资深高管担任。他们会以极其严苛的视角审视你的综合素质。
BR最喜欢问的问题是：在你过去的项目中，有没有哪一次你力排众议，阻止了一次看似合理的技术重构？或者你如何说服一个极其保守的架构师接受你的增量迁移方案？这一轮的核心是考察你的组织影响力（Influence without Authority）和商业判断力。
第五轮：Hiring Manager Round（业务负责人轮）。这一轮侧重于文化契合度（Culture Fit）以及你对未来团队具体业务的理解。HM会直接评估你入职后，面对他们部门当前最头疼的那个遗留系统，你是否能立刻上手，并开始写出合格的1-Pager。
在整个Loop中，面试官会连续使用5个Why的追问机制，层层剥离候选人话语中的水分。如果你在任何一轮中表现出对技术细节的模糊，或者试图用高大上的架构名词糊弄过去，在随后的Debrief会议中，这些疑点都会被无限放大，最终导致被一票否决。
准备清单
系统性拆解面试结构。PM面试手册里有完整的Amazon L6/L7 PMT系统设计与遗留系统迁移实战复盘可以参考。通过这些真实的案例来训练自己的架构直觉。
梳理你过去项目中的技术指标。准备好三个核心项目的技术底数：当时的TPS峰值、数据存储规模（TB/PB）、系统平均延迟（Latency p99/p99.9）以及你做迁移时的爆炸半径控制方案。
熟练掌握绞杀者模式（Strangler Fig Pattern）的工程落地细节。能够清晰地在白板上画出API Gateway、数据双写、影子测试以及灰度发布的数据流向图。
准备一个关于妥协的Behavioral故事。这个故事必须展示你如何在面临业务压力和技术不完美时，主动选择了一个不完美但能最快交付业务价值的技术方案，并清晰阐述你后续偿还技术债务的计划。
熟悉亚马逊的写作文风（Narrative Culture）。练习将一个复杂的技术重构项目，缩写成一段不超过两百字的、符合亚马逊风格的1-Pager摘要，重点突出业务价值、风险控制和可量化的交付结果。
深入理解亚马逊的L6/L7薪资结构。以便在最终的Offer谈判中拿到符合预期的包。
目前硅谷Amazon L6 PMT的合理薪资范围为：Base $185,000，年均股票RSU $160,000，第一年签字费Bonus $65,000，首年总包约 $410,000；
L7 Principal PMT的薪资范围为：Base $225,000，年均股票RSU $310,000，第一年签字费Bonus $95,000，首年总包约 $630,000。
常见错误
错误一：在6-Pager中提议全量重写（Big Bang Rewrite）
在面对一个陈旧的订单对账系统时，PM在文档中写道：“由于现有系统采用的是过时的批处理模式，且数据库设计不合理，我们计划在接下来的两个季度内，停止新功能开发，集中精力用Serverless架构重新设计并替换该系统。”
这种方案在亚马逊的评审会议上会被直接毙掉。因为对于核心对账系统来说，停止新功能开发两个季度意味着业务停滞，而全量重写带来的上线风险是无法估量的。一旦新系统在上线当天出现数据丢失，造成的财务损失和合规风险是灾难性的。
正确的做法是采用增量迁移方案。PM应该在文档中这样表述：“我们将在现有批处理系统的前端，引入一个轻量级的事件监听器。该监听器只捕获新增的、高价值的订单类别，并将其分流到新的Serverless微服务中进行实时对账。
旧的批处理系统继续处理占总量80%的历史常规订单。通过这种方式，我们可以在不影响核心业务的前提下，在第一周就验证新架构的可行性，并计划在后续的四个季度中，以每个季度20%的进度逐步完成剩余订单类别的迁移。”
错误二：在面试中把系统无法推进的责任推卸给技术债务
在Behavioral面试中，当被问到“你经历过的最艰难的项目迁移是什么”时，候选人回答：“我当时负责迁移一个遗留的客户画像系统，但是前人留下的代码实在太垃圾了，没有任何文档，而且原来的技术架构非常混乱。更糟糕的是，上游团队的SDE极其不配合，导致我们的项目延期了三个月。这完全是因为前人留下的技术债务太重了。”
这种回答犯了亚马逊的大忌。面试官听到的是一个缺乏主人翁精神（Ownership）、遇到困难只会怨天尤人、且无法在没有授权的情况下施加影响力的平庸PM。
正确的回答方式应该是主动承担责任，并展现解决复杂局面的系统性方法：“当时面临的挑战是，我们需要在一个没有文档、且核心开发者已经离职的遗留客户画像系统上进行升级。为了打破这个僵局，我首先组织了一次跨团队的架构梳理会议，通过分析线上日志，逆向绘制了系统的数据流图。同时，我发现上游团队之所以不配合，是因为他们也深陷该系统的Sev-2泥潭。
于是，我将我们的迁移方案进行了调整，主动承担了他们一部分的接口重构工作，帮助他们将日常维护工单降低了30%。通过这种双赢的方案，我们成功争取到了他们的配合，在没有影响线上服务的前提下完成了平滑迁移。”
错误三：忽视向后兼容性（Backward Compatibility），导致上线后出现严重故障
在上线一个新的商品属性服务时，PM认为这是一个内部服务，不需要考虑太复杂的兼容问题，于是在PRD中直接废弃了旧接口中的三个字段。结果上线后，导致了下游一个未被统计在依赖列表中的、运行了八年的老物流系统崩溃，引发了Sev-1级事故，仓库发货受阻数小时。
这个案例暴露了PM在面对复杂遗留系统时，对爆炸半径（Blast Radius）和依赖关系（Dependency）缺乏最基本的敬畏。
正确的做法是坚持向后兼容的黄金法则。PM应该在设计之初就明确要求：“新服务必须完全兼容旧接口。所有被废弃的字段不能直接删除，而是必须保留并赋予默认值，同时在新系统的日志中对调用旧字段的请求进行标记（Deprecation Log）。我们需要在后台监控
更多PM职业资源
探索来自硅谷产品负责人的框架、薪资数据和面试指南。
更多PM职业资源
探索来自硅谷产品负责人的框架、薪资数据和面试指南。
更多PM职业资源
探索来自硅谷产品负责人的框架、薪资数据和面试指南。
FAQ
面试一般有几轮？
大多数公司PM面试4-6轮，包括电话筛选、产品设计、行为面试和领导力面试。准备周期建议4-6周，有经验的PM可压缩到2-3周。
没有PM经验能申请吗？
可以。工程师、咨询、运营转PM都有成功案例。关键是用过往经验证明产品思维、跨团队协作和用户洞察能力。
如何最有效地准备？
系统化准备三大模块：产品设计框架、数据分析能力、行为面试STAR方法。模拟面试是最被低估的准备方式。