先说一个让我失眠的故障
那是某个周四凌晨2点47分，我被电话吵醒。数据库主从延迟从0.5秒突然飙到147秒，整个订单中心的所有读请求全部走主库，CPU直接打满。我披上衣服坐到电脑前，先看慢查询，再看连接数，最后翻到binlog。结果发现是一个开发同事上线前手动跑了一条UPDATE，忘了加WHERE条件，十五万行数据全被改成同一个值。业务那边凌晨三点半给我打电话催恢复，我说要么回滚binlog，要么用备份闪回，前者需要十五分钟，后者要三十分钟，期间这个脏数据会持续影响下游。那一刻我做了一个决定：直接kill掉那条事务的连接，然后通知业务方所有涉及该范围的查询一律走缓存，同时手动修正数据。整个过程花了四十多分钟。
第二天复盘的时候，开发部门的组长很客气，但话里的意思我听得懂："为什么监控没有提前告警？"我调出了监控系统里的原始记录——那条SQL执行前，我们的慢查询阈值设的是2秒，而这条SQL的执行计划因为走了索引，前两秒确实没超阈值，锁等待也没触发检测规则。也就是说，监控系统不是没报，而是报警逻辑只盯着慢查询，没有人写一条"单条UPDATE影响行数超过1000就拦截"的规则。事后我在自己的笔记里写了这么一句：监控覆盖不到的地方，就是事故的温床。
但真正让我失眠的，不是这次事故本身，而是我觉得这个行业把"服务稳定性"这四个字想得太简单了。大家只看到你稳住了，没看到你是用什么代价稳住的。
稳定性的成本，从来不是一张监控大屏
很多文章谈稳定性管理，上来就是监控覆盖率、告警收敛率、SLA达标率，听起来特别体系化。但真实情况是，绝大多数运维团队根本没有精力去搞什么精细化管理。我认识一个干了八年的老运维，在一家日活千万级的电商公司，他们监控系统里一共挂了684条告警规则，其中真正有人在看的不超过50条。剩下的都是历史遗留，有的规则是某个已经离职的同事写的，有的规则对应的服务早就下线了，但是没人删，因为怕删了出问题没人背锅。
我自己的团队也是这样。去年年底做了一次告警治理，把所有告警规则拉出来跑了一遍30天的历史数据，发现真正触发且有操作价值的告警只占全部告警的11%。剩下的89%全是噪音，包括但不限于：容器内存瞬时飙到75%然后回落，某些业务的夜间定时任务导致的CPU毛刺，还有因为我们自己的监控组件版本不一致而误报的接口超时。这些噪音的代价是什么？是我们团队的人逐步养成了"告警已读但不处理"的习惯。
直到今年5月，有一次线上服务真的挂了，P0级告警发到群里，好几个人点了"确认"，但整整十分钟没有人去排查。为什么？因为大家都默认这是又一次误报。后来我们改了一个机制：凡是P0告警，必须由值班人手动在群里回复"我接手了"，并且要附带一条初步排查命令的输出截图，否则告警每五分钟会通过电话精准打到个人手机。改了之后，误报依然有，但至少每次告警都有人第一时间响应了。
这件事让我意识到，稳定性不是一套标准化的工具链能堆出来的，它更像是一个团队在长期内被"狼来了"反复消耗之后，还能不能保持对风险的敏感度。这种敏感度一旦丢了，你上再贵的监控产品都白搭。
对比SRE和传统运维，我的态度是：别迷信title
行业内现在特别流行把运维团队改名叫SRE（站点可靠性工程），好像换了个名字就能解决所有问题。我自己也带过两个SRE方向的候选人，都是简历上写得花团锦簇。聊到具体问题的时候，我习惯性问一句：假设你的服务在凌晨四点出现大面积不可用，但查不到任何告警，你的第一反应会是什么？有一个候选人回答是先去看代码发布记录，另一个回答是直接上APM系统看调用链路。说实话，这回答听起来很专业，但真实场景里，我做过类似的事，你去看代码发布记录要登录跳板机，查十几个应用的版本号，等你对比完，业务早就被打爆了。正确做法是先去网关层看流量有没有异常，如果流量没掉，再去查有没有哪个接口的P99延迟突增，用这个来定位调用方是谁。
我的核心观点是：SRE的"E"是Engineering，但很多人的工程化思维只停留在线上工具和自动化脚本上，忽略了运维最关键的能力其实是"现场判断力"。这个能力没法通过教程学会，只能靠真实故障喂出来。这也是为什么我面试从来不问什么Docker和K8s的底层原理，而是花十五分钟聊他处理的最近一次事故：什么时候发现的，用的什么手段定位的，为什么要选这个手段而不是另一个，中间有没有走过弯路。能把这几个问题讲清楚且不带任何表演成分的人，比那些能把K8s源码架构图默写出来的人要靠谱得多。
传统运维和SRE的差别，不在于你有没有写代码的能力，也不在于你会不会用某个可观测性平台。差别在于，传统运维是"保障平台按既定规则运行"，SRE是"通过不断调整规则来让平台更适应变化"。前者是稳态，后者是动态。而现实是，大部分所谓SRE岗位，做的还是前者的事，只是换了个更高级的title，然后被要求写一堆毫无意义的周报。
关于自动化和AIOps，我持悲观态度
最近AIOps这个概念又热起来了，很多团队开始引入一些所谓的智能告警分析平台，号称能用算法自动找到根因。我特意在今年年初调研过三个主流产品，用我们去年线上真实故障的数据做了个盲测，结果显示，算法能准确定位到根因模块的概率在35%左右，而一个熟练的运维工程师通过经验判断，准确率可以到70%以上。更扎心的是，这35%的准确率还是在故障已经触发告警的情况下计算的，算法并没有能力从海量的日志里提前发现潜在隐患。
我不否认AI在日志聚类和异常检测上有价值，但现在的AIOps产品离真正的"自动驾驶"还差得远，最多算是个辅助驾驶。最明显的问题是，算法模型都是基于你提供的历史数据训练的，而线上故障最大的特点就是"不重复"。你永远不可能预料到，下一个故障是因为某个开发在服务器上误删了一个系统依赖库，还是因为某个云厂商的底层物理机磁盘扇区损坏导致IO延迟飙升。这些场景没法靠训练历史数据来解决。
所以我一直坚持一个反主流的做法：我们团队的自动化程度刻意保持在60%到70%左右，剩下的30%到40%必须留给人来临时决策。比如服务器批量扩容，我要求必须人工在变更平台上点击确认，而不是全自动触发。虽然这会多花两分钟，但它能有效避免"自动化脚本在错误的时间点执行了正确的事情"这种灾难。别笑，这种事真的发生过：有一次我们的自动弹性扩容规则因为监控数据源异常，在凌晨低峰期突然创建了30台大规格实例，账单多了八千多块钱。
运维的价值到底应该怎么衡量
最后聊一个很多运维工程师都困惑的问题：我们做的那些事，到底怎么向老板证明价值？你没法说"这个月线上没出故障，因为我的监控做得好"，因为不出故障是默认的，出了故障才有人想起你。我做了一年多的尝试，把运维的工作拆成两个维度：一个是成本节约，另一个是效率提升。成本节约好理解，比如通过治理闲置云资源，我们每个月节省了大概35%的云上支出，这个数字是财务认的。效率提升就难衡量一点，我的做法是记录每一次发布从代码提交到上线的时间线，然后对比年初和年末的中位数，用这个来体现平台化建设的价值。
但比起这些，我更想说的是，运维的工作本质上是给业务买保险。你买了一份保险，每个月交几千块保费，但一整年都没有理赔，你会觉得这个保险没用吗？不会，因为你知道它的价值在于"万一"。运维也一样，我们的价值在于让那些"万一"发生的时候，损失被控制到最小。想清楚这一点，很多事情就不纠结了。
写了这么多，其实没什么体系，就是一些零散的真实体会。如果你正在做运维，恰好也有类似的感觉，希望这些文字能让你意识到，你不是一个人。如果你想入行，我也建议你做好心理准备：这个岗位不会一直让你有成就感，但它绝对能让你成为那个在任何混乱现场都能深呼吸的人。