什么是解决方案

1 为什么需要「解决方案」而不只是买产品

老板说“门店要做线上订单”，采购清单很容易随之出现：服务器、数据库、存储、网络。买齐它们之后，顾客仍可能付款成功却查不到订单，店员仍可能把已售出的库存再次卖出。产品提供能力，却不会替团队定义订单何时算成功、库存由谁更新、故障时谁来恢复。解决方案要把这些关系连起来，让业务问题有可执行、可检查的处理路径。

可以把解决方案理解为“问题界定＋选定路径＋验收办法”。问题界定回答为谁解决什么，选定路径说明组件、数据和人员怎样协作，验收办法约定拿什么证据判断完成。任何部分缺失，都可能出现“每个产品都正常，整件事却没有做好”的情况。例如数据库可以接受写入，并不意味着订单接口在重试后不会生成重复订单；后者还需要订单标识、接口约定和核对流程。

Stage1 已经接触操作系统、网络与 HTTP，也练习过用进程状态、连接结果和响应记录寻找证据。进入 Stage2，先把观察尺度扩大：某次 HTTP 请求返回成功，只能证明该次交互的局部结果；顾客能否取货，还取决于订单落库、库存同步和门店处理。学习云产品时也应保留这个尺度。点击控制台之前，先写清产品将承担的责任，以及责任之间的交接条件。

假设团队有 4 周时间、首季度每月最多 8000 元预算。如果先购买最熟悉的资源，再补写目标，资源选型往往反过来限制问题定义。若先确定“20 家门店可以接收线上订单，异常订单能在 30 分钟内恢复处理”，就能检查哪些能力必要、哪些功能可以后移。方案的价值在于把投入与结果相连，也让未被解决的问题提前显露。

2 方案回答什么：需求、约束、取舍与可验证结果

方案的输入包括业务目标与约束。业务目标解释为什么值得做，例如减少漏单、缩短确认时间；约束限定可接受的实现空间，例如交付日期、预算、已有软件接口和团队值班能力。用户提出的“必须用某种数据库”应先确认来源：它可能是合同要求，也可能只是熟悉某个产品。前者进入约束，后者应作为候选偏好，不能直接替代比较。

方案的输出至少包含架构决定、承担的风险和验证路径。架构决定需要解释应用部署在哪里、订单保存在哪里、系统之间如何同步；风险需要写出触发条件、后果和责任人；验证路径需要说明测试数据、执行步骤与通过条件。这样，评审者才能沿着“目标为何需要这个决定，这个决定如何被验证”的链条追问，而不是围绕产品知名度投票。

以漏单为例，业务负责人周宁提供的当前基线是：最近 1000 笔已付款交易中，有 8 笔在门店端找不到对应订单。目标可以写为“上线后连续观察 30 天，已付款但门店端缺失的订单比例不超过 1/1000”。分母来自支付账单中的唯一交易号，分子通过支付账单与订单表关联得到，排除测试交易与明确取消的交易，排除规则也必须记录。否则双方可能用不同口径证明自己正确。

交付验收与长期成效应分别约定。上线前用 1000 笔带唯一标识的测试交易回放，要求缺失订单为 0，重复履约为 0；上线后再按上述口径观察 30 天。前者证明已覆盖的场景通过，后者检验真实运行表现，测试通过不等于已经证明未来 30 天的比例达标。方案应列出观察期负责人和未达标后的修正安排。

还要描述指标之间的冲突。如果为降低漏单而让顾客等待很久，订单完整性改善可能伴随放弃购买增多。因此同时约定：在规定负载下，提交订单接口响应时间 P95 不超过 800 毫秒。P95 表示 95% 的观测值不高于该值，它不代表每次请求都满足。成功指标可以有多个，但每个都要能够定位数据来源，不能只写“体验明显提升”。

3 方案文档最小骨架：背景、目标、范围、架构、风险

