POC 设计

1 POC 设计要回答什么

零售业务准备改造订单 API：顾客提交订单，系统检查商品与库存，保存订单，再返回订单编号。架构讨论已经提出同步处理和异步确认等选项，架构决策记录 ADR 也写下了初步理由。但团队仍有疑问：促销时能否承受流量，客户端重试会不会生成重复订单，数据库短暂不可用时会发生什么？这些疑问不能靠演示页面回答，需要有边界的验证。

POC 是概念验证。它把影响决策、又缺少证据的假设，变成能被观察和推翻的实验。本课的主要问题是：候选方案 A 在接近业务的数据与依赖条件下，能否可靠处理创建订单请求，且实施代价值得继续评估。POC 的成果是有条件的决策证据，包括通过、失败和仍未验证的部分。服务能启动、接口能返回成功，只证明调用路径已经接通。

先把需求拆成可验证的假设。例如，“支持促销”太宽，可以改为：在约定的订单结构、热点商品比例和请求分布下，持续处理每秒 300 次创建请求，响应时间 p95 不超过 800 毫秒，且没有已确认订单丢失。p95 表示按响应时间排序后，约 95% 的请求不超过该值；它比平均值更能显露慢请求，但仍不能代替业务正确性检查。这里的数值都是教学目标，实际项目必须由业务量与用户体验要求确定。

每个假设都应连到待选方案。如果同步方案已经能满足目标，增加消息队列可能不值得；如果关键依赖波动导致同步请求大量超时，异步确认才有进一步验证的理由。POC 不负责证明某个预定答案正确。它应允许出现“维持现状”“调整设计再测”以及“当前证据不足”等结论，否则实验很容易变成替既定采购寻找理由。

本课沿用零售订单 API 的需求、选项、ADR、成本、风险与高可用链路。我们把“成功响应”定义为订单已经可靠保存，顾客可以用订单编号查到；若采用异步接收，就必须单独标为“已接收”，并继续检查最终确认结果。不能让候选方案通过修改成功含义取得速度优势。验证前先固定这个业务口径，后面的性能、故障和成本结果才有可比性。

2 成功标准与退出条件

成功标准要同时描述业务结果、测量方法和适用范围。本例把创建订单成功率定义为：在全部有效逻辑订单中，最终满足约定业务结果的比例。有效订单需要排除明确的非法输入，但依赖超时、服务错误和实验造成的失败都不能随意移出分母。重试是同 1 笔逻辑订单的后续尝试，应同时保留逻辑订单数与请求尝试数，避免靠重试把报表做得漂亮。

性能目标可设为每秒 300 次逻辑订单、持续 30 分钟、p95 不超过 800 毫秒，业务成功率至少 99.9%。此外设置硬门禁：已确认订单丢失数为 0，重复建单数为 0，订单金额和明细核对差异数为 0。这里的“为 0”是本轮样本中的验收要求，并不代表证明未来永不出错。报告必须附上样本规模和持续时间，不能把短时观察写成全年可靠性承诺。

还要把正常运行与故障恢复分开。正常场景通过后，再验证停止 1 个应用实例是否仍能完成订单，以及数据库连接中断 20 秒后能否恢复处理。每类故障分别设定恢复目标、允许的失败范围和订单核对方法。本例可要求应用实例故障后 60 秒内恢复到正常目标，且所有已确认订单仍可查询。数据库故障是否允许短暂拒绝新单，需要业务负责人提前选择，不能在测试失败后补写宽松口径。

退出条件回答何时停止投入。时间盒可设为 5 个工作日，测试资源费用上限为 2000 元；出现错误写入、测试数据越界或无法控制的资源增长时立即停止当前轮次。发现硬门禁失败，也应先保存证据、定位问题，再决定是否修复重测。它不一定要求整个 POC 永久结束，却禁止继续堆积没有解释力的成绩。时间或预算耗尽时，可以输出“证据不足”，不必强行选出赢家。

