方案评审常出现这样的场面：讲解者把架构图上的组件介绍完，听众却仍不知道为什么应该批准。接着有人问“促销期间有 1 个可用区不可用怎么办”，讲解者开始翻找备份页面。问题并不只是表达不够流利，而是方案中的需求、选择、证据和责任没有连成可以检查的推理。本课练习把已有的技术方案讲成可讨论、可反驳、可行动的决策说明。
全课沿用零售订单 API：顾客提交订单，系统校验请求，把订单与受理记录持久化，再返回订单编号；后续履约由异步任务推进。为便于练习，约定促销峰值为每秒 800 次提交，正常情况下提交响应的 P95 不超过 300 毫秒，月度可用性目标为 99.9%。这些都是案例假设，需要业务方确认，不代表任何系统都应采用相同指标。支付扣款通过独立支付流程处理，本课不把“订单已受理”说成“支付已成功”。
1 方案讲解与答辩要回答什么
方案讲解首先回答“今天要做什么决定”。本次评审的决定可以是：批准订单 API 的总体方向和 POC 资源，但暂不批准生产上线。这样的开场把听众的注意力放在选择及其条件上。若只说“介绍订单架构”，有人会按预算评估，有人会按上线验收提问，还有人会把它当技术分享。相同的页面落在不同目的下，会得到完全不同的评价。
接下来要回答“为谁解决什么问题”。零售业务希望促销时可以持续接单，客服希望能按订单编号解释状态，运维希望故障期间有明确的处置边界。它们需要翻译成可检查的要求：接口的响应目标、可接受的恢复时间、已受理订单的保护范围，以及状态查询的可解释性。不要把“高性能、高可靠、低成本”直接当验收条款，这些词没有说明观察对象，也没有规定何时算失败。
本案例把成功响应定义为：服务端已经保存订单和后续处理所需的受理记录。异步任务尚未完成时，接口可以返回“已受理”，查询结果继续显示“处理中”。因此，答辩时必须分别说明接单能力与履约能力。若后台处理暂停 10 分钟，接单接口仍可能满足延迟目标，但业务积压已在增加。把这 2 类状态合并成绿色的“系统正常”，会让评审者误判方案的保护范围。
还要回答“为什么选这个方向，以及没有证明什么”。提出跨可用区部署时，应说明它针对哪个故障假设，是否覆盖共享数据库，切换是否依赖人工。提出备份时，应说明它主要用于数据恢复，不能直接证明服务连续可用。对尚未验证的结论可以明确标为待验证，并给出验证入口；不能用“后面压测”替代对当前方案依据的解释。讲解者的职责是让判断有边界，而不是消除所有不确定性。
最后回答“谁据此采取什么行动”。业务负责人确认需求优先级，架构负责人确认选项和约束，运维负责人确认演练与值守责任，预算负责人确认成本口径。每个决定都应留下负责人和完成条件。例如，评审可以接受推荐方向，同时要求在 POC 中证明跨区访问的延迟影响。这样得到的是有条件的推进结论，而不是含义模糊的“原则同意”。
2 叙事主线与关键取舍
推荐采用“需求与约束 → 可行选项 → 决策及代价 → 证据与下一步”的主线。每次切换页面都应保持同 1 个问题：这段信息怎样影响今天的决定。开头用顾客提交订单的路径交代业务，再呈现约束，随后比较部署选择，最后说明风险与 POC。图可以很简洁，但图上的每条关键连接都应能解释数据如何前进、失败时谁负责，以及成功响应意味着什么。
本案例比较 3 个选项。选项 A 为单可用区部署，成本较低，运维路径较短，但整个可用区故障会中断接单。选项 B 为同城 2 个可用区部署，应用跨区运行，数据库采用有明确故障切换能力的跨区部署，增加资源和演练成本。选项 C 为跨地域部署，需要处理更长的网络路径和更复杂的流量切换，也更容易引出数据同步边界。比较应按相同的业务范围进行，不能把 A 的完整费用与 B 的应用服务器费用直接并列。
练习中推荐 B，前提是业务确认“单个可用区故障后，应在 15 分钟内恢复接单”，并接受相应预算。已返回成功的订单，在约定的单可用区故障范围内，以不丢失为目标；灾难恢复另暂定 RPO 不超过 5 分钟、RTO 不超过 60 分钟，仍需业务确认和验证。RPO 表示可接受的数据恢复点差距，RTO 表示恢复服务所需的时间目标。把故障范围与目标一起说，才不会让“跨区”被听成对所有事故的保证。
这项决定应写成 ADR，即架构决策记录。记录背景、候选项、采用项、主要理由、代价和重审条件即可。例如，选择 B 的理由是覆盖单可用区故障；代价包括跨区流量、冗余容量和定期切换演练；若地域级中断的业务损失明显上升，就重新评估 C。ADR 不是给推荐方案盖章，而是保留当时为什么这样选，使后续条件变化时可以重新判断。
成本讲解也要沿着决策展开。先给相同口径下的月度区间，再列出差额来自哪里，包括计算、数据库、存储、网络、监控和运维投入。固定资源费用与随请求量变化的费用应区分开，并写清请求量与日志保留期等假设。用归一化成本单位演示取舍即可，实际报价要另行核算。资源增加不等于可用性按比例增加，额外费用究竟购买了哪种故障下的恢复能力，才是需要说明的内容。
讲述时可用 1 句话贯穿全程：“我们在已确认的订单受理语义下，为覆盖单可用区故障选择 B，以增加跨区资源和演练投入为代价，先通过 POC 验证容量与切换。”这句话能被逐项追问，也能被逐项修正。它比“采用先进架构保障高可用”更适合评审，因为其中的需求、范围、代价和验证动作都有具体对象。
3 质疑、证据与备选
听到质疑时，先辨认对方在检查哪个决策点。“为什么不用单区”可能是在问预算，也可能是在问双区是否真的覆盖故障。“能保证不丢单吗”可能是在问成功响应的定义，也可能是在问地域灾难。先复述问题的范围，再回答结论，能避免答了很多细节却没有回应担忧。范围不清时，可以把不同含义拆开说明，并指出本次已有证据覆盖哪部分。
证据应和具体主张配对。主张“接口满足延迟目标”，需要注明测试环境、请求构成、并发或到达速率、观测窗口和失败率。主张“可用区故障后能够恢复”，需要有带时间记录的演练过程，说明故障发生、发现、切换以及恢复接单分别发生在什么时候。设计图可以说明打算如何工作，却不能独立证明实际达标；公开文档能说明某能力的设计边界，也不能替代本系统的组合验证。
案例中可先建立证据表：每秒 800 次提交是业务预测，暂为假设；跨区访问增加多少延迟，暂缺本系统测量；订单与受理记录的持久化边界已有设计说明，尚待故障测试；单区恢复 15 分钟的目标需要演练。每条信息标明来源、日期和适用范围。不要把预测写成实测，也不要让过期环境的结果继续支撑新配置。评审最需要看清的，往往正是哪些结论已经可靠，哪些仍可能改变选择。
回答可采用“结论、依据、边界、行动”的顺序。例如：“当前不能证明单区故障后 15 分钟内恢复。设计上应用与数据库都有跨区路径，但尚未验证共享依赖和切换耗时。我们将把该项列为 POC 的阻断条件，由运维负责人组织演练，达标后再申请上线评审。”这既没有回避问题，也没有把未完成的工作包装成事实。若只有设计依据，就如实停留在设计层面。
备选方案要能触发，而不只是被列在附录。若 B 的跨区延迟使正常路径无法达标，先核查请求路径是否存在多余调用；若仍不满足，则需要重新评估性能目标或部署选择。若预算不支持 B，可以退回 A，但必须同时说明故障暴露和业务接受条件。不能在删掉冗余资源后仍沿用原来的可用性承诺。有效备选需要包含触发条件、切换代价、批准人和重新验证内容。
当提问超出本次范围时，也应留下可追踪的落点。例如，支付渠道故障虽然不在订单受理接口的直接范围内，却会影响订单后续状态，应登记为外部依赖风险。可以说明现阶段通过状态区分和超时处理保持可解释性，具体支付补偿策略另行设计。这里先建立“依赖可能失败、状态需要表达”的认识，不展开复杂的一致性算法和内部复制机制。
4 动手：准备三问三答
准备 1 页练习纸，上方写本次决策，下方按业务、技术和成本各准备 1 个问题。练习目标不是背出固定台词，而是检查回答是否包含结论、依据、边界和行动。先独立准备，再请同伴只依据回答追问。每次回答控制在 60 秒左右，细节放到附录。若需要连续翻阅多张页面才能说明推荐理由，通常意味着主线或证据索引还没有整理好。
第 1 问：“促销高峰时，为什么相信订单接口撑得住？”示例回答是：“目前每秒 800 次提交来自业务预测，尚未证明系统能够稳定承载。POC 将使用接近真实的请求构成，在持续负载下同时观察 P95、失败率、数据库写入和异步积压，并单独覆盖促销热点。只有响应速度与受理正确性同时达标，才能确认容量方向。”回答中的预测和证据被明确区分，没有拿服务器数量直接替代容量结论。
第 2 问：“已有跨区应用实例，为什么还需要额外演练？”示例回答是：“应用实例跨区只覆盖部分故障路径。数据库、流量入口以及配置依赖仍可能共同影响接单。演练需要证明剩余路径能够访问已受理订单，承担约定负载，并在 15 分钟内恢复接单；如果无法满足，就不能沿用该恢复承诺。”接下来可以用失败路径图指出测试对象，而不是继续堆叠组件名称。
第 3 问：“为什么要支付额外成本，能否先采用单区？”示例回答是：“可以把单区作为备选，但它暴露整个可用区故障导致的接单中断。推荐双区是为了覆盖已提出的故障目标。费用差额包括冗余容量、跨区流量与演练投入，当前仍为区间估算。若业务正式放宽恢复目标，并接受中断损失，才重新比较单区选项。”这使预算讨论回到业务接受条件，而不是争论哪个方案听起来更高级。
完成初稿后做 2 轮练习。第 1 轮由同伴标出回答中的事实、假设和承诺；第 2 轮只追问缺少依据的承诺。比如“切换后肯定不会重复下单”需要补充客户端重试、幂等标识与持久化边界的说明。这里的幂等是指同 1 次业务提交在重试后不被当成多笔新订单处理。具体实现可留到后续设计，但答辩不能忽略这一业务语义。
最后把无法在 60 秒内解释清楚的问题写入待办。待办至少包含原问题、当前结论、证据缺口、负责人和完成时点。不要只写“继续优化性能”之类无法关闭的句子。可改写为“在 POC 环境验证单区退出后每秒 800 次提交的受理结果与响应指标，并记录恢复耗时”。这个动作会把口头练习产出转成后续实验的输入。
5 细节深度与时间取舍
细节深度由决策需要决定。业务负责人需要知道订单何时算受理、故障时顾客看到什么，以及中断损失如何取舍；技术负责人需要知道关键依赖、失败域和容量假设；运维负责人需要知道告警、切换、回退与责任。面对混合听众，可以共用 1 条主线，再为不同问题准备附录入口。不要为每类听众重讲整套架构，否则有限时间会被重复背景消耗。
假设有 15 分钟讲解时间，可以分配 2 分钟说明目标与约束，4 分钟比较选项和推荐理由，4 分钟解释关键路径、故障范围与证据，3 分钟说明成本和风险，2 分钟提出待决事项。问答另留时间。这个分配只是起点：若本次主要争议是故障恢复，应把更多时间给失败路径，而不是坚持平均分配。被打断后，先回应决策相关问题，再回到当前主线节点。
需要进入正文的细节通常会改变选择。例如，剩余可用区能否承担目标负载，会影响是否需要更多备用容量；数据库是否能跨区切换，会影响故障覆盖是否成立。连接池的具体参数和内部复制流程，则通常不必在初次讲解展开，除非已有证据表明它们正是瓶颈。入门答辩要理解机制的作用和边界，复杂实现留给专门设计与验证，不靠术语密度证明专业程度。
成本页面尤其容易占满时间。可以先展示固定项、变动项和运维投入，再用敏感性分析解释哪些假设改变结果。下面的滑块只调整“单区退出后需承受的目标峰值比例”，展示它对简化计算资源成本的影响。比例越高，平时保留的容量越多；比例降低则需要明确业务降级。它不计算可用性，也没有包含数据库、网络等费用，不能拿它输出的数值当采购预算。
使用滑块时，讲解者应先说判断规则，再移动参数。例如：“当前业务要求故障期间仍可完整接单，因此先比较 100% 的目标。若只预留 75%，就需要确认高峰时可能延迟或拒绝的请求如何处理。”这里的 75% 是容量假设，不代表有 25% 的订单必然丢失。流量分布、排队和限流都会影响实际结果，需要实验观察。图形负责帮助讨论代价，证据负责判断行为。
结束前保留足够时间复述待决事项。若听众只记住“采用双区”，却没记住需求尚待确认、故障切换尚待验证，讲解就丢掉了最重要的边界。可以在最后 1 页同时展示推荐、已知代价、未解决风险和申请批准的内容，让评审者明确这次签字推进到哪个阶段。未得到回答的问题，应进入记录，而不是随着会议结束消失。
6 常见坑：念稿不回答决策点
第 1 类坑是按组件清单念稿：“这里有网关，这里有服务，这里有数据库。”听众能够看见图上的方框，却仍不知道每个组件服务于哪个要求。改法是沿 1 次下单讲解：请求在哪里被识别为重试，订单在哪里持久化，成功响应从哪里返回，后台处理失败后状态如何保留。介绍组件时附带它在决策中的作用，图才会成为解释工具。
第 2 类坑是把目标当结果。“要求 99.9% 可用”并不等于“系统已达到 99.9%”。月度目标还需要明确观测入口、成功标准、统计窗口和排除条件。假如入口持续返回成功，但受理记录未保存，就不能把这些请求计为正确完成。可用性目标、容量测试和故障演练分别回答不同问题，不能用 1 次短压测同时证明所有长期承诺。
第 3 类坑是只报平均延迟，或只报故障恢复后的单点结果。平均值可能掩盖少量顾客经历的长等待，恢复后的绿色状态也可能掩盖中间已经发生的失败和重复提交。应展示与目标对应的指标，并给时间线。即使采用 P95，也还要同时关注失败率与订单受理正确性。统计数字必须能回到顾客看到的行为，否则看似精确的报表也可能偏离业务问题。
第 4 类坑是把备份、冗余和切换混作“已经高可用”。备份帮助恢复历史数据，冗余提供额外运行路径，切换决定故障后如何使用这些路径。它们相互配合，但任何 1 项都不能独立替代完整故障处理。若备用应用依赖同 1 个故障区的数据库，增加应用实例无法解决数据库不可达；若恢复过程需要人工却没有值守责任，恢复时间也不能仅凭配置估计。
第 5 类坑是在追问下临时增加承诺。为了显得准备充分，讲解者可能把原来的“尽力恢复”改口成“自动切换无感”，却没有证据或预算支持。正确动作是保持已确认的边界，说明新增要求将影响哪些设计与验证项，再记录为变更。答辩不是即时竞答，允许存在未确定事项；真正损害可信度的是把未确定事项说成已经解决。
第 6 类坑是把每个质疑都当成反对。预算方追问差额，可能是在准备批准理由；运维方追问回退，可能是在确认值守安排。可以先用简短结论回应，再提供可定位的证据页，并确认问题是否已得到解释。若证据仍不足，及时登记缺口。不要以“这是行业惯例”结束讨论，因为通用做法不能自动证明它适用于当前负载、团队与恢复目标。
7 案例：被问到失败域无答案
评审中，讲解者展示了 2 个可用区的应用实例，并说“任意 1 个区故障都可以继续接单”。评审者追问：“数据库主节点、异步任务和流量入口分别在哪？剩余区有多少容量？”讲解者只知道应用副本跨区，不清楚数据库切换方式，也没有剩余容量数据。此时应撤回过宽的结论，说明现有材料只能证明应用部署分散，尚不能证明订单受理路径整体覆盖单区故障。
失败域是可能被同 1 次故障共同影响的一组资源。可用区是常见的基础设施失败域，但共享配置错误、同批发布和错误权限也可能同时影响多个区。本次先分析单区不可用，不展开所有事故类型。沿下单路径给每个关键依赖标出所在位置和恢复方式，就能看到“图上有 2 份”与“故障后有完整可用路径”之间的差距。
现场可以画出故障后的路径：流量入口把请求送往剩余区，应用访问可用的数据库写入端，保存订单与受理记录，然后返回结果。后台处理可以暂时积压，但必须有容量边界、告警与后续恢复计划。如果数据库端点仍指向故障区，接单路径就在持久化步骤中断；如果剩余应用容量不足，则可能出现超时或受控限流。把这 2 类问题分开，才能安排不同验证。
进一步追问时，应检查“失败”和“重试”相遇的位置。某次订单写入已经成功，但响应在网络中丢失，顾客会重试。系统需要根据同 1 个业务提交标识返回已有结果，避免重复建单。另外，若请求根本没有持久化，就不能凭缓存中的临时状态告诉顾客已受理。这里先要求讲清边界与可观察结果，具体事务、消息投递与去重机制在后续技术设计中展开。
修订后的答辩结论可以是：“双区方案方向保留，但单区故障下的持续接单仍是待验证项。当前缺口为数据库切换、剩余容量和重试语义；POC 必须记录故障前后订单明细、响应结果和恢复时间。若关键依赖无法跨区恢复，则重新设计或重新协商目标。”这比简单补画备用数据库更完整，因为它同时修正了主张、设计检查项和批准条件。
这次案例留下的经验是：不要从图形对称推断能力对称。即使 2 个区的资源数量相同，也可能因共享依赖、流量切换方式或数据状态不同而表现不同。评审后应由架构与运维共同补齐依赖清单，把每条未知路径转成可验证的问题。若新增发现改变了成本与恢复条件，还要同步更新 ADR，避免讲解稿修正了，正式决策记录仍保留旧承诺。
8 把讲解结构写进答辩准备
答辩准备应形成 1 份可交接的材料，而不只是一套个人熟悉的幻灯片。首页写明评审目的、推荐选项、关键假设和请求批准的内容。其后保留业务路径、选项比较、ADR 摘要、成本口径、风险与验证安排。每页标注它回答哪个问题，例如“为什么选择 B”“单区故障覆盖到哪里”。这样的标注能帮助删掉与本次决定无关的页面。
建立证据索引时，用稳定的编号关联主张与材料。例如 E01 是业务峰值预测，E02 是当前正常路径测试，E03 是待执行的故障演练计划。编号只用于定位，不能让待执行计划看起来像已经完成的实测。每项应有版本、日期、环境和负责人；若测量依赖尚未确认的请求构成，也要把这个条件写在结论旁边，避免附录里的限制在转述时丢失。
风险登记可以保持简短，但必须有关闭条件。“数据库切换未验证”是风险描述，“运维负责”是责任归属，“完成指定故障演练且核对订单结果”才是可以检查的关闭条件。还应区分阻断上线的事项与允许在限制范围内继续推进的事项。是否接受风险由具备权限的负责人决定，讲解者不能通过弱化措辞把阻断项变成普通提醒。
问答记录也要保存决策影响。有人提出“故障时允许只接收 75% 的峰值负载”，记录不能只写“讨论容量”。应写明这是待业务确认的降级提议，可能改变冗余容量和预算，但尚未替代原目标。若获得批准，要同步更新需求、成本估算与 POC 通过标准。评审结论必须与正文和附件使用同 1 组假设，否则不同团队会按不同版本推进。
最后做 1 次脱稿复述：不用翻页，在 2 分钟内说明业务问题、推荐理由、最大风险和下一步。如果只能记住组件名，说明推理主线还不够清楚；如果说不出什么结果会推翻推荐，说明备选与重审条件还不完整。练习后优先修订缺失的决策依据，而不是单纯增加页面。答辩准备的质量取决于能否支持判断，不取决于材料厚度。
9 从方案讲解与答辩走向POC 设计（P35）
本课结束时，方案应从“听起来可行”走到“知道哪些问题决定它是否可行”。接下来的 POC，即概念验证，要用受控实验检查最影响决策的不确定性。它的目的不是搭建缩小版生产系统，也不是演示所有功能。对零售订单 API，优先级最高的问题是目标峰值下能否正确受理，以及单区故障后能否在约定时间恢复。这些问题的答案会直接改变部署选择与批准条件。
把评审问题改成实验问题时，要补齐输入、动作、观测与判定。例如，“验证高可用”过于宽泛，可以改为：“在接近真实请求构成、每秒 800 次提交的条件下，让 1 个可用区的受理路径不可用，记录入口响应、持久化订单、重试结果与恢复耗时。”还要定义故障注入的具体范围，说明它能代表哪些情况、不能代表哪些情况。仅停止应用实例，不能声称已经测试整个可用区故障。
通过标准必须在实验前写下。正常路径检查 P95 不超过 300 毫秒，并同时检查失败率与受理正确性；故障过程检查在 15 分钟内恢复接单，并核对已成功受理订单在约定故障范围内是否保留。故障期间的允许失败和降级表现需要另行确认，不能默认正常目标全过程不变。恢复计时从哪里开始、何时结束，也应事先规定，避免事后通过改变口径获得“通过”。
还需要决定哪些证据足以改变方案。若只是某项参数配置不当，可以修正后重测；若共享依赖使故障路径根本不存在，就要回到设计与 ADR；若满足目标的成本超出预算，则回到业务取舍。POC 的价值包括证伪。实验失败只要能清楚说明原因与决策影响，就比没有边界的成功演示更有助于推进。
交接到 P35 的输入应包含已确认需求、候选方案、关键假设、证据缺口、实验优先级和资源限制。还要写明实验环境与未来生产环境的差异，例如数据规模、网络路径或外部依赖采用了简化替代。这些差异决定结论能迁移到哪里。下一课会据此设计实验步骤、观测方法和退出条件，本课先确保实验要回答的问题与评审所需决定保持一致。
放进方案里
本次申请批准零售订单 API 的双可用区方案方向及 POC 资源，生产上线另行评审。接口成功表示订单及受理记录已持久化，后续履约异步推进，支付结果由独立流程确认。案例峰值为每秒 800 次提交，正常响应 P95 目标为 300 毫秒以内，月度可用性目标为 99.9%；业务负责人须确认预测与统计口径。
候选项为单可用区、同城双可用区及跨地域部署。当前推荐同城双可用区，以覆盖已提出的单可用区故障恢复需求；单区成本较低，但故障暴露较大；跨地域方案增加成本及协作复杂度，现阶段保留为备选。单区故障恢复接单目标为 15 分钟，已成功受理订单在该故障范围内以不丢失为目标，能力尚待验证。地域灾难恢复暂定 RPO 为 5 分钟、RTO 为 60 分钟，另行确认并验证。
成本按相同业务规模估算计算、数据库、存储、网络、监控及运维投入，注明请求量、冗余容量和日志保留期。当前关键缺口为数据库切换、剩余区承载能力与响应丢失后的重试语义。架构负责人补齐依赖边界，运维负责人组织演练，业务负责人确认降级接受条件。证据注明环境、日期及适用范围，设计说明与实测结果分别标识。
POC 优先验证正常峰值受理及单区故障恢复，提前约定故障范围、计时起止、订单核对方法和通过标准。未满足关键标准时，不进入上线批准；根据结果修订实现、重新比较选项或协商需求。评审记录保留推荐理由、接受的风险、待决事项及重审条件，并同步更新 ADR。演练若发现共享依赖或成本超出预算，应重新提交相关取舍，不能继续沿用原承诺。
10 小结：下一步POC 设计（P35）
方案讲解要把需求、选择、代价与证据串成可检查的判断。答辩时先回应决策点，再给依据、边界与行动；遇到未知项，形成有负责人和关闭条件的记录。
进入 P35 前，请确认自己能够回答：为何推荐双可用区？现有证据覆盖哪种故障？什么实验结果会使团队改变选择？带着这些问题设计 POC，才能让验证真正推动决策。