上周跟一个做了六年运维的老哥在科技园门口抽烟，他说他们组上个月刚把流水线里的质量门禁全拆了。
为啥？之前的门禁卡了三次发版，把一个已经改了七版的618营销活动给卡黄了。老板拍桌子说要这玩意干嘛。
最先被搞歪的门禁逻辑
很多团队刚碰DevOps流水线的时候，总觉得质量门禁是个一劳永逸的兜底。把能跑的检查全堆上去——代码风格不对卡，覆盖率不够卡，甚至连提交信息少打了个Jira单号都卡。
说白了，这不是门禁，是给开发添堵。
之前接触过一个二十人不到的创业团队，跟风把代码覆盖率阈值设到85%。开发为了过门禁，写了一堆没意义的断言，把空函数的返回值都拿出来测一遍，凑数凑得飞快。核心支付链路的测试用例？没人写。反正覆盖率够了就行。
你说这种门禁有啥用？除了让开发每次提交都要多等十几分钟流水线跑，啥用没有。说实话，我刚工作那会也跟风搞过这种全量检查的门禁，后来被开发追着骂了半层楼才改过来。
更糟的是，卡得太严之后，大家会开始找漏洞。真的，别不信人性。有人写个脚本把测试用例批量跳过，有人直接在流水线参数里加个skip-gate的标记，还有人直接找运维后台手动点通过。你防得住吗？防不住。没人会服一个专门给人添堵的规则。
哪些规则真该放进来
我见过太多团队把“行业最佳实践”直接抄过来当门禁规则，根本不管自己的业务阶段和团队规模。
大厂能把覆盖率设到80%，那是人家有专门的测试团队，业务迭代节奏也没那么快。你一个刚拿到A轮的创业公司，每周要发三个版本，用户反馈迭代慢了就跑，你也硬卡80%？不是自己找事吗。
门禁的核心是筛掉会造成线上事故的问题，不是卡开发的正常交付。
什么东西必须卡？比如高危漏洞扫描出的RCE、未授权访问这类能直接被黑产利用的问题，没得商量。比如核心支付、用户登录链路的单元测试挂了，必须卡。这些东西放过去，就是要出大事的。
什么东西别放？比如代码风格检查，这种东西在IDE里加个提示就行，没必要卡流水线。比如非核心模块的测试覆盖率，你可以先统计，不卡，等大家慢慢养成写测试的习惯了，再给核心模块设个阈值，慢慢提。
麻烦在于，很多人搞反了。把不疼不痒的检查卡得死死的，真能出大事的漏洞扫描，反而因为经常出误报，被大家直接关了。
别让门禁变成没人认的橡皮章
还有一种更常见的情况，就是门禁规则写得漂漂亮亮，一到紧急发版的时候，谁都能跳过。
我之前见过一个团队，流水线里的门禁有十七条规则，写得比谁都全。结果上个月搞大促，连续五天的紧急bugfix，每次都直接点跳过门禁，跑了五次发版，五次都跳。那这十七条规则有啥意义？
门禁的权威，从来不是来自于流水线的自动拦截，是来自于团队所有人都认这个规则。
比如你定了高危漏洞必须卡，那就算是老板亲自提的需求，有高危漏洞也不能过。不然这个规则就是废纸，大家只会觉得这是个走形式的橡皮章。
对了，紧急发版的跳过规则必须提前定好，不能谁都能跳。比如只有P0级别的线上事故修复才能跳过，跳过之后要补全对应的测试用例和漏洞扫描，不然下次紧急发版，谁都能拿“我这是紧急修复”当借口。
还有，规则不是一成不变的。每个季度要复盘一次门禁的拦截记录，看看哪些规则拦下来的问题最后根本没造成影响，哪些规则经常出误报，直接删掉就行。别把门禁搞成个没人维护的垃圾桶，什么乱七八糟的检查都堆在里面。
上周又碰到那个拆了门禁的老哥。他们现在重新搭了门禁，就卡两个东西：核心链路用例通过率，高危漏洞数量。别的全放了。现在发版速度比之前快了三倍，上个月也没出过什么线上事故。
你看，这玩意从来不是越多越好。合适才行。毕竟，搞DevOps是为了让大家干活更顺，不是为了给大家添堵。