1 为什么先学「成本建模」
零售团队准备上线创建订单 API。用户点击结算后，系统校验购物车、查询商品价格、检查库存、保存订单，再发送后续处理消息。上线申请里写着“需要若干台应用实例和数据库”，财务却问：每完成 1000 笔订单要花多少钱？促销期间请求增加后，费用会增加多少？如果系统故障导致用户反复点击，账单和成交量会不会朝不同方向变化？资源清单本身回答不了这些问题。
成本建模，就是把业务活动、系统工作量、资源用量和费用之间的关系写清楚。模型不必从复杂公式开始，可以先画出订单经过的组件，再给每个组件写出计费单位和估算依据。它的作用是帮助团队在上线前比较方案，在运行后解释偏差，并在改变配置时知道哪些假设需要重新验证。模型得到的是带条件的估计，精确到小数点后很多位，并不会让未经测量的输入更可靠。
先学这件事，是因为技术方案中的许多选择同时影响体验、容量和费用。延长日志保留时间有利于排查历史问题，也会增加存储量；减少应用实例可以降低部分费用，却可能让订单排队更久；增加重试能够挽救短暂失败，也可能在依赖已经拥堵时放大请求量。只有把业务结果放在模型里，才能判断省下的费用是否值得承担相应影响。
本课始终使用同 1 个场景：面向消费者的创建订单 API。我们关注从收到创建请求到订单可靠保存并返回结果这段链路，支付和物流只作为边界外的相邻系统。讨论目标是建立入门级的估算、观测与排查方法，不需要掌握财务会计或数据库内部实现。读完后，你应该能解释费用从哪里来，用明确单位计算单位成功订单成本，并把异常账单转成可核对的技术问题。
还要区分“成本下降”和“模型变好了”。上线前把遗漏的备份费用补进来，会让估算上升，却让决策更可信；把超时请求从成功数量中剔除，也可能让单位成本上升，却能暴露真实问题。建模首先追求口径一致和证据可查，再讨论优化。团队共同使用的模型，应当让产品、开发、运维和财务能够对着同 1 组数字讨论。
2 核心概念与边界
先约定时间窗口。本课使用 30 天作为估算月，共 2592000 秒。这个窗口只是示例，实际账单可能按自然月结算，流量统计也可能采用不同时间边界。把 28 天的用量直接与 31 天的账单比较，会把时间差误当成效率变化。金额统一用“元”，下面所有价格都为教学假设，不对应任何厂商报价，且暂不包含税费和折扣。
成本对象是你准备回答“给谁算钱”的对象，可以是订单 API、整个零售站点，也可以是某个门店。本课的成本对象是创建订单服务，包含入口、应用、数据库、消息、相关网络、日志和备份的可归属费用。支付通道手续费、商品采购、物流和人工不计入本课金额，因此结果属于这段技术链路的基础设施成本，不能直接称为商品利润或公司总成本。
成本驱动因素是让用量发生变化的业务或技术量。创建请求次数会影响应用执行和访问日志，订单数据量会影响数据库存储和备份，响应字节数会影响部分网络费用，保留天数会影响历史数据规模。选择驱动因素时，要找能够被测量、又能解释变化的量。“业务很忙”无法进入公式，“本月入口收到 300 万次创建尝试”就可以。
计费单位决定了公式能否相乘。每实例小时的价格要乘实例数量和运行小时，每 GB 月的存储价格要乘对应期间的计费容量，每百万次请求的价格要乘请求次数再除以 100 万。同样写着“流量”，可能分别指请求数、传输字节或峰值带宽。核对价格表时，应同时记录单位、计费范围、免费额度、阶梯规则与生效日期，不能只抄 1 个金额。
固定成本和可变成本需要限定观察范围。某数据库按预留容量运行，在当前负载范围内每月费用近似固定；超过容量需要升级时，费用会跳到新的台阶。应用按请求收费的部分通常随调用增加，但最低保有实例又形成基础费用。因此，“固定”只表示在当前期限与容量区间内不随工作量连续变化，并不表示永远不变。
单位成本还需要明确分母。创建尝试是系统收到的每次调用；逻辑订单是用户本来想完成的独立业务操作；成功订单是在本课边界内可靠保存、满足业务成功条件的订单。重试会让创建尝试多于逻辑订单，失败会让成功订单少于逻辑订单。用尝试次数作分母，可以观察每次执行的平均费用；用成功订单作分母，才能回答完成业务结果的技术代价。
共享资源需要分摊规则。例如数据库还承载商品查询，不能把整张数据库账单都算给创建订单。可以依据可归属的资源时间、存储占用或经过验证的调用权重进行分摊，并保留未分摊部分。请求数相同的接口，单次消耗可能不同，直接平均分摊只能作为粗略起点。规则改变后，应标记版本；否则“单位成本改善”可能只是费用被挪给了其他服务。
3 关键机制（可迁移）
可以把通用模型写成：期间总成本等于各项计费用量乘对应单价后的求和，再加固定项与调整项。调整项可能包含约定范围内的折扣或补差，但不能把未确认的优惠提前当作收益。建模时应让每行费用对应明确组件、单位、数量来源和价格依据。公式越简单，越需要把输入来源写清楚，避免把直觉包装成测量结果。
用订单服务建立教学基线。30 天内有 240 万个逻辑订单，入口实际收到 300 万次创建尝试，其中包含重试；最终成功订单为 228 万笔。应用固定费用为 600 元，按尝试次数计的可变费用为每 100 万次 100 元，因此应用合计 900 元。数据库预留容量为 600 元，数据存储 100 元，备份 60 元，网络 120 元，日志 180 元，消息 40 元，总计 2000 元。
这里的数据库预留费用已经覆盖该容量范围内的处理能力，不再额外按每次读写虚构费用。网络、日志和消息金额则来自各自用量估算，不能默认所有真实产品都采用相同计费方式。逐行建模的价值，就在于防止把“数据库调用很多”直接换算成并不存在的逐次收费，也防止把确实存在的存储或出站费用漏掉。
这份基线每 1000 次创建尝试的成本约为 0.667 元，每 1000 笔成功订单的成本约为 0.877 元。相同的 2000 元，因为分母不同而表达不同问题。若故障使成功订单减少，即使账单没有上涨，每笔成功订单承担的成本也可能变高。跨月比较时，必须同时展示总费用、成功数量和单位成本，不能只拿其中 1 项判断健康程度。
从业务量推资源量，需要补上工作量系数。例如每次创建尝试平均访问数据库 3 次，300 万次尝试便对应 900 万次访问。这个数量先用于判断数据库负载和容量，不一定直接进入金额公式。再如每次尝试产生平均 2 KB 日志，按十进制单位估算，300 万次约产生 6 GB 原始日志；索引、重复采集、压缩和计费口径会改变最终计费量，必须单独说明。
月平均速率约为 1.16 次尝试每秒，但这个值不能直接决定实例数量。订单可能集中在营业时段，促销又会形成短时峰值。假设峰值为 120 次每秒，平均处理时间为 0.2 秒，稳定条件下平均同时处理的请求约为 24 个。这个估算只用于建立直觉，真正容量还受数据库连接、慢请求、请求差异和安全余量影响，需要用接近真实链路的压测验证。
模型应把业务假设和容量约束并列展示。流量增长 2 倍时，请求计费部分可能近似增长 2 倍，而预留数据库可能暂时不变；跨过容量边界后，又可能增加较大固定费用。对未来业务量不确定时，可以给出低、基准、高 3 个情景，分别写明订单量、重试放大、峰值与数据保留。这样得到的是可解释的范围，而不是看似确定的单点承诺。
还可以做敏感性分析：每次只改变 1 个假设，观察总成本变化幅度。如果日志保留从 7 天改成 30 天带来的差额远大于减少少量应用调用，那么排查重点就应先放在日志。如果某项假设虽然不影响多少费用，却接近容量上限，也不能忽略。费用敏感性告诉你钱对什么变化敏感，容量分析告诉你服务对什么变化脆弱，两者共同支持决策。
4 关键机制续：落到订单链路
现在沿着实际调用理解这些系数。用户发出创建订单请求，入口完成身份与格式检查，应用读取商品与库存信息，再将订单写入数据库。可靠保存后，系统安排后续消息，最终返回订单标识。每经过 1 个组件，都可能消耗处理时间、连接、存储、网络和观测资源。画图时先标出工作发生在哪里，再决定使用哪种计量方式，避免从账单名称反过来猜业务行为。
失败发生的位置会影响已消耗的工作。格式错误在入口被拒绝，通常不会产生完整的数据库工作；库存校验失败可能已经执行若干查询；订单保存后响应丢失，则大部分创建成本已经发生。把所有失败都假设成成功请求相同的消耗，会高估部分场景；把失败一概当作没有成本，又会低估依赖超时和重复执行。初始模型可以分为早期拒绝、处理中失败、可靠保存后结果未知这几类。
客户端超时只说明客户端在期限内没有收到确定响应，不能证明订单没有生成。用户重新点击或客户端自动重试，可能让服务器再次执行。业务上应使用能识别同 1 次创建意图的幂等标识，并让服务器在合理范围内返回已有结果。幂等能够减少重复订单，却不代表重试免费：入口校验、幂等记录查询、网络与日志仍然消耗资源，也要进入模型。
重试放大系数可以定义为创建尝试数除以逻辑订单数。本课基线为 300 万除以 240 万，即 1.25。也可以把额外尝试比例记为 r，令尝试数等于逻辑订单数乘以括号内的 1 加 r。这里 r 为 0.25，表示平均每个逻辑订单多出 0.25 次尝试，它不是某次请求的失败概率。不要把“重试 2 次”与“总共尝试 2 次”混写，否则容量估计会产生明显差异。
重试预算需要限制总次数和总时间，并配合退避，让重复尝试之间留出逐渐增加的间隔。不同客户端稍微错开重试时刻，可以减少请求同时涌入。入口、应用和下游如果各自独立重试，放大还可能层层相乘，因此应记录每层实际策略。入门阶段先回答谁负责重试、最多执行多少次、哪些错误值得重试、如何识别同 1 个订单，就能避免许多失控情况。
队列可以把短时高峰分散到稍后处理，但排队中的消息仍然占用空间，消费者也需要容量。若数据库变慢，继续大量接收请求只会积累待处理工作；消息超时重投还可能制造更多执行。对用户而言，“请求已接收”与“订单已可靠保存”是不同状态。模型和成功率口径必须与 API 的承诺一致，不能把进入队列的数量直接当作最终成功订单。
为了理解重试对费用的影响，下面交互固定逻辑订单 240 万、成功率 95%，只改变额外尝试比例。固定费用与数据费用合计 1360 元，随尝试变化的费用在 300 万次时为 640 元。这个局部模型把成功量保持不变，用于观察重复工作的边际代价；真实故障中，成功率和处理时间也会改变，不能把交互输出直接当成生产预测。
5 动手与命令/控制台直觉
先建立 1 张可手工维护的估算表。每行至少写组件、归属范围、计费单位、预计用量、单价、预计金额、数据来源和假设。把价格单位保留在表头或单元格里，例如“元/100 万次”，而不是只填数字。对于共享数据库，再增加分摊依据；对于预留容量，再增加当前容量范围。初次估算允许使用区间，但要明确哪些输入尚待测量。
接着在测试环境完成几次创建与重试，观察同 1 个业务意图是否只生成 1 笔订单。下面命令用于表达请求结构，实际地址、身份认证和字段需要按测试系统调整。示例域名不会代表可直接调用的服务，幂等标识也应在不同业务意图之间更换。不要在生产环境反复创建订单来验证估算，更不要为了看见费用变化而发起无边界压测。
curl --request POST 'https://orders.example.test/orders' \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: p6-demo-order-001' \
--data '{"sku":"demo-01","quantity":1}'对于这个业务意图，先发送 1 次，再使用相同幂等标识重发 1 次。观察返回的订单标识是否一致，订单记录是否只有 1 笔，并记录入口尝试计数和数据库访问计数的变化。重发请求返回成功，不等于创建了新的成功订单；它可能只是查询并返回已有结果。测量记录应同时包含执行次数和新增业务结果，才能把重试成本与新增订单成本分开。
随后做小规模、受控的负载实验。每轮固定请求内容与持续时间，逐步增加速率，记录吞吐、延迟、错误、应用资源和数据库等待。压测数据要覆盖入口到可靠保存的完整路径，并说明是否包含消息发送。某轮持续时间过短、数据始终命中缓存或没有真实写入，都可能让结果过于乐观。测试环境与生产规格不同的地方，也应写进结论的适用条件。
进入账单或用量控制台时，先统一账户范围、服务范围、币种和时区，再区分费用视图与用量视图。费用上升可能来自用量增加，也可能来自单价、折扣或分摊变化。用量视图里的 GB、实例小时、请求次数，能够帮助回到技术驱动因素。导出数据时保留原始单位和资源标识，避免在电子表格里提前把不同地区或不同计费项混在一起。
还应注意控制台数据的更新时间。运行监控可能几秒内刷新，账单明细却可能延迟数小时甚至更久。当天费用偏低，未必意味着优化已经有效。可以先用入口计数、日志字节和运行小时做临时估计，待账单完整后再对齐。实际核对时记录数据截止时间，不能拿尚未补齐的当天费用和已经完整结算的昨天直接比较。
完成这轮动手后，预期产物是包含真实输入来源的估算表，以及至少 1 条“请求如何变成资源用量”的测量记录。即使还无法精确归属所有共享费用，也应把未知部分显式保留。不要为了让表格看起来完整而编造缺失输入；标记待确认的容量区间、计费单位或分摊规则，比填入没有依据的精确数字更有价值。
6 观测：看哪些字段与信号
观测的目标是把费用变化接回业务行为。业务层需要逻辑创建量、成功订单量、取消或无效订单的处理口径；入口层需要尝试次数、返回状态和请求字节；应用层需要处理时间、重试来源、幂等命中与错误类别；依赖层需要数据库访问、等待、消息投递和重投。只看 CPU 利用率，无法解释日志费用；只看账单，也无法判断费用增加是否换来了更多成功订单。
建议在请求记录中使用时间、服务、环境、接口模板、请求标识、追踪标识、结果类别和耗时等字段。幂等标识或其受控摘要可以帮助关联同 1 次业务意图，但要遵守数据保护要求。订单明细、用户身份和完整请求体不应为了成本分析而默认进入日志。用于指标标签的维度应保持数量可控，订单标识适合受控日志查询，不适合给每笔订单建立独立时间序列。
聚合时先确认是否重复采集。入口网关和应用都记录请求，很容易把同 1 次尝试算成 2 次；多个副本汇总时，也可能重复合并已经聚合的结果。为每个核心指标指定权威来源，例如入口尝试以入口计数为准，成功订单以满足业务条件的去重记录为准。采样追踪有助于分析路径，却不能未经校正直接作为完整交易数量使用。
可以建立 4 组并排趋势：成功订单与尝试次数、总费用与单位成功订单成本、请求延迟与错误率、日志和网络等主要计费用量。延迟既看平均值，也看 p95，即约 95% 请求不超过的耗时位置。平均值稳定而 p95 上升，可能表示少部分订单正在经历长等待，并诱发客户端重试。趋势的时间窗口必须一致，才能判断变化是否同时发生。
告警可以围绕机制设置。例如成功量基本稳定而尝试量显著增加，提示重试放大；日志字节每次尝试显著增加，提示日志内容或采集方式变化；数据库等待上升且应用并发持续增加，提示依赖容量限制。阈值应结合基线和促销计划设定，而不是永久使用同 1 个绝对数。账单告警适合控制预算，运行信号则适合更早发现造成浪费的故障。
预算是管理目标，预测是对未来的估计，告警是需要检查的信号。预算耗尽不自动说明系统异常，促销成功也可能推动合理增长；预测低于预算也不保证没有故障。对每次告警，应该先问业务量、单位工作量和价格条件分别变化了多少，再决定扩容、限流、调整日志或修复请求策略。观测只有连接到具体行动，才会改善下一轮模型。
7 常见坑与反模式
最常见的遗漏是只计算应用实例。数据库、备份、日志、消息、跨边界传输都可能占据明显费用。解决方法是在链路图上逐个标记会产生用量的节点和连线，再与账单项目核对。某个项目当前金额很小，也应保留名称和假设，因为业务规模或保留策略变化后，它可能成为主要成本。没有收费的项目可以标为当前不计费，不能直接从模型中消失。
第 2 类问题是单位和时间窗口混用。把 MB 当成 GB、把按小时价格当成按月价格、把每百万次价格直接乘请求总数，都可能造成数量级错误。数据传输还要区分传入、传出和计费边界。保留单位参与计算，并让另 1 位同事从结果反推输入，通常比反复检查小数点更有效。跨月比较时，也要核对运行天数和资源是否整月存在。
第 3 类问题是平均值掩盖峰值。按月平均请求数配置实例，可能在促销开始时立即排队；为偶发峰值长期配置过多容量，又可能持续闲置。可以先给出常态容量、峰值容量与扩容触发条件，再验证扩容所需时间是否小于流量上升时间。成本模型不需要求出完美配置，但必须让容量假设与真实的流量形状相容。
第 4 类问题是把降低价格当成全部优化。减少实例数量后，如果超时增加，用户重试又把工作量推高，总费用可能回升，单位成功成本也会恶化。类似地，删除所有诊断日志可能降低当月存储费，却延长故障定位时间。应优先去除不产生业务价值的重复工作，再比较容量、价格和保留策略，每次调整都观察体验与成功结果。
第 5 类问题是用缓存收益重复记账。例如假设缓存使数据库请求减少 50%，又在应用工作量里再次扣掉同 1 部分查询费用，可能把收益算了 2 次。缓存自身也有运行、维护和失效成本，而且库存与价格信息有一致性要求。入门方案可以先写“哪些读取允许缓存、预计减少什么工作、由什么实验验证”，不要把未经验证的命中率当成确定节省。
最后是只保留最终金额、不保留假设版本。模型输入可能来自不同日期，接口实现和计费政策也会变化。应记录版本、负责人、数据窗口与适用容量区间，并说明哪些输入已测量、哪些仍为估计。模型更新后能够解释“哪项假设改变了结果”，团队才不会每次看到新账单都重新争论历史口径。可追溯比表格外观复杂更有用。
8 案例：订单系统相关故障
某零售站点在促销开始后出现创建订单变慢。用户看到等待提示后再次点击，部分客户端也自动重试。系统最终没有生成大量重复订单，因为幂等逻辑仍然有效，但入口请求和日志量明显上涨。值班人员最初看到成功订单数没有大幅下降，误以为只是访问变多；当数据库连接等待和 p95 延迟持续升高时，才发现大量容量正在处理重复尝试。
用对齐的 15 分钟窗口观察，逻辑创建量约为 10 万，入口尝试从相似负载时的 12.5 万增加到 22 万，重试放大从 1.25 升到 2.2；成功订单从 9.5 万变成 9.2 万。应用副本增加后，连接等待仍未缓解，日志量继续上升。这些数字说明新增入口流量没有转化为相同比例的新增业务结果，也说明仅看请求吞吐会误判系统是否正在恢复。
进一步检查发现，最近的版本让创建路径多执行了 1 次不必要的数据库查询。在平时，这次查询只增加少量延迟；促销峰值时，数据库连接开始排队。客户端的超时期限先被触发，订单有时仍在服务器继续执行，于是重试请求进入同 1 条拥堵链路。增加应用副本提升了上游并发，却没有增加数据库处理能力，反而让等待更明显。
处理顺序首先围绕恢复服务。团队按既定回滚流程恢复原查询路径，限制无节制重试，并在入口控制超出承载能力的新工作。对于结果未知的创建请求，引导客户端使用幂等标识查询已有结果。监控显示数据库等待下降、p95 回落、重试放大逐步接近基线后，再逐步解除临时措施。每个动作都保留时间点，便于判断恢复与哪项变化相关。
成本影响不应直接用 15 分钟异常比例乘整个月账单。固定容量可能已经支付，异常主要增加请求相关执行、日志和网络用量，也可能触发临时扩容或新的计费台阶。团队按故障持续时间记录额外尝试和资源小时，再用实际计费规则估算增量。受账单延迟影响，先给区间，结算数据完整后再核对，避免把短时峰值夸大成整月损失。
复盘后的长期改进包括查询路径回归检查、客户端重试预算、连接等待告警，以及以成功订单为分母的成本趋势。这里的关键并非单纯少发请求，而是让系统花费的工作能够更稳定地形成业务结果。幂等保障数据正确，容量控制保护处理能力，成本观测帮助发现浪费；这些机制相互配合，才能让优化后的账单和用户体验同时得到解释。
9 排查案例：证据链怎么写
继续使用这个故障，写证据链时先把问题变成可核验的陈述：“某日 10:00 至 10:15，逻辑创建量相近，入口尝试数与单位成功订单的可变用量增加。”这里刻意先写用量，因为实时账单尚未完整。范围包含生产订单 API，时间使用约定时区，成功定义采用可靠保存的去重订单。没有这些限定，后续数字即使都来自真实系统，也可能无法互相比较。
第 1 组证据用于确认业务变化。记录逻辑创建量、去重成功量、入口尝试量及其来源，并列出对照窗口为何可比。促销日期不同、商品组合不同或客户端版本变化，都可能影响单次工作量。没有完全匹配的对照时，应明确差异，用同窗口内的变化和其他信号辅助判断，而不是把相邻的 15 分钟自动当成可靠基线。
第 2 组证据用于定位工作增加的位置。入口计数确认尝试放大，幂等命中确认部分尝试来自同 1 业务意图，追踪样本显示数据库等待增加，查询统计显示创建路径多了额外调用。日志采样可以提供具体请求例子，完整计数则用于估算规模。样本证明某条路径确实存在，聚合指标说明它影响多少请求，两者承担不同任务。
第 3 组证据用于排除其他解释。检查价格是否变化、是否增加日志字段、是否重复采集、是否切换分摊规则，以及是否有其他服务占用共享数据库。若网络费用看起来上涨，还应核对传输方向和统计窗口。排除不等于凭经验写“应该没有”，需要保留配置记录、变更时间或对应计量数据；暂时拿不到的证据，就标记为待确认。
接着把事实、推断与验证动作分开写。事实可以是“10:03 数据库等待上升，10:05 客户端重试增加”；推断可以是“新增查询导致排队，排队触发超时与重试”；验证动作可以是回滚查询后观察等待和放大系数是否下降。时间先后有助于提出假设，但单靠相关变化不能证明因果，还要结合执行路径、变更内容和恢复表现。
成本计算也要形成可追溯链条。额外尝试来自入口计数减去对照估计，额外日志量来自采集字节差，临时实例小时来自资源运行记录。随后逐项应用对应单价，明确哪些费用已包含在固定容量里，哪些跨过了新台阶。恢复后费用尚未下降，可能只是账单延迟；恢复后单位成本仍偏高，也可能是成功量尚未回升。结论要等待相关窗口的数据补齐。
最终记录可以按“问题范围、证据、假设、验证、费用影响、后续动作”组织。给每项行动指定负责人和验收信号，例如重试放大回到目标区间、正常负载下 p95 达标、单位日志量恢复基线。仍然未知的共享费用分摊可以留作后续调查，不妨碍先确认并修复已经有证据的请求放大。好的证据链允许别人沿着同样的数据重新检查结论。
放进方案里
在零售订单 API 方案中，成本部分应先声明服务边界与成功口径。本方案覆盖入口、创建应用、数据库、消息、网络、日志及备份，以订单可靠保存后的去重数量作为成功订单数；支付通道、物流和人工另行核算。估算窗口为 30 天，统一币种与时区，价格来源、有效日期、共享资源分摊规则及未覆盖项目随模型保存，确保后续账单能够按相同边界核对。
业务基线写为 240 万个逻辑订单、300 万次创建尝试、228 万笔成功订单，说明重试放大为 1.25，月平均速率仅供估算。容量另按促销峰值、处理时间和数据库承载能力验证，并保留扩容提前量。教学价格下总成本为 2000 元，每 1000 笔成功订单约 0.877 元；这些金额用于说明计算方法，正式决策须替换为实际报价与测量用量。
方案应并列展示常态、增长与故障情景，逐项说明哪些费用随请求变化，哪些在容量范围内固定，何时会发生升级台阶。优先控制重复执行、无界重试和重复采集，再评估规格与保留期限。任何降本措施都要同时给出成功率、延迟和数据可靠性的验收条件；缓存、缩容或减少日志必须说明业务约束与回退方式。
运行期由服务负责人维护业务量、重试放大、主要计费用量和单位成功成本趋势，按约定周期对齐账单。预算异常先核对时间窗口、计费单位与业务增长，再沿请求、依赖、资源的路径定位。重大变更后更新模型版本，故障后记录额外工作量、增量费用和验证证据。上线评审以可追溯的假设、容量验证和观测责任作为通过依据，并列出仍待确认的输入及完成期限。
10 小结：检查清单
提交订单 API 的成本模型前，逐项检查：
- 是否写明服务边界、时间窗口、币种和成功订单定义？
- 是否区分逻辑订单、创建尝试、去重成功量与重试放大？
- 每行费用是否保留计费单位、用量来源、单价依据和分摊规则？
- 是否覆盖应用、数据库、存储、备份、网络、日志与消息？
- 是否同时观察总费用、成功量和单位成功订单成本？
- 是否用峰值与压测验证容量，标出固定费用适用范围和升级台阶？
- 是否为重试、幂等、日志保留和观测字段写明约束？
- 是否能用一致窗口的业务、请求、资源与账单证据解释偏差？
用 2 个问题自测：总费用不变而成功订单减少，单位成功成本会怎样变化？增加应用实例却让数据库等待更长时，应先检查哪段工作正在被放大？能说明分母与依赖容量的作用，就已经掌握了本课的核心方法。
下一课转向 P7 风险识别：把本章验收过的结论带进后续主题，写成可检查的方案约束。