先说结论（也可能是我个人的偏见）
2021 年 3 月我从一家在线教育公司跳到跨境电商，岗位写的是运维开发工程师。面试的时候 leader 跟我说，这边运维基本靠人肉，你来了把这套东西搭起来。我当时还挺兴奋的，觉得这是从 0 到 1 的机会。入职第一周我就傻了——服务器 1280 台，散在 3 个可用区、2 家云厂商、还有一批托管在机房里的物理机。资产记录在飞书表格里，最后更新时间是 2020 年 9 月。变更记录全在群里，靠关键词搜「已上线」。
大促前夜，一个同事想知道某台机器上跑的是哪个版本的订单服务，花了 40 分钟才确认。第二天我们就立项自研 CMDB。那时候团队 3 个人，我主导，另外两个一个写 Python，一个写 Java。这篇文章不是劝你别自研，而是想把这三年我们交的学费摊开给你看，你自己判断值不值。
技术选型：前三个月很爽，第四个月开始还债
选型讨论了两周，最后定的是 Python + FastAPI + MySQL 8.0 + Redis，前端 Vue 3 + Element Plus。理由很朴素：团队没人写 Go，Java 那位嫌 Spring Boot 太重。现在回头看，这个决定不算错，但有个致命前提我们没想清楚——CMDB 的难点从来不是写 API，是把数据搞对。
表设计第一版就埋了雷。我们设计了一张 ci_instance 表，所有属性塞进 JSON 字段，图省事，加字段不用改表结构。前三个月确实爽。到 2021 年底，这张表涨到 4700 万行，JSON 字段平均 3.2KB，单表 190GB。查某台机器的某个属性走全表扫，后来加了 generated column 和联合索引也救不回来。拆成 11 张表走 EAV 模型之后好了一些，又引入 Neo4j 处理机器和服务的依赖关系，部署在 3 台 32C128G 的机器上，光维护这套图库又搭进去一个人力。
监控这块的故事更典型。2022 年 Prometheus 单机 series 涨到 200 万左右，query 延迟从平常的 200ms 飙到 4s，常驻内存 30G，遇到大范围查询高峰能干到 58G，有一次直接把节点 OOM 了。换成 VictoriaMetrics 之后，同样的数据量常驻内存落到 9G 上下——这个数是我自己盯了一个月 Grafana 确认的，不是抄官网的「7 倍」宣传。但这事儿其实有更省事的路子：先做 relabel 把没用的 series 干掉，我们当时一次就删掉了 37 万个用不上的指标。
算一笔账：4.5 人力年 vs 3 周部署
2023 年上半年我认真算了一笔账。这套 CMDB（包含前一个团队留下的部分）累计投入大概 4.5 个人力年，按当时的成本折算差不多 260 万人民币。而 NetBox——Django 写的那个开源 IPAM/DCIM 系统——我们花了 2 周部署、3 周写同步脚本，就覆盖了大概 85% 的需求。剩下 15% 用 webhook 加一个 800 行的 Go 服务补上，主要是对接我们内部的审批流。
我不是说自研一定错。我们的灰度环境要按「商家 ID 哈希」动态选机器分组，这个 NetBox 原生确实做不了，必须自己写。问题是，我们一开始是「为了自研而自研」——把写平台本身当成了 KPI，而不是把解决问题当 KPI。这个惯性在运维开发团队里特别常见，因为写代码的产出比推动流程变更更容易被看见，leader 也更容易拿去汇报。
我现在的观点：运维开发的产出不该用「消灭运维」衡量
干得越久我越觉得，这个岗位最大的陷阱就是拿「消灭运维」当目标。写平台、写工具、写自动化，看起来产出很高，但真正的判断标准应该是：故障发生的时候，你的系统能不能让人更快地定位和止损。这个标准很朴素，可是它会把很多「看起来很酷」的项目直接筛掉。
我们后来做的一件事能说明问题。告警规则原来有 1200 条，每天都是噪音，大家开始下意识忽略钉钉群。我们把它砍到 210 条，同时加了一个变更关联：每次发布自动打 tag，出问题先看最近 30 分钟的变更。误报率从 63% 降到 11%。这个收益比多写三个 Kubernetes Operator 大得多，而它其实没写多少代码。
运维开发真正该干的事，是把复杂度从人脑子里搬进代码，然后让代码可解释。至于平台是自研还是直接用开源，那只是手段。别本末倒置——这是我花了三年和两百多万才想明白的事。