自建的真实成本
自建平台的初期投入只是冰山一角：后续要持续投入功能维护、版本升级、权限体系、审计合规与高可用改造，还要有人负责它的可用性。它的价值在于能把内部特有的流程（审批链、资产编码、双人复核）直接做成产品能力。若内部流程与通用工具差异不大，自建往往只是把工具已有能力重新实现一遍，收益有限而成本持续存在。
基本信息
| 自建必要前提 | 内部流程差异显著、规模足够大、有长期维护人力 |
|---|---|
| 工具组合方式 | 配置管理加流水线加调度，辅以少量胶水代码 |
| 主要成本 | 开发、升级、安全、可用性与人员流动 |
| 判断标准 | 差异是否构成不可替代的业务要求 |
决策要点
- 差异评估：内部流程与通用工具的标准模型差距有多大。
- 人力评估：未来三年能否稳定保留维护团队，而不只是上线时有人。
- 上限评估：自建方案在节点规模翻十倍时是否还成立。
- 集成成本：与现有工单、审批、监控系统的对接难度。
- 退出成本：数据与资产能否导出，是否会被自建系统锁死。
- 演进节奏：能否先从工具组合起步，确有痛点再自建局部组件。
两种路线对比
| 对比项 | 自建平台 | 工具组合 |
|---|---|---|
| 上线速度 | 慢，需要开发周期 | 快，可局部试点 |
| 贴合度 | 高，可定制流程 | 中，需迁就工具模型 |
| 维护成本 | 长期投入，随规模增长 | 由社区或厂商分担 |
| 升级与安全 | 自行负责 | 跟随上游修复 |
| 风险 | 人员流动后维护困难 | 工具限制难以突破 |
| 适合场景 | 流程差异大且规模大 | 多数中小规模场景 |
折中路线通常最划算：主体用成熟工具，只对确实无法适配的环节开发小范围组件，并把这些组件当成需要长期维护的产品对待，而不是一次性脚本。
无论自建还是组合，都要保留资产的可迁移性：自动化资产用通用格式编写，凭据与清单位于可导出的中间层，避免未来更换平台时全部重写。