最小骨架的作用是暴露决策空白。它可以从 1 页开始，测试脚本、报价依据和接口说明作为附件链接。页面顶部写版本、作者、业务负责人、技术负责人和评审日期；例如“v0.3，方案负责人林岚，评审日期 2026-11-06”。负责人不是装饰：当库存数据与门店反馈冲突时，必须知道谁负责给出最终口径。

背景字段写现状和证据：“20 家门店分别登记线上咨询，最近 1000 笔已付款交易漏单 8 笔，依据为抽样核对表。”目标字段写期望变化和测量周期。范围字段写本期处理与暂缓处理的边界，例如本期支持门店自提，不做跨仓调拨。背景可以被原始记录核对，目标可以被统计推翻，范围可以逐项判定是否包含；这就是字段应当可检验的含义。

架构字段不能只有组件方框，还要标出入口、数据去向、身份边界和异常流向。例如微信或网页调用订单 API，API 写入订单数据库，再由同步任务通知门店；通知失败进入重试记录，由值班人员处理。若“支付成功”来自外部支付回调，必须画出回调进入的位置及验签责任。否则评审者看到的是设备布局，无法判断业务链路是否闭合。

风险字段写“事件—影响—措施—负责人—检查日期”。例如“门店库存接口中断超过 5 分钟，将暂停该门店线上接单；集成负责人陈旭在联调日验证暂停与恢复流程”。风险不必伪装成已经消除的问题。写出残余风险及接受人，比用“全面保障连续性”覆盖未知更有用。首版还应预留费用、选项和验收字段，使采购、交付与运行使用同一组边界。

“打造先进平台”“赋能智慧零售”“实现极致体验”不能独立占据上述任何字段，因为没有观察能直接证明它们错误。如果这些话来自立项材料，应继续追问其具体含义，再替换成业务动作与指标。文档可以很短，但不能用空泛口号掩盖没有决定的内容；尚未确认的字段明确标为待验证，并附负责人和截止日期。

4 从症状到需求：可测陈述 vs 愿望清单

“要上云”描述了一种实施方向，“要高可用”表达了期待，它们都不足以直接验收。改写的第一步是记录症状与影响：周末接单中断过多久，哪些用户受影响，是否有证据支持原因判断。门店说“系统慢”时，可能是浏览图片慢，也可能是订单确认慢。若未经测量就增加服务器，图片链路的问题可能仍然存在，账单却已经增长。

可测陈述可以采用“在什么条件下，哪个对象，达到什么阈值，怎样检查，由谁负责”的结构。把“要上云”改为：“在 4 周内，将 20 家门店的微信与网页订单接入统一订单 API；交付负责人林岚组织 200 笔订单/小时的回放，业务负责人周宁核对订单号与门店归属，要求缺失及错店订单均为 0。”是否上云成为实现选择，业务验收有了独立依据。

把“要高可用”改为：“订单 API 因应用节点故障不可用时，恢复时间目标 RTO 不超过 30 分钟；运维负责人许晨从监控确认不可用的时刻开始计时，到探测请求连续 5 分钟成功为止，并保留告警、操作和探测记录。”这里的 5 分钟确认窗口计入恢复耗时，避免不同人员对结束时刻产生分歧。机房整体故障是否包含在承诺内，也要另行列明，不能用某次节点演练代替所有故障证明。

恢复服务与恢复数据又是不同问题。可以补充待验证条目：“订单数据库恢复点目标 RPO 不超过 5 分钟；数据库负责人陈旭通过恢复演练核对最后可恢复交易的时间。”RPO 约束可能丢失的数据时间窗口。即便达到它，也不能默认允许永久丢失已付款订单，支付账单对账与补单仍要覆盖差额。这里先把指标对象写清，具体恢复策略与非功能需求设计留到 P3 展开。

预算也要从愿望改成边界：“首季度每个自然月，生产环境云资源账单不超过 8000 元，包含计算、数据库、对象存储、公网出流量、备份与监控；财务负责人赵敏每周查看费用预测，达到 6400 元时通知方案负责人复核。”6400 元是预算的 80%，告警是检查触发器，不表示超过后必须立刻停服务。人力、短信和支付手续费是否另列，要在同一条目中说明。

