上周在南京新街口的咖啡馆见了个老熟人。
他是城商行的技术部副总。
去年他们咬着牙批了三百万预算上全套DevOps工具链，从代码托管到自动化测试到部署流水线，前后对接了三家供应商，光POC就跑了四个月，就为了赶上大家都在说的数字化转型节奏。
结果呢？
现在发版还是要走线下审批。
三百万的预算，砸出去水花都没响两下。
工具买了，流程没动
他跟我吐槽的时候，咖啡杯上的拉花都塌了。咖啡凉透了。说开发那边写完代码推到仓库，自动跑单测是没问题，但是到了预发环境，运维还是要手动改服务器配置，还要等安全团队手动扫完漏洞，整个流水线到最后一步就卡成了静态网页。
麻烦在于，很多团队一开始碰DevOps，第一反应是先选工具。把市面上吹得神乎其神的流水线、监控、日志组件全买齐，以为把工具串起来就算完成了转型。
说白了，人要是不对，再好的工具也是摆设。
他的团队里，开发和运维是两个独立的考核线。开发的KPI是需求交付速度，恨不得当天接的需求当天就能上线；运维的KPI是线上稳定性，恨不得所有代码改完都在测试环境跑三个月再碰生产。两边从根上目标就拧着，你就算把全世界最好的流水线摆在他们面前，运维敢随便放开发的代码直接上线吗？
速度和稳定从来不是对立面
之前在苏州见的一个做工业软件的小团队，二十来个人，没买昂贵的商业流水线工具。就是自己搭了个开源的CI流程，每提交一次代码，自动跑单元测试，跑接口校验，过了就自动部署到测试环境，开发自己盯着测试环境的日志，出了问题马上回滚。
前两个月怨声载道。
之前写代码不用管测试覆盖，现在单测跑不过就不让合代码，大家要补写好多之前欠的测试用例，加班加了快俩月。
第三个月开始爽了。
之前每次发版要运维搭环境，要手动导基础数据，要挨个点按钮部署，前后要耗大半天，现在点一下按钮，十分钟就能把版本推到生产环境。出了问题自动告警，开发自己就能定位到是哪行代码的问题，不用再拉着运维开两个小时的排查会。
很多人觉得搞DevOps就是要牺牲稳定性换速度，完全是误解。你把流程捋顺了，把责任划清了，速度上去了，稳定性反而会更好。因为每一次变更都有记录，每一个问题都能快速定位，根本不需要靠运维在生产环境熬夜排查。
当然，这里有代价。
不是花点钱买工具就能解决的，是要真的打破部门墙，要让开发对自己写的代码负责，要让运维提前参与到需求评审里，不是等代码写完了才接盘。这个过程要得罪人，要改老规矩，要花时间磨，没有哪个供应商能帮你搞定这些。
DevOps没有适配所有团队的模板
别总盯着互联网大厂的案例抄。人家做To C业务，本来就要求快速迭代，搞trunk开发，搞一天发好几次版，那是人家的业务属性决定的。你一个做金融核心系统的，本来就有严格的合规要求，每一次发版都要留痕，要过审计，你非要追求跟大厂一样的发版频率，根本不符合监管的要求，最后肯定落不了地。
也别觉得团队小就不需要搞DevOps。
我见过一个五个人的创业团队，一开始连代码提交规范都没有，每个人写完代码就直接往生产服务器上扔，上次出了一次事故，误删了客户的生产数据，差点把公司赔没了。后来他们花了一周时间，搭了最简单的流程：代码必须走分支合并，合之前要过最基础的语法检查，部署用统一的脚本，就这么简单的几步，后面大半年都没出过线上事故。
DevOps从来不是什么高大上的概念。
说白了就是减少团队内部的沟通内耗，让写代码的人不用花那么多时间跟运维扯皮，让运维不用天天给人擦屁股。
上周跟那个城商行的副总分开的时候，他说现在终于想通了。之前的思路完全错了，不是先买工具，而是先把开发和运维的考核线拉齐，把之前那些没必要的线下审批砍掉，工具只是辅助，不是目的。
这事急不来。
真的。