6.1 部署模型选型
6.1 部署模型选型
进入运维主线的第一件事：决定这套系统的运维责任放在谁手里。承上：第 2 章的三件套（边缘、控制器、编排器）由谁来运行，就是本节要回答的问题。启下：选型结论直接决定 6.2 节开通流程由谁执行、6.3 节平台由谁值守。读完本节，你应当能用四个变量给自己的组织定位，并看清每种模式的退出成本。
选型先选责任边界
部署模式的本质不是技术差异，而是责任矩阵的差异：设备谁买、控制器谁管、策略谁写、故障谁修、升级谁做。同样一套 SD-WAN 软件，三种交付形态给出三张责任表。
三种模式的责任矩阵
| 责任项 | 自建自维（DIY） | 运营商托管 | 云托管（SaaS 化） |
|---|---|---|---|
| 边缘设备 | 企业自购 | 运营商提供 | 厂商寄送或复用 |
| 控制器/编排器 | 企业自建自管 | 运营商机房 | 厂商多租户云 |
| 策略编写 | 企业网络团队 | 运营商代维 | 企业自写（平台托管） |
| 链路采购 | 企业直采 | 运营商打包 | 企业直采 |
| 故障定界 | 企业自己 | 运营商一线受理 | 平台工单+企业自助 |
| 软件升级 | 企业规划执行 | 运营商窗口 | 厂商统一灰度 |
| 费用结构 | CapEx 为主 | OpEx 打包 | OpEx 订阅 |
三种模式没有绝对优劣，匹配的变量有四个。分支规模：站点多（数百以上）且有网络团队，自建的规模效应才成立；十个八个站点，托管的起步速度碾压一切。IT 人力：自建需要至少能值夜班看平台的团队，算人力账时别只算工程师工资，算上技能培训与离职风险。合规与数据边界：强监管行业可能要求控制器本地化，云端多租户形态直接出局，或在私有化部署与托管之间折中。现有链路合约：已有多年期 MPLS 合约的组织，托管打包换链路的迁移摩擦更大。
图：三种部署模式的责任边界与适用形态
混合模式：最常见的落点
实践里多数中大型组织最终落在混合：总部与核心站点自建（策略与数据的控制权留在内部，合规好交代），边缘分支与临时点位托管（开通速度与省心度优先）。混合的关键工程问题是策略一致性：两套控制面如何共享同一份应用组定义与分段规则——这要求厂商方案支持跨控制面的策略联邦，或者干脆同一控制面多租户分区。审混合方案时把这个问题问透，能筛掉一批"混合只在 PPT 上成立"的产品。
一页纸的选型报告模板
选型结论要能说服人，就得压缩成一页纸。模板五段，每段几行字：段一，结论先行——推荐模式与理由一句话（例：推荐混合模式，核心自建保合规、边缘托管保速度）。段二，四个变量的现状——站点数与三年规划、可投入人力、合规红线、存量合约到期表，各一行。段三，备选方案的放弃理由——为什么不纯自建、为什么不纯托管，各一行；写放弃理由比写推荐理由更能体现评估的完整性。段四，成本与风险——三年总账的量级结论加前两大风险（通常是人能与绑定）。段五，下一步——PoC 范围、时间、验收口径。写不出这五段的选型，说明评估还没做完；反过来，这页纸本身就是给管理层决策的最佳载体。
问题：混合模式下两套系统的人才怎么办？
混合的隐性成本是团队要同时理解"自建平台的运维"与"托管服务的用法"两套东西。对冲办法是在项目初期就做角色切分：平台策略与验收标准由同一组人统一制定（保证口径一致），两套系统的日常操作分给不同成员（保证各自熟练）。每季度组织一次交叉演练——管托管的人做一次自建平台的模拟排障，反之亦然——避免任何一侧成为单点知识。人才问题的本质是知识冗余度问题，混合模式放大了它，就要主动管理它。
退出成本：签约前就要算
选型讨论通常聚焦进入成本，退出成本被系统性忽略。三个必须写进合同的退出条款：数据与配置导出（全量策略、遥测历史、拓扑，格式可读）；边缘设备解绑（设备能重新注册到新平台，还是变砖）；遗留链路处置（打包合约里的宽带与电路归属谁）。SD-WAN 的软件本质让迁移比传统网络容易，但控制器的策略数据库是事实上的锁定点——能把策略以标准格式导出的厂商，才谈得上不锁定。
三种模式的成本结构对照
责任矩阵之外，把费用结构也摆到一起看（以 50 站点、三年期为口径的相对量级）：
| 费用项 | 自建自维 | 运营商托管 | 云托管 |
|---|---|---|---|
| 初始投入 | 高（设备+控制器+实施） | 低（初装费） | 最低（设备押金或寄送） |
| 年度订阅 | 低（软件维保） | 中高（打包月租） | 中（按站点订阅） |
| 人力投入 | 高（专职团队） | 低（代维） | 中（企业自管策略） |
| 三年总账特征 | 前重后轻，规模越大越划算 | 平稳，议价空间看采购量 | 前轻后中，随站点线性增长 |
从总账形态能读出各模式的经济学本质：自建是"固定资产逻辑"——前期砸钱买控制权，站点越多摊薄越狠；托管是"外包逻辑"——用溢价买省心，适合人力稀缺；云托管是"订阅逻辑"——与业务规模同步伸缩，适合增长期组织。财务背景的决策者对这三种形态的偏好差异很大（重资产还是重费用化），谈判时把总账形态摆出来，比逐项砍价更有效。
问题：选了托管，企业网络团队会失业吗？
不会失业，但会转型，这一点最好在项目立项时就说清楚。托管转移的是"操作性工作"（值守、例行变更、一线排障），留下并强化的工作是"策略性工作"（应用分级、SLA 定义、架构规划、供应商管理）。转型失败的组织通常是把托管当成了"外包了就不管"，几年后发现自己既没有运营经验也没有议价能力，被供应商拿捏。健康的状态是：日常运维交出去，关键策略与验收标准握在手里，每年做一次服务评审。简单说——托管买的是人手，不该买走的是判断力。
本节要点
- 部署模式的差异是责任矩阵：设备、控制器、策略、故障、升级五项归谁，签约前逐项落纸。
- 四个选型变量：分支规模、IT 人力、合规边界、存量合约；按三年上限选，不看当下。
- 混合模式是多数中大型组织的落点：核心自建、边缘托管；关键考点是跨控制面的策略一致性。
- 退出成本三条款：数据导出格式、设备解绑流程、链路归属，合同里写清才叫选型完成。
模式定了，下一节看最快兑现的收益：一台设备从拆箱到业务上线，自动化流程里每一步发生了什么。