上周在南京软件谷蹲了三天，见了六个做研发效能的团队负责人，聊到最后大家吐的槽居然都一样——花了大价钱买了全套流水线工具，搭了CI/CD的架子，结果上线频率还不如两年前手动发版的时候。最搞笑的是，有个团队的负责人跟我抱怨，说他们买的DevOps平台，光培训就做了三次，每次培训完大家还是该怎么手动发版就怎么手动发，因为平台上的流程太绕了，比手动发版还麻烦。
先搞清楚你要解决的到底是什么问题
很多团队上来就对标别人家的DevOps成熟度模型，数自己缺几个组件——缺自动化测试就补测试平台，缺制品库就搭Nexus，缺监控就接Prometheus，折腾了小半年，所有工具都齐了，跨部门的扯皮一点没少。
说白了，DevOps从根上是要拆墙的，不是给墙刷漆的。之前见过一个团队，研发和运维的KPI是拧着的：研发要快，每个迭代多塞三个需求；运维要稳，上线次数超过两次就要扣绩效。这种情况下你就算把流水线搭得能自动跑到月球，两边该打架还是打架。
麻烦就出在，大家总觉得DevOps是技术问题，是工具问题，其实第一关根本是组织目标对齐的问题。你想啊，研发的人想着早点把功能推出去拿迭代评分，运维的人想着半夜别被告警叫起来，两边的目标从根上就没拧成一股绳，再好的工具也只是给两边各发了一把更快的吵架武器。
别迷信一步到位的成熟度
我见过太多团队一上来就奔着”四级DevOps成熟度”冲，恨不得把所有能自动化的环节全自动化，连产品经理写需求的评审环节都想整个AI自动校验。代价是什么？小团队五个人，光维护那套复杂流水线就占了两个研发的一半工作量，每次改个小功能，要等二十分钟流水线跑测试，还要等三个不同平台的审批，最后大家宁愿绕开流程，直接手动把代码传到生产服务器上。
这事没那么玄。DevOps的本质是减少从代码提交到用户能用上的这段距离里的无效等待，不是为了把流程做复杂给老板看的。
之前有个做电商的小团队，最开始连个正经的版本控制都没有，大家共享一个FTP文件夹传代码，每次发版要拉个微信群喊所有人别碰服务器。他们没上来就买几十万的效能平台，先是把代码挪到Git上，搭了个最简易的CI：提交代码就自动跑单元测试，过了就自动打包丢到测试环境，就这一步，发版的等待时间从原来的俩小时缩到了五分钟。就这一步，比那些花了几百万搭全套平台的团队拿到的实际收益还多。
真正的落地从来都是反常识的
很多人觉得DevOps落地就是要把所有环节都串起来，要做到全流程自动化，要做到零人工干预。真不是。你在金融行业试试，核心交易系统的上线审批，你敢全自动跑？出了问题谁担责？这里的取舍从来都不是”全自动化最好”，而是找到那个自动化和人工兜底的平衡点。比如非核心的用户端功能，你可以做到提交代码就自动上线，出问题了一秒回滚，根本不需要层层审批；但涉及资金清算的核心模块，哪怕流程多一步人工审核，也是值得的。
还有个很容易被忽略的点：很多团队做DevOps，只盯着研发和运维两个部门，把测试、产品甚至安全团队全排除在流程外面。结果就是，等研发把功能写得差不多了，测试才接到版本包，测完发现有问题打回来改，改完再走运维的上线流程，一圈下来半个月过去了。真正顺的流程是什么样的？需求刚进迭代的时候，测试就开始写用例，安全团队同步做合规校验，甚至连上线之后的监控告警规则，都跟着代码提交一起进流水线。
说实话，这种事说起来简单，做起来难在哪？难在你要打破原来”各管一段”的惯性——原来测试的人就等着拿版本测，你让他提前写用例，他会说”需求都没定我写什么”；原来安全的人就等着上线前做扫描，你让他提前介入，他会说”我哪有时间跟着你每个需求跑”。
上个月碰到个在制造业做内部系统的技术负责人，他说他们花了两年时间慢慢磨DevOps，从来没搞过什么运动式的推广，就是每次团队碰到具体的堵点，就针对性改一点：上次发版要手动导数据，就写个脚本把这步自动化；上次测试环境老是被人改乱，就搞了个一键重置的脚本；上次上线完要手动写周报统计变更，就把变更记录自动同步到文档里。两年下来，他们根本没买什么昂贵的商业效能平台，全是开源工具拼的，每个迭代的上线次数从原来的每个月两次，变成了每个星期两次，半夜的告警量降了七成。
这事真的没那么玄。你要是问他DevOps是什么，他肯定不会给你背那堆标准定义，他就会告诉你，就是把原来大家重复做的、浪费时间的事，能省就省点，别把精力全花在无意义的流程上。