1 政企与政务云方案要回答什么
同样是部署零售订单 API，面向政企或政务相关业务时，方案需要回答的不只是服务器放在哪里。谁有权决定数据用途，哪些人员能查看订单，运维人员通过什么入口操作，外部履约方能拿到什么字段，故障后按什么顺序恢复，都需要形成可执行的约定。这里的“政企”包含多种组织和行业，“政务云”也不是可以自动套用到所有项目的合规标签。业务性质、系统边界、主管要求与采购合同不同，适用的约束就可能不同。
本课沿用零售订单 API 案例：用户创建订单、查询自己的订单，后台向履约方发送必要信息。订单包含订单号、商品、金额、状态以及收件手机号和地址；日志用于定位错误，备份用于恢复。为便于练习，假设服务面向境内用户，初期峰值为每秒 200 次请求，业务提出月度可用性目标 99.9%、恢复时间目标 RTO 为 2 小时、恢复点目标 RPO 为 15 分钟。这些是待验证的教学输入，不能当作任何政务项目的统一要求。
RTO 表示中断后希望多久恢复服务，RPO 表示恢复时可接受丢失多长时间内的数据。它们与可用性比例有关联，却不能互相替代。订单已经返回成功但恢复后消失，是数据恢复问题；接口暂时不可用但订单完整保留，是服务恢复问题。需求讨论应把这 2 种影响分开，让业务负责人确认可承受的后果，并约定重复提交、延迟履约和人工补偿的处理方式。
方案工作的起点是形成要求清单：业务功能、性能、数据范围、部署边界、运维身份、接口依赖以及恢复目标。每条要求写明来源与确认人。来源可能是法律法规、适用标准、主管部门规定、组织制度或合同，不能把会议中的个人偏好直接写成法定要求。对于尚未确认的事项，应标成待确认约束，说明它会影响哪些决策和何时必须解决。
在这条链条中，架构图说明控制放在哪里，流程说明谁在什么条件下执行，证据说明执行结果怎样被复核。只画网络分区，无法证明账号离职后会及时停用；只写管理制度，也无法证明数据库确实拒绝了越权请求。合格的入门方案应能从任意重要要求追到控制、责任人和验收方法，再从运行变化回到要求清单。后续各节都用这条线索检查订单系统。
2 等保、密评与数据分类
等保通常指网络安全等级保护制度相关工作。对方案设计而言，首先要明确保护对象和业务边界，再由责任单位按适用程序开展定级、备案、建设整改、测评及持续管理等工作。不能因为使用某种云服务，就直接推断订单系统已经满足某个等级的全部要求；也不能仅凭“处理订单”这个功能名称自行给出正式等级结论。云平台与业务系统可能有各自的边界，平台提供的材料需要与应用自身的责任对应。
密评通常指商用密码应用安全性评估，关注适用场景中的密码应用是否符合相关要求。它与等保存在联系，但不是可以相互替代的同一项工作。项目是否需要开展、适用什么范围，应由责任单位结合有关规定确认。入门阶段先理解密码需要服务于身份鉴别、传输保护、存储保护等目标，以及密钥由谁生成、保管、使用和停用。算法细节和专门的密码协议设计留到后续课程，不在这里自行创造。
数据分类解决“数据是什么、影响是什么、应怎样保护”的问题。分类可以先按业务用途区分订单交易、收件信息、运行日志、配置和审计记录，再结合适用制度开展分级判断。手机号、地址在本案例中涉及个人信息；某批交易数据是否属于重要数据，需要结合适用规则、目录及认定程序，不能凭字段名称草率判断。匿名化与脱敏也不能混用：日志遮盖部分手机号，不等于数据已经无法关联个人。
可以为订单 API 建立字段台账，记录字段来源、处理目的、使用环节、接收方、保存位置、留存规则和删除方式。例如收件地址用于履约，通常不应进入普通性能日志；请求标识用于排障，应避免直接编码手机号。保留多久需要目的和制度依据，不能统一写成“永久保存”。备份中的副本、导出的表格和工单附件也在台账范围内，删除流程需要考虑副本更新周期与实际可执行性。
控制设计还要区分保护对象。传输加密可以降低链路被窃听的风险，却不能阻止已获权限的应用将完整地址写入日志；数据库加密也不能代替查询权限限制。方案应逐项问：防谁、保护什么、在哪个环节生效、失败时如何发现。对于密钥，还需区分密钥管理权限与业务数据访问权限，避免同个日常运维账号同时拥有所有能力。具体分离方式由系统规模和适用要求决定。
完成这些工作后，等保、密评、数据分类不再只是文档中的 3 个名词。它们分别促使团队明确系统保护责任、密码应用安排和数据处理边界，并共同约束架构与运行。正式的合规结论需要相应程序和证据，本课练习产出的是可供评审的设计输入，不能替代测评或法律判断。
3 专有云与公有云边界
专有云强调为特定组织提供专用的资源或环境，但名称本身没有说明机房归属、设备所有权、租户隔离方式和运维权限。公有云通常由服务方提供面向多个客户的资源，也可以提供不同程度的隔离与访问控制。比较时应拆开看物理位置、逻辑隔离、控制面访问、服务人员权限和合同责任，不能把“专有”直接理解成绝对安全，把“公有”直接理解成不允许使用。
订单 API 至少可以提出 3 种备选：全部部署在满足约束的公有云环境；全部部署在经批准的专有环境；将部分公开入口和核心订单处理分开部署。每种备选都要列出适用前提。若已确认核心数据必须在指定环境处理，违反该约束的选项应先排除。若没有这种限制，就继续比较运行能力、服务可用性、采购周期和总体成本，而不是凭环境名称提前得出结论。
组合部署尤其要说明边界上经过什么。公开静态页面可以与订单库采用不同位置，但页面引用的脚本、访问分析和错误上报仍可能处理用户信息。若入口转发完整订单请求，入口所在环境也是数据处理路径的一部分。图上画出“核心区”并不意味着外围没有责任。网络连接应按实际业务方向说明身份、协议、必要字段及失败处理，避免只画 1 条没有含义的双向箭头。
成本比较要使用相同口径。计算资源只是其中部分，还包括数据库、存储、备份、网络、日志、密码相关服务、测评整改配合和持续运维。专有环境还可能涉及容量预留、设备更新、机房条件与驻场支持；公有云可能涉及数据传输、调用和留存费用。已有资源也不是没有成本，应区分新增现金支出与内部资源占用，并说明采用哪种口径。
例如把每月资源与服务费用记为 A，网络与备份费用记为 B，运行人力折算为 C，初次实施费用记为 D，可先用“年度估算 = 12 × (A + B + C) + D”比较。这个算式不用于制造精确报价，而是暴露遗漏。还应分别估算正常负载与恢复期间所需资源，记录价格来源、容量假设及误差范围。只有满足硬约束的方案，才值得继续比较价格优势。
4 动手：映射一次合规控制到架构
这次动手不需要创建真实云资源。先用虚构字段和组织要求，完成可审阅的控制映射。假设责任单位提出：“收件信息仅供获批履约用途使用，普通运维人员不得直接查询明文，普通应用日志不得记录完整收件信息。”这句话还不是完整验收标准，需要拆成数据范围、允许主体、允许用途和禁止路径。若“普通运维人员”范围不清，先补角色定义，避免团队各自理解。
第 1 步，画真实数据流。创建订单经入口鉴权后进入 API，API 写入订单库，履约消息送到获批接收方；日志经过字段过滤后进入日志平台；数据库产生备份。运维人员通过受控入口操作，访问数据库另行授权。将收件字段标在经过的箭头旁边，把不应携带这些字段的日志路径单独标出。配置中心、告警和客服导出若参与实际处理，也需要补进图中。
第 2 步，把要求分配到明确位置。入口验证调用者身份，API 校验用户只能查询自己的订单；履约接口按字段白名单组织消息；日志组件只输出请求标识、错误码和耗时；数据库限制业务账号和运维角色的权限。网络规则只允许必要连接，无法代替订单归属校验。存储保护与密钥权限按适用要求设置，并写出负责配置与复核的角色。
第 3 步，补流程。履约方接入前确认目的、字段、接收位置、留存与责任；新增运维权限经过申请和复核，紧急授权有期限与事后检查；发布时审查日志样例与依赖配置。这里无需堆满审批节点，重点是让高影响动作有明确入口、执行人和结束条件。临时账号不能只写“审批通过”，还应说明到期如何停用以及停用失败由谁处理。
第 4 步，设计验证。使用虚构用户分别请求自己的订单和其他用户的订单，确认越权访问被拒绝；模拟请求失败，检查日志中没有完整手机号和地址；用普通运维角色尝试读取受限数据，记录拒绝结果。再抽查授权流程与密钥操作记录，确认架构上的限制和人员流程能够对应。验证材料应关联版本、环境、执行时间和执行人，便于后续复核。
第 5 步，记录剩余问题。例如客服排障确需查看部分收件信息，可以提出独立角色、按需授权、显示脱敏和访问审计的候选控制，再交业务与安全负责人确认。不能为了让表格全绿，就默许共享管理员账号。练习的完成条件是每条要求都能追到控制位置、运行责任与验证结果；暂未解决的项进入风险清单，标明影响、临时措施、责任人和计划日期。
5 开放能力与安全隔离取舍
订单系统需要与履约、支付状态核对、客服等能力交互，完全关闭连接会影响业务。但开放也不是把所有系统放进同个网络。先按业务目的划定接口：谁调用谁、用什么身份、需要哪些字段、调用频率多少、出错后怎么办。对外接口的数量只是管理负担的部分指标，接收方数量、权限差异、字段敏感程度和供应商依赖同样影响复杂度。
以履约通知为例，API 可以先提交订单并记录待履约状态，再由队列异步发送通知。这样接收方短时故障不必立刻拖垮创建订单，但也带来延迟、积压、重复发送和状态核对的责任。接收方应能按订单号或约定的事件标识识别重复请求，系统应提供失败重试与人工处理入口。不能写“接入消息队列即可保证不丢单”，而应验证订单记录、消息状态与实际履约结果是否可核对。
隔离还涉及运维和供应链。远程支持人员是否可以直接连生产库，诊断工具是否向外发送信息，依赖组件是否有默认遥测，都属于边界设计。可以通过受控运维入口、必要权限、获批出口和变更记录降低风险，但每个控制也需要运行维护。出口规则过宽会留下未知路径，过窄又可能使证书更新或必要故障处理失败，因此要列出允许依赖并验证异常时的行为。
滑块展示的是接口数量变化带来的示例复核工时和费用，不代表真实安全程度。把接口从 3 个减到 1 个，可能减少接入评审，也可能把不同用途揉进同个接口，反而扩大权限。正确的讨论方式是询问每个接口是否必要，是否能缩减字段和权限，是否有稳定的接收方责任。成本应同时计入业务等待和人工补偿，不能只计算设备或网络开销。
高可用设计也必须遵守已确认的数据边界。为 API 设置不同故障域的实例、为数据库采用受支持的高可用部署，可以减少部分故障影响；如果实例共用无法恢复的身份服务或网络出口，仍可能一起不可用。异地备份和跨区域切换需要先确认位置及数据处理约束，不能为了追求可用性自动跨越获批边界。选项受限时，应把恢复能力的限制明确交给业务决策。
备份成功不等于能在 2 小时内恢复。应在获批的隔离环境验证还原、密钥可用、应用连接和订单核对，记录实际耗时与可恢复时间点。若演练超过 RTO，或者恢复点早于允许的 RPO，就调整备份频率、恢复资源或业务承诺。高可用、备份和灾难恢复分别应对不同故障，需要组合验证，不能用其中任意项替代其他项。
6 常见坑：只堆产品清单无流程
常见的方案写法是罗列防火墙、堡垒机、日志平台、密钥管理和备份服务，最后写“满足安全合规”。问题在于，清单没有解释这些能力怎样约束订单处理。即使采购全部完成，共享账号仍可能长期有效，履约方仍可能收到多余字段，备份也可能无法恢复。产品能提供能力，系统能否正确使用以及人员是否持续执行，需要另行设计和验收。
可以用“控制、触发、执行、证据、例外”检查每项安排。例如运维访问的控制是受控入口与最小权限，触发是人员申请或紧急事件，执行包括审批、授权和到期停用，证据包括申请记录和操作日志，例外需要有期限及补偿措施。若缺少结束条件，临时授权就会变成永久权限。若只留下审批截图，却无法对应到实际账号，也无法证明控制已生效。
第 2 类坑是把所有责任写给云服务方。服务方可能负责底层设施或某项托管能力，业务团队仍需要负责订单权限、字段用途、应用依赖和配置。具体边界应依据服务范围与合同明确。例如数据库由服务方维护，并不自动表示服务方替业务决定谁能查询收件地址。方案应写出事件发生时谁受理、谁能操作、谁批准以及谁验证恢复，不要只写“联系支持”。
第 3 类坑是证据失去上下文。截图没有环境、时间和版本，可能证明的是测试环境；日志没有完整性保护和访问限制，可能被随意修改；恢复报告只写“通过”，无法判断是否满足 RTO 与 RPO。初学者不必设计复杂取证系统，但需要让证据可定位、可解释、可复查，同时避免证据包本身泄露真实订单与账号秘密。留存期限与访问权限也应有明确依据。
还有一种问题是建设验收结束后无人维护。新增接口、SDK 升级、人员离岗和区域调整都可能改变原有结论。把复审嵌入正常发布和权限管理，通常比另建长期无人执行的表格有效。方案应写明触发条件，例如增加数据接收方、扩大字段范围或改变备份位置时重新评审；风险例外到期后必须复核，不能靠默认续期长期悬置。
7 案例：数据出境路径未识别
假设订单 API 的数据库、备份和主要日志平台都在获批的境内位置，团队据此认为数据路径已经完整。后来排障发现，某次 SDK 升级开启了独立诊断功能。遇到异常时，它会把请求上下文发送到另个接收端，而团队没有核实这个接收端的实际区域和处理范围。上下文可能包含收件信息，因此出现了未识别的数据路径。此时还不能只凭域名就下结论，需要先查清事实。
问题根源不只是某条网络规则遗漏。评审把数据路径等同于主数据库位置，没有把日志、诊断、工单和远程支持作为独立处理活动；发布检查关注功能是否正常，没有检查依赖默认行为。即便正常请求从不携带收件信息，异常分支仍可能附带请求体。这说明数据流应覆盖成功与失败 2 类路径，字段检查也要覆盖异常输出。
发现后先按预案记录时间、发布版本、目标地址和发起组件，保留必要证据，并限制非必要诊断发送。不要在缺乏授权时随意扩大抓取或复制真实订单。随后由负责人协调核对 SDK 配置、代理转发、实际发送字段、接收区域、接收方以及留存安排。加密连接可能保护传输内容，但不会改变接收方处理数据的事实；“只用于排障”也不能代替对用途与依据的确认。
若确认存在受限数据的未经批准路径，或者关键事实仍不清楚，应由授权负责人结合适用制度评估处置、告知或报告等义务。教材不根据这个简化案例直接判断是否构成违法出境，因为数据类别、实际接收位置、主体关系和适用规则都影响结论。技术团队需要提供准确事实，避免用“云资源都在境内”掩盖辅助链路，也避免把未知信息写成已证实事实。
整改可以包括禁用不必要诊断、使用字段白名单、调整接收目的地和收紧出口。完成后重新触发相同异常，检查不应发送的字段确实消失，并确认必要排障能力仍然可用。最后更新数据台账、架构图、依赖升级检查和接入责任。事件复盘的价值是让下一次增加 SDK 或履约方时能够发现同类问题，而不是只删除当次错误配置。
8 把政务合规写进方案
方案正文应先说明适用范围与假设，再呈现选择依据。对于订单 API，可以写清业务责任单位、系统边界、数据类型、获批处理位置、外部接收方、运维方式与恢复目标。未确认的等级、密评适用范围或特殊数据要求，应列出确认责任和截止节点。涉及采购前置条件的事项必须先解决，不能在已经锁定技术选型后才补充决定性约束。
然后使用 ADR，即架构决策记录，保存重要选择。每份记录包含问题背景、硬约束、备选、决定、理由、代价与复审条件。例如教学案例暂选“核心订单服务位于获批专有环境，公开静态内容可置于经批准的公有云环境”，理由必须引用已确认的要求与团队运行能力。若约束尚未确认，这只能是条件性建议；不能将它包装成政务项目普遍适用的结论。
控制映射宜采用短表，列出要求编号、控制位置、流程责任、验收证据和剩余风险。订单查询越权由 API 校验并以拒绝访问结果验收；收件字段日志限制由字段过滤和发布检查共同实现；恢复目标由备份配置与实际恢复报告共同证明。不要把同句“满足相关要求”复制到每行，也不要以服务方已有报告替代应用自身需要提供的证据。
成本章节采用相同业务容量与相同合规边界比较备选，说明初次投入、年度运行和恢复预留。风险章节则保留不能立即消除的问题：专有环境扩容周期长、外部履约可能中断、某些恢复依赖尚未演练等。每项风险有影响、责任人、措施与复审日期。接受风险应由有权承担业务后果的角色确认，技术人员不能用“已知风险”几个字替他人接受后果。
高可用章节把目标变成验收场景，例如停止单个 API 实例、暂时中断履约连接、从备份恢复订单库。记录哪些故障可自动处理，哪些需要人工决定，恢复后如何核对订单和处理重复通知。整个验收包还应包含边界图、权限样例、脱敏日志、运行联系机制和例外清单，使评审者能沿着要求追到证据。这样合规安排才与架构、成本和运行形成同份方案。
9 从政企与政务云方案走向制造与工业互联网（P27）
本课建立的工作方法可以带到制造与工业互联网：先确认业务损失和责任主体，再识别数据与连接边界，比较部署选项，记录决策，并验证故障后的恢复。订单 API 仍然是业务主线，进入制造场景后，它可能向生产排程或仓储系统发送需求，再接收生产进度。订单中的收件信息通常没有必要进入设备控制环节，新的集成仍应遵循最小必要字段原则。
变化在于，制造场景可能出现现场设备、连续生产和更复杂的连接条件。某个接口断开后，业务既可能接受延迟同步，也可能影响现场安排；现场系统是否允许自动重试、能否在失联时独立工作，需要重新确认。不能把互联网订单接口的恢复目标原样套给设备相关系统，也不能把订单的成功响应直接等同于现场动作已经完成。
进入 P27 前，可以带走当前方案的要求清单、数据流、ADR、成本假设和恢复演练结果，并新增“与现场系统交换什么、由谁确认状态、失败时谁接管”这些问题。对于工业协议、实时控制与设备安全的深入机制，留到后续适用章节。本课的目标是让方案保持可追溯：当新业务接入时，知道应该修改哪些边界和责任，而不是不断往架构图上增加产品图标。
放进方案里
本方案覆盖零售订单 API 的创建、查询及履约通知，处理订单号、商品、金额、状态和必要收件信息。业务责任单位确认数据用途、适用要求和接收方，技术团队维护系统边界与控制映射。等保定级、密评适用范围及数据分类分级结论按适用程序确认，尚未确认的事项列入决策前置条件，并明确责任人和完成时间。
在核心数据须留于获批专有环境的前提下，建议将订单 API、订单库、日志与备份部署于该环境；公开静态内容可在批准后使用公有云能力。入口及辅助组件实际处理的字段同样纳入评审。履约通过受控接口发送必要字段，运维经受控入口按需授权，普通日志不记录完整手机号和地址，新增接收方、诊断服务或备份位置均触发复审。
架构决策记录对比全部专有、全部公有和组合部署的适用条件。年度成本包含资源、网络、备份、日志、密码相关能力、人力、评审整改及恢复预留，列明容量和价格假设。若专有环境扩容周期或外部依赖影响目标，记录业务影响、缓解措施、责任人和复审日期，由授权角色确认剩余风险。
教学目标暂定月度可用性 99.9%、RTO 为 2 小时、RPO 为 15 分钟，正式承诺以业务确认和演练结果为准。通过实例故障、履约中断和备份恢复验证可用性与数据完整性，并核对恢复后的订单及重复通知。验收材料包含边界图、权限拒绝结果、脱敏日志、密钥操作记录和恢复报告，关联环境、版本、时间与责任人。上线后将权限变动、依赖升级和例外到期复核纳入持续运行。
10 小结：下一步制造与工业互联网（P27）
政企与政务云方案需要把要求、数据、边界、控制、流程和证据连起来。等保、密评与数据分类各有作用；部署名称不能替代适用性判断，产品清单不能替代运行责任，备份成功不能替代恢复验证。
可以用 3 个问题自测：订单库位置获批，为什么仍需检查日志 SDK？接口数量减少，为什么不一定降低风险？恢复演练超过 RTO，为什么必须调整设计或业务承诺？回答时都应落到实际路径、责任和证据。
下一课进入制造与工业互联网，继续使用订单 API，把履约链路延伸到生产与现场系统，学习如何在新的业务约束下重新安排连接、隔离和恢复。