上个月跟在南京做电商的老周吃夜宵，他扒拉着烤串突然骂了一句，说上周大促前压测，他们组那个刚转的SRE，盯着监控面板半小时没说话，最后说”你们这个系统的告警阈值设得跟闹着玩一样”。
就离谱。
别把SRE当高级运维用
很多公司招SRE的逻辑特别简单，把原来的资深运维拉过来，涨点工资，换个title就算完事。觉得SRE嘛，不就是能扛故障、能写脚本、比普通运维懂点开发的人？
老周他们去年真踩过这个坑。一开始团队缺SRE，把原来运维组的组长升了title，大促前信心满满，结果618当天峰值刚上来，支付接口直接超时，那位”SRE”翻来覆去查了俩小时，最后发现是开发上线的时候把数据库连接池的最大数设成了10，全堵在那了。
后来他们花了三个月招到真正的SRE，人家到岗第一周就把之前的认知全推翻了。SRE的核心工作是用工程化的方法解决运维的重复性问题，不是每次出了故障就蹲在服务器前面手动重启、翻日志、接各个团队的需求。说白了，就是把那些之前需要人反复做、容易出错的事，用代码和自动化工具固定下来，让系统自己就能把大部分风险扛过去。
很多人说SRE是运维和开发的中间地带，其实根本不是。它的出发点从来不是”我要帮谁干活”，是”我要怎么让整个系统的稳定性，不依赖某几个老员工的经验和熬夜”。
告警不是越多越负责
那个新来的SRE刚到岗的第二件事，直接把组里攒了3年的告警规则删了80%。当时老组里的运维都炸了，说你这是要把眼睛蒙起来？出了问题谁负责？
他没争，拉了个两周的告警历史报表，当着所有人的面数：平均每天能弹出1200多条告警，其中90%都是”某台服务器CPU使用率超过30%””磁盘剩余空间10%”这种根本不影响业务的破事，真正能触发核心故障的P0级告警，被淹在里面，根本没人能第一时间看见。
改完规则那天，全组的告警量直接降到每天不到50条，其中只有5条是需要人立刻响应的，剩下的都是可以慢慢排期处理的优化项。
爽了。
之前大家的状态是什么？每天盯着满屏的红弹窗，看到提示就条件反射点个确认，点到后面整个人都麻木了。去年那次支付超时的故障，一开始弹的告警就是混在一堆噪声里，值班的人以为又是哪个无关紧要的指标波动，拖了20分钟才响应，前后亏了近百万的GMV。
好的SRE从来不会追求告警的覆盖率，而是追求告警的有效率。不是说告警越少越好，是要把那些真的需要人介入的事件，从信息噪声里捞出来，别让团队天天在无效的弹窗里耗精力。毕竟人不是机器，盯着满屏的垃圾信息久了，真遇到事的时候，反应速度只会越来越慢。
故障复盘从来不是为了找人背锅
老周之前最烦开故障复盘会。每次会上都是扯来扯去，开发说运维没盯紧指标，运维说开发写的代码没做容错，扯到最后写个”加强值班纪律，提升上线校验标准”的空泛结论，下次该崩还是崩。
那个SRE来了之后，直接给复盘会定了死规则：全程不许提”谁的责任”，所有的分析都要落到系统的机制漏洞上。
说实话，这套规则刚推的时候，大家都不习惯。
有一次大促前，库存系统突然抖了两秒，本来按照之前的习惯，肯定要把负责库存模块的开发叫过来批一顿。结果按照新规则，大家顺着链路往回查，发现是之前的自动扩容策略设得太保守，流量上来的时候，扩容速度比用户下单的速度慢了30秒。就这30秒的延迟，差点又演变成一次线上大故障。后来他们把扩容策略的阈值调了，加了基于流量预测的提前扩容机制，去年双11的时候，实际流量比预估的高了40%，系统也没出任何乱子。
稳得一批。
很多人对SRE的误解，觉得这帮人是来给开发提约束、卡上线流程的”警察”。其实根本不是。他们的所有工作，都是为了把那些会反复出现的坑，提前用自动化的方式填上，而不是每次摔了跤，就互相指着对方的鼻子骂。
上周再跟老周吃夜宵，他说现在组里的SRE每天的日常，就是写脚本、调策略、把之前需要人手动做的事全自动化，值班的时候再也不用把手机攥在手里，怕半夜突然响起来要爬起来处理故障。
他现在睡觉都敢把手机放客厅了。
这才是SRE该有的样子。