客户那边电话打过来的时候，我正在用 n8n 调试一个自动回复流程。系统报警邮件已经塞满了收件箱，但我没时间看。电话那头是愤怒的咆哮，说他们的数据面板全红了，订单卡死，问我到底在搞什么。我一边道歉，一边切到服务器终端，top 命令一看，CPU 占用 99%，内存快爆了。是昨晚更新的一个数据同步节点，死循环了。
挂了电话，我深吸一口气。这就是超级个体的日常：没有运维同事帮你重启服务，没有开发兄弟帮你 hotfix，更没有客服妹子帮你安抚客户。你就是客服，你就是运维，你就是那个写 bug 的人。我先把 n8n 里那个出错的 workflow 停了，然后 SSH 连上去 kill 掉进程。服务恢复大概用了三分钟，但这三分钟里，我手机又震了两次，微信群里@我的消息跳了十几条。我得在同一个屏幕上，分三个窗口：一个终端，一个 n8n 编辑器，一个微信。脑子里同时处理三件事：向客户解释故障原因（客服），写临时脚本清理脏数据（运维），复盘 workflow 逻辑哪里出了边界条件错误（开发）。
这他妈就是 2022 年的我。39 岁，名义上是“超级个体”，实际上是个 7×24 小时待命的救火队长。上周还有个搞“副业联盟”的老朋友找我，说有个项目，拉个团队做小程序商城，“流水可观”。我直接拒了。2019 年我就是信了这种鬼话，组了个六人团队，结果呢？赚的那点钱全填了工资和社保，自己从写代码的变成跪甲方的、哄员工的、算账的。身心俱疲到去查了心脏彩超。现在？我宁可一个人，在书房里，面对这些冰冷的服务器日志和代码错误。
因为我知道问题出在哪。不是人不够，是工具太原始。或者说，我使用工具的方式还停留在“手工作坊”阶段。这次故障的根本原因，是我那个 n8n 的 workflow 缺少完善的异常处理和监控告警。它就像一个没有保险丝的电路，一短路就全烧了。我花了接下来四个小时做三件事：第一，给所有关键数据流节点加上 try-catch，错误时自动重试三次并记录日志到数据库。第二，写了一个 Python 脚本，用 psutil 库定时检测关键进程的资源和状态，异常时通过 Telegram Bot API 给我手机发警报。第三，在 workflow 的起始和结束节点，硬编码了执行时间的检查，超时即自动终止并标记为失败。
这听起来都是很基础的运维工程，对吧？但对一个长期做业务开发、习惯了“跑起来就行”的产品经理来说，每一步都是新坑。比如用 n8n 的“Function”节点写 JavaScript 来处理异常，你得搞清楚它的异步上下文和普通的 Node.js 有啥不同。再比如 Telegram Bot 的 API 有频率限制，警报消息不能发得太密集，你得自己写个简单的消息队列来缓冲。这些细节，没人教你，文档也语焉不详，全靠 Stack Overflow 和把错误信息复制粘贴到 Google 里硬搜。
搞完这些，天已经黑了。我靠在椅子上，感觉比跟甲方吵三小时架还累。但心里有种奇怪的踏实感。这套简陋的自动化监控和自愈机制，是我一个人的“运维团队”。它不会抱怨，不会离职，7×24 小时盯着系统。而我，终于可以从“随时待命”的焦虑里，偷出一点点时间去想更长远的事。
这就是我拒绝所有“团队”和“加盟”的底气。不是我不需要协作，是我需要的协作对象，不再是另一个会疲惫、会闹情绪、需要我管理的人。我需要的是更强大的工具，是能理解我意图的 AI，是能把重复性劳动彻底封装掉的自动化流程。Llama 3 的开源消息那时候已经隐约在圈子里流传了，我知道，下一波浪潮要来了。而我这种被逼到绝境、必须一个人搞定所有技术栈的“超级个体”，或许才是最能快速适应那种“人机协作”新形态的人。
客户后来发消息说系统稳定了，还夸我响应快。我没告诉他，那三分钟的“快”，是用我过去四年踩过的所有管理陷阱、身体警报和深夜焦虑换来的。书房里很安静，只有服务器风扇的低鸣。我把刚才故障处理的过程，用 obsidian 记成了笔记，标签打了“#故障复盘”、“#自动化运维”、“#n8n进阶”。这大概就是 39 岁最好的状态：远离喧嚣的“事业”，守住一张书桌，和真正值得死磕的东西。
