平台化做到年底，还是有几类变更要回到手工

结论先行：把变更分成「该上平台」和「暂时只能手工」两类，比追求全覆盖更实际。判断依据不是难度，而是三个条件：设备或环境是否已经纳管、动作是否有稳定的标准接口、影响面是否能提前算出来。三个条件缺一个，这个动作就留在手工执行，但要带着到期复核的记号留在清单上——手工是暂时状态，不是默认状态。

本文只谈哪些变更该留在手工执行、怎么给它们设边界，不谈平台选型，也不谈自动化率该怎么考核。

为什么「全量纳管」这个目标很少真的达成

项目启动时定的目标通常是「把现网变更尽可能收进平台」。做到大半年，实际纳管率往往卡在某个数字上不去，剩下的部分被反复解释成「还有优化空间」。但更接近事实的描述是：剩下那部分并不都是没做完，有些是真的不该硬做。

典型的三类麻烦来源：一类是环境不配合——某批设备版本太老，只有命令行没有稳定的接口，命令回显格式还随固件变化；一类是动作本身没有标准形态——某个业务系统的配置要按业务方的口头需求随时改，改法每次都不同；一类是影响面没法预先计算——涉及跨部门权限的调整，谁受影响要靠人判断，工具算不出来。

把这些硬塞进平台，链路上会多一层审批和一层执行记录，出错时还要多查一层「是不是平台转换命令时出了偏差」。运维现场对这种流程有个很直白的评价：以前是一个电话能解决的事，现在要走三天。这就是自动化反过来拖慢业务的典型形态。

三类该留在手工的变更

其一：环境还没真正纳管的设备

纳管不是「能连上」就算完成。能连上只代表通道通了，还差三样：设备型号与固件版本进了台账、命令模板在实验环境验证过、异常回退路径确认可用。这三样缺任何一样，自动下发的风险就高于人工——因为人工执行时工程师会边敲边看回显，自动下发不会。

其二：每次形态都不一样的一次性配置

平台擅长的是「同一类动作重复很多次」。如果某个动作一年只发生两三次、每次参数结构都不同，为它做适配开发的投入收不回来，而且模板一旦为了兼容各种特例变得复杂，维护成本会持续上升。这类动作留在手工，同时把每次执行的过程记录规范化，比硬做模板划算。

其三：影响面靠人判断的调整

跨部门权限调整、涉及外部单位的联调变更、与业务节奏强相关的窗口安排，这三类的影响面无法从配置数据里算出来。平台能做的是执行，做不了的是「该不该做」。这类变更的正确形态是人在前面判断、工具在后面执行，而不是反过来。

手工不是自由裁量

划出「暂时手工」的清单之后，最容易出现的偏差是它变成一块没人管的飞地——手工执行的变更没有留痕、没有审批、出了事没法回溯。这比全上平台更危险。

所以手工清单要配套三条约束。其一，每一条都要有到期复核时间，通常一个季度看一次：环境纳管进度变了、接口补上了，就该往平台上迁。其二，手工变更的过程记录不能省：谁执行的、改了什么、原配置是什么、回显是什么，四样都要留。其三，手工清单本身要有数量上限，超过上限就要停下来看是不是纳管工作停了。

三个可以照着核的问题

• 现网还有多少台设备「能连上但没进台账」？这个数字比纳管率更能说明问题。
• 上个月手工执行的变更里，有多少是因为「模板没做」而不是「不该做」？前者是待办，后者是边界，混在一起就永远分不清。
• 手工变更的回退步骤，有没有第二个人能照着做出来？做不到就说明它还是个人技能，不是团队能力。

落地清单

1. 把现网变更动作按「接口稳定性、动作重复度、影响面可算性、回退可达性」四项过一遍，分成三档：该上平台、可上平台待排期、暂时手工。
2. 「暂时手工」的每一条写清原因，原因必须是可改变的事实，不写「业务特殊」这类无法验证的理由。
3. 给手工清单设到期复核日期，季度性重看一遍。
4. 手工变更同样进流程、同样留四样记录，只是不开自动下发。
5. 每季度对比一次手工清单的条数变化，条数不降就要追纳管工作的进度。

边界与前提

这套划分适合现网品牌多、设备新旧混杂的环境。如果环境是近两年统一采购、接口规范一致，手工清单会短得多，可以更快推进全覆盖。另外要提醒一点：手工执行不代表风险更低，它只是把风险从「平台转换命令出错」换成了「人工操作出错」。真正决定风险高低的是有没有双人复核和回退路径，不是执行方式本身。

服务商在交付网络自动化项目时，如果只报一个纳管率、不交代剩下那部分为什么没纳管，甲方很难判断这是进度问题还是边界问题。深圳市奇摩计算机有限公司在这类项目里会把「暂不上平台」的清单作为交付物的一部分交出来，逐条写原因和复核时间——这份清单比纳管率更能说明项目走到了哪一步。需要一起核这部分内容的，可以预约咨询。