通过也需要明确边界。正常负载通过但故障验证缺失，只能支持正常条件下的可行性；吞吐达标但成本采集失败，不能支持经济性结论。建议采用“通过、附条件通过、不通过、未验证”这 4 种状态。附条件通过必须写清补充条件、负责人和截止时间，硬门禁未满足时不能靠审批文字改成通过。结果审阅时先看这些状态，再看演示画面。

3 环境、数据与对照基线

测试环境不必复制全部生产规模，却必须保留会影响结论的关键结构。本例至少保留 API 网关或等效入口、2 个应用实例、订单数据库、库存依赖和观测组件。记录每个组件的规格、版本、部署位置、连接限制与配置。若库存依赖使用模拟服务，要说明它模拟了哪些延迟、超时和错误，哪些行为没有覆盖。模拟接口总是立即成功，就不能用结果推断真实库存依赖下的表现。

建立对照基线时，先运行当前同步创建订单方案，再运行候选方案 A。两者使用相同的订单业务定义、数据集、入口负载和资源预算；如果资源不同，应单独披露，并把差异纳入成本比较。基线不是随手找的旧成绩，应该在本轮环境中重跑。测试期间固定其他关键因素，每次只调整有记录的变量，才容易解释性能变化究竟来自方案还是环境。

数据要描述分布，而不仅是总量。本例准备 100 万条历史订单、10 万个商品，并让 10% 的商品承接约 70% 的请求，以观察热点影响；每单商品项数按约定比例分布，加入多商品订单、长备注、缺货和无效地址等情况。比例只是可复现的教学设定，应由真实业务统计替换。还要检查索引、历史数据和可用库存是否准备一致，避免第 2 轮因为库存耗尽而测到另一种业务。

真实数据应先脱敏，并确认使用范围；没有授权时使用合成数据。合成数据也应保留字段长度、关联关系、热点和时间分布等重要特征。给数据集标注版本和生成规则，说明哪些分布来自测量，哪些来自假设。若只拿到日常数据，促销场景就仍是外推。结论中要把这个缺口保留下来，不能因为数据量够大就声称具有代表性。

负载也需要可复现。先预热 10 分钟，再执行正式测量；分别测试稳定负载、阶梯升压和短时突发。记录计划发出的请求速率、实际发出的速率以及完成速率，确认施压端没有先达到瓶颈。未完成请求与客户端超时都要计入结果。每轮结束核对订单后，恢复到约定的数据状态，再进行对照；缓存是否清空或预热也必须使用一致规则。

4 动手：写一份 POC 计划表

现在把疑问写成可执行计划。不要从工具清单开始，先写决策问题：“候选方案 A 是否值得进入订单 API 的下一阶段设计？”再列出会改变答案的证据。下面的表格是团队评审的起点，其中阈值只适用于本课示例。业务负责人确认订单含义，开发负责人确认实现与版本，测试负责人维护负载和记录，运维负责人确认资源、监测与停止手段。

把表格展开成实验卡片，每张卡片只回答 1 个主要问题。例如“热点是否使数据库等待上升”卡片，应固定总请求速率和资源，只改变热点比例，同时记录响应、数据库等待和业务核对结果。对照实验不能同时换机器、改索引、换数据再宣称架构更优。必要的组合调整可以进行，但应作为新的候选配置命名，并重新说明它与基线的差异。

执行时先做小流量冒烟检查：提交有效订单、重复提交同 1 个业务请求、查询返回订单，再核对金额与明细。通过后才开展正式负载。每次运行分配独立运行编号，关联代码版本、配置、数据版本和日志。保存原始结果及汇总规则；仅保留截图会让后续审阅无法判断超时是否被忽略。遇到异常先标记时间，再判断是否需要停止，避免一边修改配置一边继续累计统计。

正式测试可对关键场景重复 3 次，观察结果波动。如果某轮失败，不应直接删除后只展示成功轮次；应解释原因，并保留失败结果。修复后的运行使用新编号，说明改动和是否重跑基线。最后安排一次由其他成员按计划复现的小规模运行，检验计划是否依赖作者的口头补充。可复现性本身就是 POC 向项目交付的重要证据。