这些条目首次写下时可以是草案。若 30 分钟来自老板直觉，就注明“业务待确认”；若恢复脚本还没演练，就注明“技术待验证”。需求基线应记录确认日期和更改原因。与其把未经验证的数字写成承诺，不如明确需要补哪项调查、何时补齐；但“待确认”也不能无限延期到上线当天。

5 约束与非功能：可用、安全、成本、合规怎样写进方案

功能说明系统做什么，非功能需求约束它在什么条件下做到什么程度。本课先用 4 类检查入口，避免遗漏重要限制。可用性关注服务中断、恢复和依赖；安全关注谁能访问、凭什么授权、如何留痕；成本关注计费边界与负载假设；合规关注数据处理必须满足的规则。它们彼此影响，不能在架构确定后才作为附录补齐。

可用性可以同时记录月度目标与恢复目标。若按 30 天、全天服务计算，99.9% 的可用率对应不可用预算约 43.2 分钟，99.99% 对应约 4.32 分钟。这个换算帮助理解目标严格程度，但不证明架构能够达标。统计应明确探测频率、维护窗口是否计入，以及“无法提交订单”怎样判定。单次 RTO 为 30 分钟，也不保证当月累计中断小于 43.2 分钟。

下表为同一零售负载下的教学估算，单位为元/月。基础项包含应用计算、数据库或磁盘、对象存储和监控；出流量与备份单列，预留额用于估算偏差。它不是厂商报价，也不是可用率保证。

从 B 扩展到双 AZ，估算总额约为 1.5 倍，超出 8000 元预算 1300 元。增加故障隔离能力是否值得，需要业务损失、故障范围和恢复实测共同支持。若业务要求覆盖整个 AZ 故障，单 AZ 路径就不能仅凭价格低继续入选；应调整预算、范围或明确暂停交付决定，而不是修改口径让表格看起来达标。

安全条目可以写成“数据库仅接受应用身份和受控运维入口访问，公网连接测试应失败，运维操作可关联到实名账号”。合规条目可以写成“订单手机号的用途、保存期限、删除规则与备份处理方式，由数据负责人提交清单，在上线前经法务确认”。不要自行假定某个期限满足所有适用规则。安全与合规约束都需要检查材料，购买加密服务或选择某个地域不能单独证明完成。

6 选项比较：至少 2 套可行路径与否决理由

比较应先统一范围与负载，再讨论优劣。这里比较都覆盖 20 家门店、峰值 200 笔订单/小时、首季度每月 8000 元上限，并假设现有订单程序可以改造为独立 API。若某个选项少做库存同步，它的低价格就不能直接与完整方案比较。先检查硬性约束，未通过的路径标为淘汰或有条件候选，再对剩余路径评分。

路径 A 是把现有程序迁到虚拟机，数据库继续自管，图片迁入对象存储。它能保留较多系统控制权，但团队要负责数据库补丁、备份恢复和故障值班。估算月资源费 4600 元，实施需要 28 天，月运维投入约 24 小时。它的可行性前提包括：已有可用的数据库运维人员，且迁移和恢复演练在交付日前完成，不能只因为代码改动少就认定最省事。

路径 B 保留应用计算层，将数据库交给托管服务，图片使用对象存储。估算月资源费 6200 元，实施需要 21 天，月运维投入约 10 小时。团队仍负责表结构、权限、备份策略确认、应用重试和业务对账。托管降低部分维护工作，也限制部分底层参数与扩展方式；若应用依赖不受支持的数据库插件，就必须重新验证迁移成本。

为了使讨论可追溯，可用 1—5 分表示满足偏好的程度，分数越高越符合当前团队需要。“控制”指可调整底层环境的自由度，“运维”指本团队维护负担较低，“成本”只比较资源费，“见效”指在期限内交付的把握。权重依次为 20%、30%、20%、30%，依据是团队人少且只有 4 周交付窗口。

