那天凌晨两点，服务器挂了。不是那种优雅的 502，是数据库连接池直接雪崩，连带把支付回调接口也拖进了无底洞。手机在五分钟内被客户的微信消息和未接来电震到发烫，屏幕上的光在黑暗里像催命符。我瘫在椅子上，脑子里第一个念头不是怎么修，而是“完了，这个月的流水要打水漂，下个月的房贷怎么办”。
没有团队可以甩锅，没有运维可以背锅。我就是客服、开发、运维的三位一体。先切到备用数据库，手动重启服务，在微信群里发公告安抚客户，手抖着敲命令看日志。日志里全是“Connection timed out”和“Deadlock found”，像在嘲笑我过去两年所谓的“技术架构”。一边回着客户“马上就好，技术正在紧急处理”，一边在终端里疯狂 kill 进程、清理锁表。汗从额角滴到键盘上，那种黏腻感和心脏狂跳的感觉，比任何管理会议都真实。
等支付回调终于恢复，天已经快亮了。我灌下第三杯冰水，看着监控面板上重新爬起来的曲线，没有半点轻松。这次是数据库，下次呢？下下次呢？靠我一个人 24 小时当人肉监控和灭火器，这条路走到黑就是猝死。所谓的“超级个体”，如果只是把一个人的时间拆成八份去填坑，那和当年陷在管理泥潭里没什么区别，无非是坑的形状从“人”变成了“机器”。
我需要的不是更多的“技能”，而是一个能替我“决策”的系统。过去写的那些 Python 脚本，都是单线程的傻小子：监控脚本只负责报警，重启脚本只负责执行。它们之间没有对话，更不会在“数据库连接暴增”和“支付接口超时”同时发生时，判断出根源是前者，并优先执行连接池扩容而不是盲目重启支付服务。这就像让一个只会听令的士兵去指挥一场战役。
我得让脚本学会“看”和“想”。所谓“看”，就是给它更多的传感器。不止是服务器 CPU、内存，还要接上业务日志的实时流，用简单的正则去抓取关键错误模式；接上微信机器人 API，让它能“看到”客户群里的关键词爆发（比如“怎么付不了款”在五分钟内出现十次）。所谓“想”，就是一套最朴素的决策树。我用最笨的 yaml 写了个规则引擎：IF 数据库连接数 > 阈值 AND 支付错误日志激增，THEN 执行预案 A（先扩容数据库连接池，观察 90 秒）；IF 只有支付错误且数据库正常，THEN 执行预案 B（检查第三方支付证书和网络）。预案本身也是脚本，但被这个“大脑”调度。
最难的不是写规则，是让这些系统“闭嘴”和“说话”的时机。早期版本像个躁狂症患者，一点风吹草动就报警，半夜把我吵醒三次，结果都是虚惊。我给它加了“冷却期”和“聚合判断”：同样的错误，五分钟内只提醒一次；多个相关指标同时异常，才触发高等级告警。告警信息也必须“多模态”：普通预警发 Telegram，高等级告警直接打电话。它得知道什么时候该默默处理，什么时候必须把我从床上炸起来。
折腾了快一个月。这个土炮“多模态决策”系统上线那天，我又模拟了一次故障。看着脚本自动识别、执行预案、在业务群发安抚公告、最后给我发了一条“故障已自动恢复，根因：数据库锁，执行操作：连接池扩容+杀死阻塞进程”的报告时，我靠在椅子上，久违地感觉到一点“自由”的滋味。不是时间自由，而是焦虑被暂时卸载的自由。工具不应该只是延伸你的手，它应该在某些时刻，成为你另一个更冷静、不知疲倦的大脑。真正的自由职业，可能不是你一个人能包打天下，而是你终于能打造出一个值得信赖的、自动化的“天下”，让你偶尔可以关上手机，睡个整觉。虽然我知道，下一个未知的故障，正在来的路上。
