上周三凌晨两点十七分，我盯着告警面板上跳红的订单接口，手都在抖。不是怕出故障。是怕旁边产品经理甩过来的那句”你们不是管稳定性的吗？怎么又炸了”。
被误解最多的岗位定位
刚入行的时候，我也以为SRE就是运维的进阶版，无非是比原来的运维多会写两行Python，能搭几个自动化脚本，工资高个一两千。直到待了三家公司才发现，一半以上招SRE的团队，本质上是想找个”免费的运维开发+7*24小时背锅侠”。要求你能扛着服务器跑机房，能写代码改业务逻辑，能做容量规划，最后出了问题，不管是开发写的代码有内存泄漏，还是产品临时上线的活动把带宽打满，第一锅永远扣在SRE头上。
说真的，谁愿意大半夜爬起来处理故障？我见过最离谱的团队，SRE的KPI里一半是”故障响应时长”，另一半是”故障归因率”，意思是不管什么原因出的问题，你得在十分钟内把责任分给对应的开发组，不然就算你值班失职。这种环境下，谁还有心思去做长期的稳定性建设？
真正的SRE核心，从来不是当救火队员，是从根上把火灭了。之前我们团队刚接核心交易链路的时候，每个月要处理上百次磁盘满告警，全是业务日志没做轮转占的空间。原来的运维团队每次告警了就手动登服务器删日志，熬了整整一年。我们接过来之后花了两周写了自动日志轮转的规则，加了容量提前30天预警的阈值，之后整整八个月，这类告警一次都没出现过。算下来省的人力成本，够给整个团队发两次季度奖。
那些没人明说的落地细节
很多人一提SRE，张嘴就是SLO、错误预算、混沌工程，好像不把这些名词挂在嘴边，就不算正经做SRE。我见过太多团队上来就给所有业务定99.99%的可用性指标，完全不考虑业务的实际价值。比如公司内部的OA报销系统，全公司也就两千号人，一个月也就处理几百笔报销，你定99.99%的可用性，意味着一整年只能累计停机52分钟，为了这个指标搭三副本的高可用集群，算下来一年的硬件、带宽成本比一整年的报销总金额还高。这不是纯纯的浪费吗？
说实话，指标从来不是越高越好。SLO的本质是找稳定性和研发效率的平衡点，不是为了追求极致的可用性无限制烧钱。我们现在给业务定指标的时候，一定会拉着业务负责人算明白：如果这个接口出问题，每分钟会造成多少实际损失，再倒推对应的可用性目标。比如面向C端的支付接口，我们定99.99%的可用性，因为一秒钟的故障可能就是几十万的流水损失；但是内部的文档协作系统，我们只定99.9%的可用性，哪怕每个月停43分钟，对业务的影响也微乎其微，省下来的资源完全可以投到更核心的业务上。
还有值班的坑，我真的见过太多。很多团队学谷歌搞7*24小时oncall，但是根本没有配套的备班、换休机制。之前我们组的小伙子连续值了两个大夜，白天还要改监控脚本，结果盯告警的时候打了个盹，漏了十分钟的缓存命中率下跌，最后复盘的时候领导拍桌子说他责任心不够，他当场就提了离职。谁不是血肉之躯？连轴转三十个小时，就算是铁人也扛不住啊。
别把谷歌的手册当万能圣经
我见过太多小团队的技术负责人，把谷歌公开的SRE手册翻得页都皱了，回来就要求团队照搬全套流程。什么全链路压测、混沌工程、多活容灾，一套组合拳打下来，钱花了几百万，最后连最基础的CPU使用率告警都配不对，天天误报，值班的人直接把告警群设成免打扰，真出问题的时候，愣是过了四十分钟才有人发现。
对吧？人家谷歌的SRE团队，是百万年薪招的顶级工程师，有专门的团队花几年时间打磨自动化运维平台，有充足的服务器资源做容灾演练。你一个几十人的创业公司，总共三个后端开发，两个运维，学人家搞什么三地五中心多活？先把最基础的监控做好，把最容易出问题的几个告警阈值调对，把常见故障的处置手册写明白，比抄十遍手册有用一百倍。
干了这么多年，我最大的感受是，SRE从来不是什么高高在上的技术岗位，也不是大家眼里的背锅侠。说白了，就是帮团队把那些重复的、容易出错的运维动作，用更聪明的方法解决掉，少让大家熬没必要的夜，少出没必要的故障，让开发能安心写业务代码，让值班的人能睡个整觉。就够了。