例如 B 的得分为 3×0.2＋4×0.3＋3×0.2＋5×0.3＝3.9。评分只是整理判断，不能推翻硬约束，也不能把主观分数伪装成精密测量。这里暂选 B，条件是数据库兼容性与恢复测试通过；A 保留为备选，前提是落实额外运维能力。若给运维时间按 150 元/小时估值，A 另需 3600 元，B 另需 1500 元，资源费更低并不自动意味着总投入更低。

路径 C 是同时引入容器编排、多个微服务和双 AZ 部署。当前估算月资源费 12800 元，实施 45 天，团队还缺少值班经验，因此因预算与期限同时不符而否决。否决理由应保留在决策记录中，并写明重新评估条件，例如业务规模增长、预算获批且团队具备运维能力。这样后来的人才能理解当时为何没有选择功能更多的路径。

7 常见坑：堆砌产品名、忽略运维、把 PoC 当上线

第 1 类坑是把规格清单当作架构。某团队的评审页列出 2 台虚拟机、1 个数据库、1 个存储桶，看起来组件齐全，实际所有订单都写入同一块未做恢复验证的磁盘。应用节点有 2 台并没有消除数据恢复风险。修正方法是沿 1 笔订单画出请求与持久化位置，逐段问“这里失败后，顾客看到什么，数据在哪里，谁能恢复”。清单可以用于采购，不能替代责任与数据流。

第 2 类坑是预算只覆盖上线当天。某方案把数据库交给开发人员维护，却没有安排备份失败告警和休假替班。第 1 次恢复时才发现备份连续 3 天未成功，文件存在也不能用于恢复。方案需要写明备份执行频率、失败通知对象、恢复抽检周期和替班人。值班负责人应能指出最近的恢复记录；“系统自动备份”只是能力描述，不能证明数据可恢复。

第 3 类坑是把概念验证 PoC 当作上线证明。PoC 可以验证托管数据库是否兼容某条查询，也可能只用约 40 条假数据和单个测试账号。曾在演示时为方便联调，把数据库入站规则开放为 0.0.0.0/0，即允许所有 IPv4 来源，之后直接沿用到生产环境。即使仍需密码，这也扩大了暴露面。上线前应核对测试入口与生产入口，收紧数据库访问源，轮换测试凭据，并记录外部访问应被拒绝的检查结果。

还有团队只准备“部署成功”的路径，没有回退设计。新版本写入了旧版本不认识的订单状态，回滚应用后旧程序无法处理这些记录，服务依旧异常。因此回退需要同时考虑代码、数据结构、正在处理的交易与外部副作用。数据库变更可先采用兼容新旧版本的方式；若某项数据转换不可逆，就要设计前向修复或暂缓发布，不能把“换回旧镜像”写成完整恢复办法。

这些失败的共同点是验收证据只覆盖顺利演示。可以在发布清单中增加 3 个具体问题：权限边界是否实测，备份是否恢复过，失败发布是否演练过。每个问题对应可打开的记录和负责人。PoC 的结论也应保留适用范围，例如“已验证驱动兼容，尚未验证负载、恢复和生产权限”，避免有限证据被扩大解释。

8 案例：小微零售「线上订单」方案一页纸

下面把前面的判断压成可评审的 1 页摘要。数字用于贯穿案例，真正交付时应链接到调研记录、估算表和测试结果。页面短不意味着细节不存在，而意味着关键决定及其依据可以迅速找到。

背景与责任。 20 家零售门店准备接收微信和网页订单，预计峰值 200 笔/小时。现有漏单基线为每 1000 笔已付款交易 8 笔。方案 v0.3，业务负责人周宁、技术负责人林岚、运维负责人许晨，2026-11-06 评审；目标交付日期为评审通过后 28 天。门店店员处理取货，顾客查询订单，总部维护商品与门店关系。

