SRE从来不是运维的新马甲

上周三凌晨两点，我在南京新街口的出租屋里被手机震醒。是前同事发来的消息。他们公司年中大促前的全链路压测把核心交易链路打挂了，运维团队熬了两个通宵把服务拉起来，转头周会上CTO拍着桌子问，你们到底什么时候能把SRE体系搭起来。

说这话的时候，他们团队已经连着三年把SRE挂在招聘网站的JD最前面，开的薪资比同岗研发高30%，招了快两年，连个合适的候选人都没约到。

把SRE当运维升级包的公司基本都交了学费

我接触过的一个做家居电商的团队，去年花了接近市场两倍的薪资挖了个有头部互联网大厂SRE经验的工程师进来，对方花了三个月时间搭了全套的可观测监控看板，写了覆盖上百个指标的告警规则，甚至把每个服务的部署拓扑都画成了彩色的架构图贴在了团队的公共文档里。

结果呢？

大促当天告警弹了三千多条。值班的工程师手机震到自动关机。最后还是因为个没纳入监控的缓存配置漏改，把支付接口干挂了俩小时。

为啥会搞成这样？太多人从一开始就对SRE有误解。觉得这就是运维团队的2.0版本，招个懂点自动化的运维，把可用性KPI往高了定，就算完成任务了。

他们根本忘了SRE最核心的底层共识——错误预算。说白了，就是你定了全年99.99%的服务可用性，算下来全年允许的故障总时长也就52分钟，这52分钟不是让运维攥在手里当护身符拦着所有新功能上线的，是给全团队留出来的试错额度。

之前有个做在线教育的团队，产品部要上线新的AI答疑功能，研发要把原来的单体应用拆成十几个微服务，运维拦着不让，说这么改肯定会影响稳定性，两边吵了三个月，连周会都没法好好开。最后有人提了个思路，把这个季度剩下的20分钟错误预算算出来，新功能灰度发布，每次出故障的时间都从预算里扣，扣超了就停一周的新功能迭代，集中补稳定性漏洞。

真的，吵破头都不如把账算明白。

值班本上的每一行字都是踩过的坑

我之前在南京雨花软件园的一家企业服务公司待过，他们团队有个传了四年的值班本，是个封皮磨得发白的硬皮笔记本。翻开来第一页就用黑笔写着：“凌晨三点不要随便改核心数据库的连接数”，旁边还有红笔补的批注：“2023年6月18日改完之后，所有订单接口超时，赔了12万”。

很多人觉得SRE的日常就是写脚本做自动化，把重复的运维操作都干掉，追求100%的零故障。真待过一线团队就知道，这种想法纯粹是脱离实际。

他们的SRE团队根本不背“零故障”的KPI，反而每次出故障，值班的人第一时间拉群先列影响范围，等服务恢复了开复盘会，根本不追是谁点错了按钮、谁漏了检查项，就问三个问题：这个故障为什么没被提前监控到？下次怎么能让刚入职的新人也不犯同样的错？要补多少自动化的兜底逻辑才能把故障影响压到最小。

你别说，就这种不追责的氛围，反而让故障出的越来越少。之前他们每个月都要出个三四次影响全量用户的故障，现在连续八个月，累计故障时间都没超过每个季度的错误预算。

别把SRE做成飘在半空的流程

我见过太多团队，学大厂的SRE经验学的走火入魔，把流程搞的复杂到离谱。每次上线要填三个审批单，要过五个检查点，要找两个负责人签字，最后研发团队为了赶版本，直接绕开流程半夜偷偷把代码推上去，出了问题谁都找不到人。

之前帮一个十几人的创业团队做流程梳理，他们之前定的SRE规则里，要求所有上线必须在工作日下午两点到四点之间，结果研发团队为了不耽误版本上线，经常趁值班的人下班，半夜偷偷推数据库变更，上次就是没做备份直接改了表结构，差点把半年的用户数据搞丢，折腾了一整夜才恢复。

真正落地的SRE，从来不是给研发团队添麻烦的。你完全可以把所有上线的检查点，做成一键触发的流水线，点一下按钮，自动跑数据备份、自动做流量校验、自动触发回滚预案，研发根本不用记那么多零散的规则，点一下就走完所有流程。

最好的SRE流程，是让团队感觉不到流程的存在。

很多人觉得小团队根本不需要做SRE，得等公司规模到几百人了再搭专门的SRE团队。其实根本不是，小团队反而更简单。你可以让每个研发工程师轮值一周，把自己写的服务的监控、告警、回滚预案都做扎实，比你招个完全不了解业务的SRE天天盯着通用的监控看板有用多了。

上周跟之前那个被CTO拍桌子的前同事吃饭，他们现在已经不天天盯着招聘网站找SRE专家了。每个季度拉上业务、研发、运维坐下来算一次错误预算，把值班的流程简化到一页A4纸，上次年中大促，全链路压测一次过，整个活动期间的故障时间总共才花了3分钟。

哪有什么神乎其神的SRE啊。说白了就是大家别互相甩锅，把能踩的坑提前记下来，把能自动化的活都交给机器，就够了。