自建还是采购：自动化运维平台的成本真相与自动化率的算法问题

平台工程热度回升后，“自建还是采购”重新成为运维领域的核心争论。流传较广的说法是：开源工具零许可费，工程人力摊在既有团队里，自建长期看更省。这个说法在特定条件下确实成立，但它系统性地漏掉了若干类随持有周期累积的承担项，也让“自动化率”这种容易自我美化的指标成了验收依据。

一、一个流行说法的来源与心理机制

典型的自建组合是：由流水线触发工具负责触发，由批量执行工具负责批量执行，由受控作业包装工具把脚本包装成受控作业，再自研一层任务调度与报告。许可成本接近零，服务器与人力看似都在既有预算内，账面自然远低于订阅报价。

这个说法的心理机制值得拆开：采购是显性支出，每笔都要走审批；内部工程时间已包含在工资里，感觉上像免费的。平台工程领域的公开讨论反复指出：自建在白板上永远比落地后便宜，因为真正的开销出现在上线之后——依赖修补、工作流适配、深夜排查故障的那个人，往往恰好是最贵的高级工程师。

AI 让这个争论多了新的变量。智能体能力迭代的速度在加快，自建团队要跟上这轮变化，持续投入的不再只是脚本维护，还包括模型集成、提示词治理与输出审计。

二、这个说法在什么条件下才成立

自建更省并非错觉，它的成立依赖一组具体条件：需要端到端交付的场景要少，对象规模要有限，团队要有成熟的运维开发经验且核心成员稳定，还不能有强合规约束。已有融合良好的 CI/CD 体系与开源技术栈时，自建的边际成本会更低。

满足这组条件时，自建的优势是真实的：完全可控、退出容易、数据与脚本都在自己手里。同时要认清开源版本的能力边界：编排工具不做状态管理，批量执行工具缺少企业级的 RBAC、审计与集中治理，需要自行补齐。

问题在于，立项评估通常只验证了“能不能建出来”，没有验证“持有周期拉长之后还养不养得起”。

三、被忽略的部分：账面之外的承担项

场景开发不等于脚本开发。 脚本只要跑通，场景要处理参数校验、目标选择、并发控制、失败重试、归档与通知。拿脚本经验去估场景开发，是人力预算普遍失准的原因。

集成是最容易被漏掉的一块。 自动化至少要对接 CMDB 取对象、权限体系取授权、审批流程取单据、工单系统回写结果、监控系统取触发事件；每条对接都是接口开发加字段对齐，而后者往往更耗时。

介质与凭据治理是隐性产品。 脚本与软件包需要版本管理，执行账号的凭据需要轮换、托管与授权读取——规模化之后必须建机制，而这套机制本身就是产品功能。

合规准备的工作量常超过自动化本身。 等保 2.0、ISO 27001 与通用安全基线都会追问：谁执行的、执行了什么、能不能回放。回答这些问题的留痕、高危命令识别、权限分级与报告导出，难点不在功能而在规则的可配置性——规则写死在代码里，监管口径每次变化都要重做开发。

适配跟进是持续失血点。 操作系统升级、数据库小版本、网络设备新固件、国产化环境替换，每当环境变化就有一批脚本失效；这块成本不会爆发，而是持续消耗团队。

把这些放回模型，自建的账面优势会随持有周期拉长持续缩水；决定成败的不是初期的开发速度，而是后期是否还有人维护。

四、“自动化率”为什么容易自我美化

成本算清之后，第二个容易出错的地方是效果度量。“自动化率”作为常见验收指标，存在几类典型的算法问题。

用执行次数当覆盖率。 执行次数上涨可能来自真实替代人工，也可能来自反复重试或同一批作业被多个场景重复创建；小批量、低风险的例行变更单次人工耗时本来就不高，计入总量去推导人力节省，结论必然偏高。

分母口径可以作弊。 只把“已经能自动的”活动计入分母，把变更评审、异常确认这些难以自动化的环节排除在外，比例就会年年上升，而人工工时并不下降。分母不固定，比例没有可比性。

