DevOps落地别迷信工具和流水线
上周在南京河西的一栋写字楼里，跟一家做工业SaaS的技术负责人聊到晚上八点。他桌上摊着这两年DevOps建设的采购清单，小几百万的支出，从CI/CD平台到监控工具，全链路可观测的系统买了个遍。
他说现在对外报的数都很好看：部署频率从两周一次提到一天三次，故障平均恢复时间从4小时缩到22分钟，变更失败率压到了8%。
结果呢？
研发和运维还是天天在群里吵。
流水线跑通根本不算落地
很多人对DevOps的认知，到现在还停在“把代码提交到部署的流程自动化”这一步。代码一推，自动跑单元测试，自动打包镜像，自动推到镜像仓库，自动部署到测试环境，甚至生产环境，看着流水线的节点一个个变绿，就觉得DevOps成了。
CI/CD流水线只是把原来的手工步骤自动化了，要是流程本身是拧巴的，自动化越快，错的越远。
我见过一个团队，花了四个月搭完整套流水线，给每个节点设了严格的卡点：单元测试覆盖率不到80%不能往下走，安全扫描没出高危漏洞不能过，测试环境部署失败直接打回研发。听起来特别规范对吧？结果呢？研发为了凑覆盖率，把本来该跑的集成测试用例全注释了，单元测试写一堆没有实际断言的空方法，就为了把数字凑到80%。安全扫描那边，为了不卡流水线，研发直接把已知的依赖漏洞加到了白名单里，反正扫不出来就算过。
说白了，这套自动化流水线跑的越顺，团队里的投机取巧反而越方便。那个南京的公司也有这问题，他们的生产部署节点，在流水线里还是要走三层审批：运维总监、产品总监、CTO。有时候CTO在外面开行业会，手机没信号，审批流程卡那大半天，本来要赶在用户上班前发的版本，硬生生拖到上午十点，直接影响了业务侧的客户使用。
你说这是流水线的问题？
根本不是。是他们从一开始就没搞懂，流水线是帮人省时间的，不是把原来的线下审批流程原封不动搬到线上的。要是没人对业务结果负责，所有的权限都攥在领导手里，哪怕你把流水线的节点做的再丝滑，省下来的时间也全耗在等审批上。
跨团队的墙才是真卡点
我跟那个技术负责人聊到最后，他自己也承认，这两年搞DevOps，把90%的精力都花在买工具、调流水线速度上了，从来没碰过团队之间那堵看不见的墙。
之前他们的流程是什么样的？研发写完代码，过了单元测试就提给测试，测试测完打包给运维，运维负责把包部署到生产环境。整个流程是单向的交接收口，谁接了谁负责，前面的人把东西扔出去就算完事。出了线上故障，第一反应是研发写的代码有问题，还是运维部署的时候配错了环境？互相甩锅，扯半天。
DevOps的核心从来不是工具，是把原来研发和运维之间的“交接收口”变成“共同负责”。
后来他们试着做了个很小的调整：每个新需求从评审会开始，研发、测试、运维三个人必须全到场。运维不用等到临上线才对着研发写的部署文档抠细节，在评审阶段就把生产环境的配置要求、日志埋点的规范、监控指标的阈值直接提出来，研发写代码的时候就把这些东西揉进去，不用等到上线前临时补。
这个调整不是没有代价的。头两个月，运维觉得自己平白多了好多评审的活，本来就够忙的值班排期又挤进来一堆会；研发觉得运维事多，写个业务逻辑还要考虑一堆日志、指标的事，写代码的速度都慢了，整个团队的交付速度比之前还降了15%。但三个月之后再看数据，线上因为日志缺失、配置不对导致的故障直接少了一半。很多本来要等到上线才会踩的坑，在评审和开发阶段就被揪出来了。
很多公司不愿意走这一步。毕竟买工具走个采购流程，几周就能落地，还能写进年终汇报里。要改团队的协作流程，要打破原来的部门边界，要动每个人的工作习惯，甚至要调整绩效考核的规则——原来研发的考核只看需求交付速度，运维的考核只看线上稳定性，现在要让他们对同一个线上故障共同负责，这难度比买十套工具都大。
别拿指标当目标
现在行业里聊DevOps，张口就提四个关键指标：部署频率、变更前置时间、故障平均恢复时间、变更失败率。很多公司直接把这四个数字拆成KPI，压到每个团队头上，觉得数字上去了，DevOps的成熟度就高了。
那个南京的公司之前也这么干。为了把部署频率从一天三次提到一天五次，他们给每个研发小组定了考核要求：每周至少完成15次生产部署。结果呢？研发为了凑这个数字，把本来可以攒到一起发的几个小改动，拆成好多次独立部署。比如改个按钮颜色、调个文案，本来跟着下个版本一起发就行，现在为了凑部署次数，单独走一次完整的上线流程。
上线次数是上去了，但是运维的值班压力直接翻了倍。本来一天只需要盯两三次上线，现在一天要盯五六次，值班的工程师熬的眼睛都红，反而因为疲劳出了好几次配置错误。
指标是用来帮你定位问题的，不是用来当KPI考核的。比如你发现变更失败率高，你要顺着流程倒：是测试环节没覆盖到边缘场景？还是研发在写代码的时候根本没考虑生产环境的配置差异？还是流水线的卡点设置的不合理？找到根因再调整，而不是逼着研发把失败率压到某个数字以下，为了压数字把本来该走的测试环节砍了，最后出了大故障，谁都担不起。
说实话，我见过太多团队把DevOps做成了数字游戏。流水线的界面做的漂漂亮亮的，指标看板上的数字一个比一个好看，但是团队内部还是互相甩锅，出了问题还是要拉着十几个人的群排查到半夜。
上次聊到最后，那个技术负责人说，现在回头算，之前花的那几百万里，至少有一半的钱买的工具根本没怎么用。要是一开始就先把团队的协作流程理顺，把跨团队的责任边界捋清楚，根本不用花那么多钱，效果反而更好。
DevOps这事，从来不是给团队装个自动化马达。
是先把团队里拧着的那股劲顺过来。要是大家还在等着把手里的活扔给下一个环节的人，你把流水线搭到天上去，也没用。