SRE从来不是运维的高端马甲
上周三凌晨两点四十七分，我手机连着震了七次。
是某品牌电商大促前的压测环境，订单接口超时率飙到37%。旁边开发哥们抱着电脑蹲在机房走廊，脸都绿了——说自己只改了个商品详情页的缓存过期时间，根本没碰核心交易链路。
最后扯了半小时才发现，是运维同事怕压测流量把测试服务器打挂，提前把限流阈值调低了三分之二，两边谁都不知道对方动过什么配置，就这么把压测环境的核心链路给堵死了。
别再把SRE当高配运维招了
现在刷招聘网站，一半以上写着招SRE的JD，本质上就是换了个名字的传统运维。要求负责服务器日常巡检、处理线上告警、配合开发完成版本发布，薪资比普通运维岗高出两成，就敢说自己在招SRE。
真不是抬杠。SRE的核心是用软件工程的方法解决运维问题，不是抱着现成的脚本天天登服务器敲命令改配置。最早Google提出这个岗位的时候，就明确划了线——SRE团队里的工程师，写业务代码、写自动化工具的时间，不能少于一半，剩下的精力才用来处理线上的突发问题。
之前在杭州接触过一支正经做SRE的团队，人家根本不天天盯着告警面板熬大夜。花了三个月写了套自动巡检的工具，把所有线上服务的端口连通性、证书有效期、磁盘使用率的检查全自动化，原来三个人要花一整天干完的巡检活，工具跑起来每天自动出报告，真有异常才会推到对应的负责人那里。
[SRE线上故障复盘会议白板照片]最离谱的招聘要求我见过，让SRE既能扛着服务器搬机房，又能写复杂的后端性能优化代码，还要在故障出现的时候第一时间站出来背锅，月薪开八千。
谁去啊。
故障从来不是靠人盯出来的
很多团队做运维的逻辑特别简单，招几个人轮班盯着告警面板，出问题了就爬起来处理。但他们从来不想想，为什么告警系统会天天响个不停？
之前碰到一个创业团队，告警规则写得跟闹着玩似的。什么“服务器CPU使用率超过30%”“磁盘剩余空间还有40%”“某个服务的进程数比昨天多了两个”，全是没用的噪音。早上八点打开告警列表，能堆两百多条，真到核心支付链路出问题的时候，告警早就被淹在里面，半小时都没人看见。
后来团队里来了个做过SRE的工程师，花了两周把所有告警规则全重写了一遍。把所有不影响用户实际体验的告警全砍了，只留和核心链路挂钩的——比如接口超时率超过5%、核心服务连续三次心跳失败、支付链路成功率低于99.9%，剩下的低优先级事件，全做成每周汇总的报表，不发即时告警。就这一个改动，整个团队的即时告警量直接降了90%，大家再也不用盯着手机心惊胆战，真出问题的时候，所有人的注意力能第一时间被拉到核心故障上。
[SRE告警规则优化前后数据对比看板]很多人对SRE还有个误区，觉得这个岗位的终极目标是实现零故障。扯呢。世界上根本没有零故障的系统。Google自己的SRE团队，都给故障留了固定的预算——就是允许系统一年里有固定比例的不可用时间，要是故障时间没超预算，就不用揪着细枝末节瞎优化，把精力放在更有价值的业务迭代上；要是超了，就得停下来复盘，把容易出问题的冗余链路给补上。
你想啊，为了把系统可用性从99.99%提到99.999%，可能要多花十倍的研发成本，最后用户根本感知不到这点差别，纯纯浪费资源。
落地SRE根本不用搭大团队
很多中小公司的负责人一听到SRE，就觉得这是大厂才能玩得起的概念，自己几十人的小团队，根本没必要搞。
错了。
根本不需要专门招三五个SRE工程师搭独立团队，把原来的运维同事拉上，抽两个懂点基础开发的后端，每周抽两个小时坐下来聊就行。
第一步，先把过去半年的线上故障记录全翻出来，列出来哪些是重复出现的——比如每次发布都要手动改配置文件，经常有人改错；比如每次扩容都要手动登服务器装环境，半小时才能搞完一台；比如每次证书快过期了，要靠人记着时间去更新，忘了就导致全站访问报错。
把这些重复的、浪费时间的事，一个个写成自动化脚本。不用追求什么高大上的统一管控平台，哪怕是个简单的Python脚本，能把手动操作的事自动跑完，就是SRE最核心的价值。
之前给一个做本地生活的小团队做咨询，他们原来每次发版，运维要登三台服务器，依次停服务、拉代码、打包、启动，整个流程要四十分钟，每次发版都要提心吊胆怕操作错。后来他们写了个简单的发布脚本，把整个流程串起来，点一下按钮就自动跑完，发版时间从四十分钟缩到三分钟，因为发版操作失误导致的故障直接降没了。
这就是SRE啊。
根本不是什么玄乎的概念。
上周碰到那个之前跟我吐槽招不到SRE的HR，还问我是不是现在懂SRE的人都被大厂抢光了。
我跟她说，你要是把JD里“负责日常服务器维护”的描述，改成“负责把团队从重复的手动操作里解放出来，把故障掐在用户感知之前”，再把薪资调到能招到会写基础代码的水平，自然有人愿意来。
她翻了个白眼，说那人力成本太高了，划不来。
我没接话。
毕竟，谁愿意天天凌晨爬起来，给别人的操作失误擦屁股啊。