计划表还要写交付物和审阅人：实验报告、数据说明、可运行配置、问题清单、费用记录和 ADR 更新。每个结论应指向具体运行编号，而不是“测试同学确认没问题”。审阅时逐项判断证据是否足够、条件是否吻合；若结果互相冲突，应安排能区分原因的后续实验，而不是取平均值掩盖差异。

5 演示效果与可推广性取舍

演示追求让人快速理解业务路径，可推广性要求换数据、换操作者、延长运行时间后仍能解释结果。两者可以兼顾，但时间盒内应先保证关键疑问有证据。本例可以用简单页面展示下单与查询，主要投入则用于数据分布、订单核对和故障记录。漂亮页面能够辅助沟通，却不能替代后台真实保存结果。

需要区分允许的简化和改变问题的简化。临时管理页面、手工触发测试、缩小非关键业务范围，通常可以明确标注后使用；绕过库存检查、关闭关键校验、把真实写入换成内存保存，会改变创建订单的工作量与成功含义。这样的实验仍可用来检查局部接口，但不能支持完整订单 API 的可行性结论。简化的影响应写进报告，而不是藏在代码里。

考虑 5 个工作日的投入安排：先保留 2 天建立环境和核对链路，再根据主要风险分配剩余时间。若最大不确定性是热点数据，优先扩大分布覆盖；若是故障后重复建单，优先验证重试与订单唯一性；若业务尚未认可流程，再安排必要的演示。投入比例应随决策问题改变，不能把某种固定比例当成普遍最佳实践。

交互中的滑块展示固定时间预算下的取舍，并不预测真实项目成功率。把时间更多分给演示，会减少可用于重复实验、故障注入和数据准备的时间；把时间更多分给验证，也需要保留足够清晰的业务讲解。学习时应观察被推迟的证据，并说明它对最终决策的影响。风险来自未回答的问题，而不是滑块停在某个位置本身。

推广前还要区分代码资产和实验资产。临时压测脚本、模拟库存服务、手工初始化步骤未必能直接进入生产。报告应说明哪些内容可以复用，哪些需要重做，以及预计需要哪些角色参与。POC 证明某条技术路径值得继续，并不会自动完成上线设计、容量规划、权限治理和日常值守；这些工作需要进入下一阶段的计划与成本。

6 常见坑：POC 成功却无法量产

常见的问题是验证对象在中途悄悄变化。基线等待订单保存才返回，候选方案收到请求就返回，两者的响应时间无法直接比较。若候选方案采用异步确认，应分别报告接收延迟、最终确认延迟、积压量和最终业务成功率。只有顾客被明确告知订单状态，且后续确认满足业务要求，快速接收才构成有意义的优点。

另一个问题是只看应用实例。应用 CPU 不高，并不能说明还有足够容量；数据库连接等待、热点库存争用或依赖超时都可能限制吞吐。至少需要把入口请求、应用处理、数据库访问和业务核对连起来，使用统一运行编号和时间范围定位。入门阶段先掌握这些观察点，不必深入数据库内部实现；看见等待集中在哪里，就已能为下一轮实验缩小范围。

还有一种误判是把短暂稳定当成长期稳定。30 分钟测试可能看不到历史数据增长、定时任务、日志累积或缓慢积压。若这些风险与决策有关，就补充更长观察或专门场景；时间盒不允许时，明确列为未验证。不能把“没有观察到”写成“不存在”。同样，停止 1 个应用实例只支持相应的实例故障结论，不代表已经验证数据库切换或整个可用区故障。

成本也会在推广时突然出现。POC 可能使用临时免费额度、共享数据库或人工盯守；生产则需要持续资源、备份、监控、值班和维护。记录测试消耗时，应同时记下人工操作次数、所需角色和依赖条件。此时不必计算完整 TCO，但必须留下足够输入，让下一课能够区分实验费用与长期拥有成本。

最后是没有可接手的操作过程。作者知道何时重启、何时补数据，其他人却只能看演示。推广门槛应包括环境重建、异常定位和恢复步骤能够被别人执行。发现手工补救时，应把它记录为工作量和风险；若补救会改变订单结果，还必须重新核对正确性。隐藏这些步骤只会把未完成工作推迟到上线现场。

