SRE从来不是运维新马甲

去年6月在新街口那家开了快十年的独立咖啡馆，我跟做本地生鲜电商的老周对着冰美式坐了俩小时。他吐槽去年618零点的惨状：APP直接卡成PPT，客服电话被打爆，运营在大群里@研发问为啥又崩，运维组的小伙子们蹲在机房满头大汗重启服务，连晚饭点的黄焖鸡都凉透了，最后算下来三个小时的故障，直接让当天的GMV折了近两成。

他说之前为了补这块短板，专门招了个号称有五年SRE经验的人，结果干了三个月，跟之前的运维没差。

真的。

每天的工作就是接告警、处理故障、填故障报告，连他们用了三年的老监控系统的告警规则，都没敢动过——怕改乱了漏了更麻烦。

先把最拧巴的认知掰过来

说真的，我当时听他说那个所谓的SRE，连错误预算是什么都答不上来的时候，差点把咖啡喷出来。

太多公司对SRE的理解从根上就错了。觉得这就是高级版运维，是给运维涨薪换个名头，甚至是想让之前需要十个人干的运维活，现在找两个SRE就全搞定。

Google最早搞SRE的初衷，根本不是为了把运维的活干得更快。是因为当时的运维团队天天陷在重复的故障处理里，根本腾不出时间做长期的稳定性建设，最后干脆把这部分工作交给懂软件工程的人，用写代码的方式解决运维的重复劳动，从根上减少故障的发生。

就拿老周他们公司来说，要求核心链路全年可用性99.99%，连一年里允许有多少故障时间都不跟业务谈，不管是大促还是日常，只要出问题就全是运维的锅。这种环境下，就算把Google的SRE团队挖过来，也得天天蹲在机房重启服务。

真把SRE落地的团队是什么样

我认识的南京本地一家做企业服务的公司，SRE团队满打满算四个人，比老周他们的运维组少一半人，去年全年的三次大促，核心链路连一次超过五分钟的故障都没有。

他们的做法说出来一点都不高大上。首先跟每个业务线坐下来谈，把全年的错误预算摆到台面上：核心交易链路全年允许累计1小时的不可用时间，算下来每个月平均5分钟，花完了这个月就不许再上任何新功能，先停下来搞稳定性建设。

他们的SRE根本不接一线的告警。一线的告警先直接发给值班的研发，要是五分钟没响应没处理，才会升级到SRE的值班群。毕竟最懂服务哪里容易出问题的，永远是写代码的人，SRE没必要天天帮研发擦屁股。

最关键的是，他们的SRE把之前所有需要人手动做的重复操作，比如磁盘满了的清理、服务异常的重启、大促前的容量检查，全部写成了自动化脚本。之前大促前要三个人花一下午逐台机器查容量，现在系统自动跑一遍，发现容量不够直接自动扩容，十分钟就能搞定。

不过话说回来，这事儿真不是靠买个最贵的监控系统就能搞定的。太多公司花几十万买了顶级的APM工具，结果还是天天半夜爬起来处理告警，本质上就是没人愿意花时间把重复的劳动变成自动化——大家都觉得“故障处理快就行，写脚本太费时间”。

别迷信那些飘在天上的方法论

现在一提到SRE，很多人上来就背Google总结的四大黄金信号：延迟、流量、错误、饱和度，背得滚瓜烂熟，恨不得给公司所有服务都把这四个指标的监控全部配上。

有啥用啊？

之前有个刚毕业的小孩去朋友的公司做SRE，上来就给所有服务配了满屏的黄金信号监控，一天能弹出来几千条告警，最后整个团队直接把告警群设成了免打扰，真出了故障反倒没人看见。

真正落地的SRE，从来都是从自己团队最痛的那个点开始的。别上来就搭一整套完美的监控体系，别上来就搞全链路压测，先看看你现在每周要重复三次以上的运维操作是什么。是发版太麻烦容易点错按钮？还是每次磁盘满了都要手动清理？还是告警太多大家都看不过来？

就从这个点开始解决。比如刚才说的那家企业服务公司，刚开始搞SRE的时候，就先解决了发版的问题：之前每次发版要三个人手动操作两小时，还经常因为点错按钮搞出线上故障，他们花了两周时间写了自动化发版脚本，加了灰度和自动回滚，直接把发版时间缩到10分钟，人力成本降了80%。光这一项省下来的时间，就够他们把之前的故障处理流程全部捋顺了。

老周上个月给我发微信，说今年618的时候他们APP的流量翻了三倍，全程没崩。之前招的那个SRE，现在把之前所有的重复操作都写成了自动化脚本，上周还休了三天小长假去千岛湖玩。

你看。

哪有那么多高大上的东西啊。

要是你现在所在的团队想搞SRE，别上来就招一堆人，别上来就买一堆系统，先从把你每周重复做三次以上的操作写成脚本开始，就够了。