忙着救火，问题为什么还在？

服务器的临时目录涨到 95%，报警响了。

工程师登录机器，翻文件、删日志，容量掉下去，群里安静。几天后，同一条报警又回来，大家再做一遍。

这种场面，我一眼就能看懂。第一个动作当然是先恢复服务。可如果每次只把日志删掉，所谓高效，只是同一场火救得越来越熟。

救火很容易被看见。

报警几点响、谁第一个回复、多久恢复、谁熬到凌晨，这些都有时间戳，也方便写进周报。相比之下，清理一条长期没用的任务、补一个容量限制、把重复操作做成自动化，常常安安静静，甚至很难说清“避免了哪次事故”。

于是评价系统会偷偷改写大家的选择：先把眼前的红灯按灭，至于它为什么总亮，等不忙了再说。

可“等不忙”通常不会来。一个问题没被设计掉，它就会继续制造下一次紧急。

这里最容易混淆的是，响应时间和问题质量不是同一个指标。十分钟恢复，说明值班的人反应快；如果同类故障每周来一次，它也同时说明系统仍在稳定地产生麻烦。

第一个数字容易统计，第二个数字需要把一段时间的事件串起来看。只考核前者，团队自然会越来越擅长眼前这十分钟，却很难拿出半天去换未来少一次报警。

救火速度只能证明这次恢复得快，不能证明问题变少了。

Google 的 SRE 手册把这类工作叫作 toil，可以理解为“运维苦活”：手工、重复、可自动化、被中断驱动，而且做完以后系统没有留下持久改善。

他们给 SRE 团队定过一个很具体的目标：运维性工作尽量不超过一半，至少一半时间要留给能减少未来苦活的工程工作。

这不是所有公司的标准答案。它有价值的地方，是逼着团队把两种忙分开记账。

一种忙让今天恢复正常。另一种忙让下周少响一次报警。

前者不能没有，后者如果长期没有，团队就会被自己的勤奋困住。业务一增长，人工处理量跟着线性增长；新人进来只会接过更多重复按钮，没空建设系统。

一次性的故障当然可能只值得手工处理。真正该警惕的是同一类动作开始复读：同一个目录又满了，同一个服务又要重启，同一份数据又要人工补。第二次出现时，它还是事故；第三次再来，它已经是流程设计的一部分。

所以我更愿意看三笔账。

第一笔，这次故障多久恢复。第二笔，同类故障在下一个统计周期里又来了几次。第三笔，处理它还需要多少人工步骤。

还是拿 95% 的临时目录来说。删日志让第一笔变好；把无用日志停掉、设置轮转上限，让第二笔下降；再把容量检查和清理做成可审计的自动任务，第三笔才会减少。

三笔账不要求每次事故都做成大工程。它只是逼着人说清楚：这次是在恢复，还是留下了持久改进。两件事都重要，但不能拿前者的速度冒充后者的结果。

只看第一笔，英雄会越来越多。三笔一起看，才知道系统有没有真的往前走。

真正的效率，不是把同一场火救得更漂亮，而是让它少烧一次。

我也会被“立刻处理完”的感觉骗住。

报警清零，工单关闭，清单上多一个对勾，反馈来得又快又确定。反倒是花半天追根因、改监控、删掉一段历史包袱，看起来像什么都没发生。

这也是最难受的反转：有时团队也想解决根本问题，只是我们只给救火留了掌声，没给少起一场火留位置。

如果一个人每周都能漂亮地救下同一场火，问题也不只在他。系统正在拿他的责任心当补丁，而且补得越稳，真正的缺口越不容易被看见。

下一次红灯再亮，当然还得有人冲过去。

只是灯灭以后，那条报警会不会第三次出现，才是这支团队真正交出的成绩。