7 案例：样例数据掩盖真实瓶颈

团队最初使用 1000 个商品和 1 万条订单做验证，每个订单只有 1 个商品项，请求均匀分散。候选方案 A 在每秒 300 次请求下 p95 为 420 毫秒，业务核对通过。汇报材料于是写下“满足促销目标”。但这份结论遗漏了数据分布前提：商品访问均匀、订单明细很短，且历史订单量远小于计划范围。

评审要求换用计划中的数据版本：100 万条历史订单，10 万个商品，10% 的商品承接约 70% 的请求，并包含多商品订单。保持应用和数据库规格、请求速率以及测量窗口不变后，p95 上升到 1600 毫秒，客户端超时增加。应用 CPU 仍有余量。此时不能直接得出“必须加应用实例”，因为证据只说明端到端变慢，尚未说明受限位置。

团队沿时间线发现，慢请求与数据库等待上升同时发生，且集中在热门商品相关订单。接着分别运行均匀分布和热点分布场景，再固定热点分布、改变每单商品项数。对照结果支持“热点与订单结构影响当前处理路径”的判断。它尚不能证明具体内部原因，需要结合必要的数据库诊断继续缩小范围；本课停留在如何设计能区分假设的实验。

为检验修复方向，团队对相关访问方式做了有记录的调整，形成候选配置 A2，使用相同数据与负载重测，同时重新检查订单唯一性和金额。假设 A2 的 p95 降至 720 毫秒，也只能说明该配置在这些条件下达到目标。随后仍需执行计划中的实例故障与数据库中断场景，并观察代价是否转移到其他资源。性能修复不能豁免业务核对和故障验证。

最终报告保留初始成绩，标为“均匀小数据场景通过”；代表性场景的失败与 A2 的改进结果分别记录。ADR 更新为：原候选配置不满足目标，A2 在已测场景下可继续评估，故障验证与长期数据增长仍有明确状态。业务方由此得到的是可追踪的决策条件，而不是被后来成绩覆盖的历史。这个案例的关键教训是，数据分布属于实验条件，必须和结果一起传播。

8 把 POC 门禁写进项目方案

门禁是进入下一阶段必须满足的条件。它应放在需求与架构选项之后、实施和采购承诺之前，让读者知道方案依赖哪些证据。本例按“正常负载、业务正确性、故障恢复、成本可解释性”设置检查项，每项都指定证据、负责人和状态。门禁要能被审阅人执行，不能只写“性能良好”“具备高可用”这类无法判断的描述。

正常负载门禁引用数据版本、请求分布、规格和运行编号；正确性门禁引用订单核对结果；故障门禁列出故障对象、持续时间及恢复观察窗口。成本门禁先要求资源与人工记录齐备，供后续评估使用。若采用附条件通过，应明确允许进入的是补充设计还是小范围试点，以及扩大范围前必须补齐的证据。不同阶段不应共用含糊的“已通过”标签。

门禁还应覆盖变化后的处理方式。订单峰值目标提高、商品热点变化、数据库规格调整或成功响应定义改变时，原结论的适用性需要复审。并非所有变更都重跑全部实验，但负责人必须说明哪些假设受影响、哪些场景需要补测。把这项规则写进方案，能够防止实验条件已经变化，团队仍沿用旧成绩作出承诺。

与 ADR 的连接可以写得很直接：选择 A2，因为它在指定数据和资源下满足正常目标，并已通过列出的故障场景；代价是增加了相关实现与运维工作；当峰值或订单结构越过已测边界时重新评估。未通过的替代方案也保留主要原因。这样，未来团队能理解决策为何成立，以及哪些证据变化可能使原选择不再合适。

项目经理还需要把剩余工作变成可安排的任务。对每个未验证项写明风险、补充实验、所需资源、负责人和完成时点；对临时实现写明生产化改造范围。高可用目标尤其要落实到已验证故障范围，不能仅凭部署了 2 个实例就勾选完成。门禁的价值是控制决策的不确定性，并让团队知道下一步该补什么。