目标与范围。 MVP 即最小可用版本，支持下单、支付结果接收、订单查询、门店库存同步和到店自提。上线前回放 1000 笔测试交易，缺失订单及重复履约均为 0；上线后连续 30 天的已付款漏单比例不超过 1/1000。本期不包含多仓分配、跨仓调拨、配送路线优化和复杂促销。需要这些功能的订单不能悄悄进入人工无记录流程，应在入口明确限制并留待后续评审。

架构与数据。 采用路径 B，应用 API 接收微信及网页请求，托管数据库保存订单、支付关联号、库存快照与同步状态，对象存储保存商品图片。图片地址不能承担订单事实记录。支付回调先校验来源与签名，再用唯一交易号更新订单状态；同一回调重复到达不得重复扣减或重复履约。门店系统仍是实际库存来源，总部快照必须带门店编号、更新时间和同步批次号。

同步与异常。 同步任务每 60 秒拉取门店库存变更，正常情况下库存快照新鲜度目标不超过 120 秒。连续 5 分钟未更新时暂停该门店线上接单并通知店长，恢复同步并核对后再开放。最终库存确认在提交订单时完成；库存源无法确认就返回暂不可下单，不能仅凭旧快照承诺有货。若旧系统没有原子预占接口，MVP 必须先划分线上可售配额并由门店维护，接口能力未确认前不得开放无边界售卖。

性能与恢复。 负载测试持续 1 小时，产生 200 笔订单，同时施加每秒 20 次混合请求，包含浏览、查询和提交，记录请求比例。提交订单 P95 不超过 800 毫秒。节点故障的 RTO 目标为 30 分钟，数据库 RPO 目标为 5 分钟；已付款交易通过对账补齐，恢复时间测量口径沿用第 4 节。单 AZ MVP 不承诺 AZ 整体故障下的同等恢复时间，此残余风险需由业务负责人明确接受。

费用与选择。 B 的应用计算 1800 元、托管数据库 2200 元、对象存储 200 元、监控 400 元，基础项共 4600 元；加公网出流量 500 元、备份 300 元和预留额 800 元，合计每月 6200 元。预算上限 8000 元，人力与支付手续费另列。出流量暂按 500 GB、每 GB 1 元估算，备份按 300 GB、每 GB 每月 1 元估算，均为教学单价。上线前赵敏要用实际计费规则替换，注明免费额度、保留周期与地区差异。

上线与风险。 先选择 2 家门店灰度 1 天，再根据验收记录决定是否推广到 20 家。门店接口不支持库存预占、数据库兼容性不符、恢复演练失败，任意情况出现都阻止推广。许晨执行发布和回退，陈旭核对数据与对账，周宁确认业务结果。回退期间已付款订单继续登记与履约，不允许通过删除新订单来恢复旧版本。

9 排查案例：方案评审被打回的 3 类证据缺口

评审退回不一定表示技术选型错误，也可能是证据不足以支持决定。假设上述零售方案首次送审时只提交产品截图和演示录像，评审委员会指出 3 类缺口。补材料应能让第 2 名工程师不联系作者也能复跑检查，而不是增加几句保证。

缺口 A：没有可测成功指标。 坏句子是“上线后订单体验大幅提升”。修正为：“业务负责人周宁按验收包中的 1000 笔唯一交易号回放，在订单表与门店接收记录中关联核对，缺失订单与重复履约均为 0；规定负载下提交订单 P95≤800 毫秒。测试负责人林岚提交带版本号的结果文件。”验收包需包含生成数据的种子或固定样本、请求比例、启动说明、统计查询及期望输出，手机号使用合成数据。

复查时，第 2 名工程师应能在隔离测试环境加载样本，运行回放，导出请求耗时和核对差异，再按同一规则计算 P95。只有截图没有原始结果，或者作者手动删掉失败请求后才达标，都不能通过。若新旧系统基线不同，还要说明为何可比；不能拿低负载测试与节日高峰事故直接比较。

