凌晨两点四十七分，床头柜上的手机震了一下。
老张摸黑抓起来看，监控平台推的：某台机器磁盘使用率 85%。他翻身接着睡。第二天早上，那条告警还静静躺在值班群里，谁也没回。
搁三年前他肯定爬起来登机器了。现在不。不是懒，是学会了分辨噪音。
这事挺能说明 SRE 的处境。很多同行对这个岗位的第一印象是“高级运维”，我一开始也这么想。真在团队里泡上一阵才明白，修机器只占很小一块，大头是跟整个组织的混乱长期拉扯。
告警不是越多越安全
有个数字我一直记着。某团队一个月发了四万条告警，其中真正需要人动手的，不到两百条。
剩下那三万九千多条干了什么？它们把人的注意力磨平了。心理学上叫“狼来了”效应——值班同学扫一眼，觉得又是那台老机器的老毛病，划掉。真正的故障，就是在这种一次次的“划掉”里漏出去的。
我们后来干了一件事，把所有告警拉出来过一遍，每条只问三个问题。这条响了之后人会做什么动作？这个动作能不能自动化？如果什么都不做，会怎样？三个问题全答不上来的，直接删。
删完从四万降到六百。听着吓人吧？其实那一个月线上事故的数量，一点变化都没有。
把可靠性变成一个能吵架的数字
“我们要保证高可用”——这句话基本等于没说。什么叫高？99.9% 和 99.99% 之间隔着一条人命。前者一年能停 8.76 小时，后者只能停 52 分钟。差一个九，成本翻着番往上走。
所以 SLI、SLO 这套东西的价值，不在于它多先进，在于它把话说明白了。你选哪个指标代表用户体验？延迟、成功率，还是订单转化？目标定在几个九？这个数字谁签的字？
没人签字，出了事就是各说各话。业务方觉得你不行，你觉得业务方漫天要价。
顺带说个反直觉的点：SLO 不是越高越好。我见过一个内部报表系统硬要定到 99.99%，结果团队一半精力砸在它身上，核心交易链路反而没人管。可靠性是要算投入产出比的，不是道德竞赛。
还有 error budget，说白了就是“允许你出错的额度”。这个月额度还剩六成，那就放心发版，放开了做实验。要是已经用掉九成，冻结变更，先修稳定性。把这事变成一条客观规则，比谁在群里喊一嗓子管用得多。
事故大多是自己改出来的
行业里有个大概的统计口径，线上故障七成左右跟变更相关。发版、改配置、调参数、切流量，都算变更。
我的经验是，出问题往往不在于变更本身，而在于变更没有退路。
有个很土但极其有效的做法：写发布脚本之前，先把回滚脚本写完。听着像废话，可你去问问身边的人，多少团队的“回滚”实际上是“再发一版修回去”。那种时候手是抖的，脑子是乱的，群里还在刷屏问好了没有。
灰度这词被说烂了。真正难的地方在于，定义什么条件下自动回滚。错误率超过 1%？还是 P99 延迟涨了一半？这个阈值得提前定死，写进发布系统，让机器去判断。靠人盯着仪表盘拍板，凌晨三点没人拍得准。
最贵的资源其实是人
Google 那套 SRE 里有个词叫 toil，译成“杂役”或“琐事”都行。指的是那些重复的、可自动化的、没有长期价值的活。手工扩容、手工改配置、手工导报表。
他们给的红线是，toil 占比不该超过 50%。超过这个数，说明团队正在被消耗，工程能力在退化。
国内很多团队没这个意识。人一忙就觉得是好事，其实忙在搬砖上，系统一点没变好。
值班这事也得讲人性。跨时区的团队按“跟随太阳”排班，谁的白天谁值班。人少的团队，至少保证值完夜班能调休。被半夜叫醒三次，还指望第二天精神饱满地写代码，这不太现实。
复盘也一样。事故会如果开成了批斗会，下一次大家就会想办法把事故藏起来。而藏起来的事故，才是最危险的。
明天就能动手的三件小事
不用搞什么宏大规划。挑一天，把告警列表拉出来，删掉一半——先删那些“响了也没人管”的。
然后找业务方喝杯咖啡，挑一条最核心的链路，定一个 SLO。不用多精确，先跑起来，一个月后再调。
再挑个周末的低峰期，把回滚演练做一遍。真执行一次，掐着表看要多久。你会发现很多理所当然的事，其实根本跑不通。
做完这三件，你大概就能摸到，SRE 跟运维到底差在哪了。