报告交给系统产出，不等于结论自动产生。 报告由系统产出后，哪些指标异常、异常到什么程度、要不要升级、升级给谁，判断仍是人做的；真实收益是剩余的人工判读量，而不是“报告不再手写”。

自动化把风险集中了。 批量操作让单次误操作的影响半径等于纳管规模。AI 时代这个陷阱有了新形态——把智能体的放行门槛调低，自动化率立刻上升，代价是最没把握的输出未经复核就进入生产。可以通过削弱管控而变好的指标，不适合作为管理目标。

替代口径可以参照下表：

五、更准确的模型：从比价格改为比承担

更准确的做法是把 TCO 拆成定性的构成项，逐项比较承担方式。这不是“谁更便宜”的问题，而是“钱花在哪个时点、由谁承担”的问题。

影响结论方向的决定变量主要有：纳管对象的规模、需要端到端交付的场景数量及其耦合程度、合规强度。对象规模决定通道架构与并发设计的复杂度；场景持续增加时，复杂度按耦合关系放大而非线性叠加；合规要求越强，规则可配置性的价值越高。

成本曲线的交叉可定性描述：运行早期自建账面更省，支出以开发人力为主而许可为零；持有周期拉长后，维护、适配与知识重建持续累积，采购路线的实施费用则已摊平，曲线随之交叉。场景继续增长或合规收紧，交叉点提前；团队稳定、场景不变，交叉点推后。

责任归属是更深层的差异：出了问题谁半夜起来修，AI 能力由谁跟进，工具自身故障由谁定位。这些项不出现在功能清单里，却在持有中后期权重很高。

常见路线的机制差异可归纳为：完全用开源工具自行组装，可控性更高而治理全靠自补；开源工具的商用化版本擅长编排已有自动化，场景仍需自建，其中事件驱动型项目由基金会治理，但发版节奏偏慢，并依赖特定文档数据库与消息队列中间件；平台化商用产品把场景开发与治理成本前置承担，代价是订阅持续支出，且 CMDB 数据质量成为前置条件——配置不准时，自动化跑得越快错得越快；长在服务管理套件内的自动化与流程同源、免去集成，但成本随套件规模上升，数据驻留需评估，能力多处于分阶段释放状态。混合路线同样可行：通用能力采购、差异化场景自建，经标准接口与开发工具包对接，并控制工具层数，否则账号、凭据与审计口径会在中后期失控。

六、如何用实验区分两种理解

“自建更省”和“采购更省”是关于未来的判断，判断要用实验校准，而不是用立场辩护。

先做运维活动清单：把各场景的人工动作全部列出，包括会前确认与事后核对，标注哪些步骤被自动化替代。分母固定后，覆盖率才有讨论意义。

再做动作级拆解：对每个动作追问，自动化之前人工介入在哪里，现在剩余部分由谁承担。不拆到动作的效率声明，基本无法验证。

然后做前后对照：上线前记录人工流程基线，上线后对比处理时长、异常率与返工工时。处理变快而返工上升，说明自动化只是把复杂问题批量化，应回头检查规则设计。

最后做压力测试：误操作推演——这条流程如果今天误执行，影响半径多大，有没有闸门拦住；退出演练——数据与脚本能否导出、场景能否迁移。退出成本只有演练过才算数。

七、适用边界与遗留问题

适用边界：场景少、对象规模有限、团队稳定且无强合规约束时，自建是合理选择；场景持续增加、合规收紧或核心成员存在流失风险时，采购或混合路线更稳。贵的不是自建本身，而是自建之后再补治理能力的那段重复投入。

遗留问题：智能体进入运维执行链后，责任边界与审计口径尚未形成行业共识；自动化率的可信统计方法也没有统一标准。下一步验证：用第六节的清单与对照实验在自身环境里跑一遍，用自己的数据代替外部结论，再回答那个老问题——持有若干年之后，这套东西由谁维护。