缺口 B：没有影响范围与回退证据。 坏句子是“故障自动切换，必要时回滚”。修正为：“许晨先仅向 2 家灰度门店启用新版本；连续 5 分钟提交错误率超过 1%，立即停止扩大范围，并在触发后的 10 分钟内恢复旧版入口。陈旭核对灰度期间全部已付款交易，要求无重复履约、无未登记交易。”恢复旧版入口只是发布回退目标，仍需与整体 RTO 分别检查。

复查材料应包含灰度门店名单、路由配置、触发指标查询、回退命令及权限前提，并说明其他 18 家门店为何不受影响。演练至少制造 1 次发布失败，保留触发时间、回退完成时间与交易核对结果。灰度门店可以共用数据库，因此路由只限制部分影响；本次发布采用兼容字段的增量变更，禁止在灰度阶段删除旧字段。若做不到数据兼容，必须重新评估影响范围。

缺口 C：成本模型漏掉出流量与备份。 坏句子是“数据库和服务器每月约 4600 元，预算充足”。修正为：“赵敏按费用表逐项复算，基础项 4600 元、公网出流量 500 元、备份 300 元、预留额 800 元，每月合计 6200 元；若出流量升至 1500 GB且其他假设不变，月估算为 7200 元，仍低于 8000 元，但剩余空间缩至 800 元。”这里备份容量随保留策略变化，不能永远沿用首月容量。

复查时，第 2 名工程师从价格依据与用量表重新计算，而不是只读取合计单元格。他应能把出流量改为 2500 GB，得到月估算 8200 元并标记超预算；也应能找到备份保留天数、容量增长假设和费用负责人。最终验收要求 3 项检查都能独立执行：复现业务指标、演练受控回退、重算费用边界。执行步骤缺少环境准备或访问权限说明，同样属于尚未关闭的证据缺口。

放进方案里

接到新需求时，先创建方案接入清单，并让每项都指向证据位置。目标项写业务损失、当前基线、期望变化和观察周期，不能只填“数字化升级”。用户项列出直接使用者、运维人员与受影响的外部伙伴，说明每类人完成什么动作。约束项记录预算、期限、数据规则、已有接口和团队能力，同时区分已确认条件与待调查假设，给假设指定负责人和到期日。

选项项至少保留 2 套可行路径，使用同一业务范围、负载与计费边界，写出采用条件、资源费用、运维投入和被接受的残余风险。被否决的路径也留下具体原因，例如超预算 1300 元或晚于交付期限 17 天。验收项把目标连接到数据、步骤和阈值：谁准备样本，谁运行负载，谁核对订单，恢复从何时计时，费用按什么单价重算。仅写“测试通过”无法关闭此项。

负责人项不只列作者，还要列业务确认人、发布执行人、故障处理人和预算复核人。记录方案版本与评审日期，在上线前检查待确认项是否关闭。对于尚未解决的风险，明确由谁接受、有效到何时、出现什么信号后必须重评，不能把没有回复当作默认同意。

把清单交给未参与编写的同事，让他任选 1 个成功指标重算，再任选 1 个故障场景找到恢复步骤。如果材料只有产品名、规格和控制台截图，他可以按缺失字段退回：没有目标证据，无法判断购买是否必要；没有选项和成本边界，无法判断取舍；没有验收步骤和责任人，无法判断交付是否完成。退回意见应指向需要补的材料，而不是要求再加几页介绍。能被别人独立检查，才说明方案已经从个人理解变成团队可以执行的约定。

10 小结：走向需求调研与云服务选型

解决方案把业务问题、实现路径与验收证据连接起来。产品能力通过明确的数据流、职责、约束与取舍进入方案，目标则通过数字、口径和可复跑检查接受检验。尝试用本课的清单审阅 1 份方案：它为何选择这条路径，失败后如何恢复，第 2 名工程师能否验证结果？

P2 的需求调研将进一步处理访谈、利益相关者与需求确认；云服务 C 系列课程帮助理解候选产品的能力和责任边界。带着已写清的目标与约束学习这些内容，选型才能回答业务问题，调研也能持续修正方案中的假设。

下一课转向 P2 需求调研：把本章验收过的结论带进后续主题，写成可检查的方案约束。