上个月去杭州找做电商的老周吃饭，他吐槽说去年招的两个SRE，干满三个月就全跑了。
原因说出来有点好笑，团队给这俩SRE安排的活，跟之前招的运维没差——天天跟着开发改bug，半夜爬起来接报警，出了问题第一时间要过去兜底，工资比之前的运维高了30%，干的活却一点没少，换谁谁愿意留。
先掰清楚SRE和传统运维的边界
很多人对SRE的认知，还停留在“高级运维”的层面，觉得就是技术更好、能写代码的运维而已。根本不是这么回事。
Google最早搭建SRE团队的时候，定过一个非常硬的规则，SRE团队成员的总工作时长里，最多只能有20%花在oncall处理线上故障上。如果这个比例超过了，说明系统的稳定性已经差到需要靠人堆时间来补了，根本不是SRE的问题，是整个研发流程出了问题。
就说老周他们团队，之前的报警系统规则离谱到什么程度？只要接口响应超过500ms就发钉钉群，不管是测试环境的接口，还是单个用户触发的偶发抖动，一晚上能炸20多条消息。新来的SRE到岗第一周，根本没急着去接报警，先把所有报警规则从头到尾捋了一遍：测试环境的报警全部隔离，单用户触发的偶发异常加聚合规则，连续三次触发才会推送，最后真实需要人工介入的报警量直接降了70%，大家的oncall压力一下子就下来了。
传统运维的核心是“保运行”，服务上线了我负责盯着，挂了我负责重启。但SRE的核心是“建体系”，要把那些重复的、需要人反复做的运维动作全部自动化，从根源上减少需要人介入的故障量。这俩从目标上就不一样。
别让SRE变成专门背锅的角色
现在很多团队的惯性思维更离谱，只要线上出问题，第一反应就是找SRE的麻烦。我去年在深圳见个做社区团购的技术负责人，他们团队去年大促的时候，因为运营临时上了个秒杀活动，没提前跟技术团队同步，流量直接冲了平时的4倍，把商品详情的缓存集群打满了，页面加载要10多秒。当时SRE的几个小伙子熬了一晚上扩容兜底，把故障恢复了，结果复盘的时候，老板劈头盖脸骂SRE的人，说他们容量预估做的不到位。
这种换谁谁不跑？SRE又不是你们团队的蛔虫，怎么可能提前知道运营偷偷上了个活动？正确的协作逻辑本来就应该是，所有可能带来流量波动的需求，不管是产品提的还是运营搞的，在上线前必须拉SRE一起评审，把预估流量、资源消耗、可能的风险全部列清楚，SRE要从项目最开始的阶段就介入，而不是等出问题了才被叫过来救火。
更可笑的是，有些团队甚至把SRE的KPI定成了“全年故障为0”，这种指标本身就违背基本常识。只要系统在跑，就不可能永远不出问题，你把SRE逼得太紧，最后只会让他们为了不背锅，把所有可能出问题的新功能全部拦下来，整个团队的迭代速度直接垮掉。
落地SRE根本不需要照搬大厂模板
很多中小团队的老板，总觉得SRE就是Google那套复杂的体系，要搞多机房容灾，要搞全链路压测，要搞各种高大上的技术平台，一年砸几百万进去，最后团队的人累的要死，实际的稳定性提升根本没多少。
比如我之前接触过一个做本地烘焙连锁的小团队，总共日活才8万，老板看了几篇大厂的技术博客，非要让新来的SRE搞三地五中心的容灾架构，算下来一年光服务器和带宽的成本就要多花300万。对于他们这种规模的业务来说，就算真的机房挂了，最多停服两小时，损失的钱都够付一年的服务器成本了，这不是纯粹的瞎折腾吗？
其实小团队落地SRE，根本不需要搞这么复杂。先把最痛的几个问题解决了就行：比如把所有线上服务的监控补全，不要等用户打电话投诉了才知道服务挂了；把最常重复的运维动作做成自动化脚本，比如服务扩容、数据库主从切换，不要每次都要手动敲命令熬大夜；把报警规则捋顺，不要半夜发一堆没用的报警打扰人。
就连大家经常听的“错误预算”，也根本不需要搞什么复杂的流程。你只要给你的业务定个合理的可用性目标，比如面向普通用户的C端服务，定全年99.9%的可用性就够了，算下来一年允许的故障时间大概是5个小时，这就是你的错误预算。这个额度花完了，后面几个月就别瞎着急上线新功能，老老实实把稳定性的基础打牢，比搞什么虚头巴脑的概念有用多了。
说实话，现在很多团队对SRE的期待，本质上是想找个万能的背锅侠+救火队员，希望花比普通运维高一点的工资，就能拿到一线大厂级别的稳定性保障。哪有这么好的事。
SRE的核心从来不是修服务器，不是接报警，不是替所有人兜底。是帮整个团队建立一套能自我运转的稳定性机制，让写代码的开发、做需求的产品、搞活动的运营，都要对系统的稳定性负责，而不是把所有的压力都压在几个SRE身上。
别再让好好干活的人，心凉了。