9 从POC 设计走向TCO/ROI 与招投标（P36）

POC 结束后，团队已经知道部分技术目标能否实现，但还没有回答长期投入是否合理。进入 P36 时，应带上各候选方案在相同条件下的资源消耗、测试费用、人工投入、运维动作以及剩余风险。这些记录能为总拥有成本 TCO 提供输入。把每秒 300 次请求时的费用直接乘到全年通常不可靠，因为日常与促销负载、冗余资源和计费方式可能不同。

投资回报 ROI 还需要业务收益假设。例如，更稳定的下单是否减少失败订单、降低人工处理量，收益基线是什么，改善幅度由谁确认。POC 可以测出失败率变化和操作时间，却不能自行把它们换成确定销售收入。应把测量值、业务假设与不确定范围分开，让后续敏感性分析能够检查结论对哪些输入最敏感。

招投标材料则需要把可验证条件转成公平、清晰的验收要求。描述订单语义、数据分布、负载形态、故障范围和证据格式，允许不同实现证明满足同一业务目标。避免把 POC 中偶然采用的产品功能或配置名称直接写成必须条件。若确有兼容性约束，应说明业务原因，并确保供应方与项目团队对测试条件和责任边界理解一致。

交接前检查读者能否回答：为什么测这些问题，基线是否可比，哪些结论仍依赖模拟，失败是否被保留，成本记录是否可用于下一阶段。能够回答这些问题，才意味着 POC 为方案选择提供了可用证据。P36 将在这组边界清楚的输入上讨论 TCO、ROI 和采购评估，让技术可行性继续走向经济性与交付责任。

放进方案里

本项目针对零售订单 API 开展 POC，验证候选方案 A 相对当前同步方案的适用性。决策范围包含创建订单的正常处理、重试正确性和指定故障恢复，不覆盖全部生产场景。成功响应表示订单已可靠保存并可按编号查询；采用异步接收时，另行记录最终确认结果与耗时。各方案使用一致的业务定义进行对照。

测试使用已脱敏或合成的数据集，包含 100 万条历史订单、10 万个商品以及约定的热点和订单明细分布。正常场景以每秒 300 次逻辑订单持续运行 30 分钟，要求 p95 不超过 800 毫秒、业务成功率至少 99.9%，且本轮核对中已确认订单丢失、重复建单及金额差异均为 0。上述指标须与样本规模、数据版本、资源规格和运行编号共同提交。

正常场景通过后，分别验证停止 1 个应用实例和数据库连接中断 20 秒的影响。实例故障恢复目标为 60 秒内回到正常指标；数据库故障期间的新单处理规则由业务负责人在测试前确认。故障结果需包含时间线、请求结果、恢复记录和订单核对，不将局部故障结果扩展为全部高可用承诺。

POC 时间盒为 5 个工作日，测试资源费用上限为 2000 元；发现错误写入、数据使用越界或资源增长失控时立即停测并保存证据。结果采用通过、附条件通过、不通过和未验证状态，未满足正确性硬门禁不得通过。测试负责人提交报告，业务、开发与运维负责人共同审阅。

批准进入下一阶段前，应更新 ADR，列明选择理由、适用边界、生产化改造和未验证风险。证据包同时移交资源消耗、人工投入与费用记录，供 P36 的 TCO、ROI 和招投标评估使用。需求、数据分布或关键配置变化时，复审受影响假设并安排补测。

10 小结：下一步TCO/ROI 与招投标（P36）

POC 设计把架构疑问变成可复现的实验：先明确订单结果，再约定标准、基线、数据、故障和退出条件，最后用证据更新 ADR。演示帮助理解，实验边界决定结论能走多远。

进入 P36 前，尝试用自己的话回答：样例数据通过为何仍可能不支持促销决策？异步接收应补测什么结果？停止 1 个实例能支持哪些高可用结论？带着这些边界和成本记录，继续评估方案的长期价值与采购条件。