北京冬奥会开幕这事儿，我盯着直播看了半小时就切后台了。不是不精彩，是脑子里那套自愈脚本系统又在报警——上周给一个健身连锁品牌做的会员数据同步管道，因为对方服务器半夜升级，三个关键API节点同时挂了，凌晨三点我被钉钉震醒，手动切了备用线路才救回来。这种事儿再来几次，我真得折寿。
自愈力。这词儿现在听着比什么“颠覆”“赋能”实在多了。2019年那会儿带团队做外包，最怕的就是客户半夜一个电话说系统崩了。那时候的解法是堆人，搞24小时轮班值守群，结果就是兄弟们累得跟狗一样，我自己也陷在无穷无尽的救火里，交付质量反而越来越差。人，是最不可靠的“单点故障”。疫情逼我砍掉团队回归一个人干，第一件事就是逼着自己把“被动响应”变成“主动自愈”。
我管这套东西叫“逻辑反馈环”，核心就一句话：给系统装上一个基于IF-THEN-ELSE的脊髓反射弧，别动不动就惊动大脑。拿我现在维护的几个体育健身场馆的数据管道举例。基础架构是n8n搭的，但n8n本身的任务失败重试太基础。我的脚本在每一个数据抓取或API调用节点外面，都包了一层监控壳。
具体怎么干的？比如，爬取某健身平台公开课表，传统做法就是写个requests发过去，等响应，失败了记个log或者发个邮件告警。我的壳子会干这几件事：第一，失败先不是告警，而是立刻分析返回状态码。如果是403频率限制，脚本会自动切换下一个代理IP池里的地址，把请求间隔从2秒随机提升到5-8秒，重试三次。三次都失败，才会触发第二逻辑：切换备用数据源。这个课表信息，可能A平台有，B小程序也有，我的脚本里预埋了3个来源的解析规则，A挂了立刻用B的规则去解析B的页面DOM结构，数据格式在内存里统一转成我定义的标准JSON。
这还没完。如果所有备用源都挂了，脚本会执行“软着陆”：它不是直接抛出一个错误中断整个工作流，而是生成一个带有时间戳和最后已知有效数据的“存根记录”，标记为“数据源暂时不可用，采用上一次缓存”，并把这个事件推送到一个低优先级的检查队列。同时，它会自动生成一个简单的诊断报告——是网络问题、对方页面结构大变，还是API密钥过期？报告直接贴到我的一个私有Discord频道，我第二天早上喝咖啡的时候扫一眼就行，根本不需要半夜处理。
这套逻辑的关键，在于把“故障”细分成等级，并且给每一级都预设好一个不需要我介入的“逃生动作”。就像人的身体，划破皮流血，血小板自己就上了，不会动不动就发烧惊动全身。我现在写的每一个自动化脚本，第一件事不是实现功能，而是画它的“故障树”，穷举它可能死掉的每一种姿势，然后给每一种死法都准备好棺材和替补队员。
冬奥那些炫酷的AI裁判、8K转播，背后肯定有比我这个复杂万倍的高可用架构。但道理是通的：越是光鲜亮丽的数字化盛宴，底下越是一堆默默无闻、自己会喘气会爬起来的“脏活累活系统”。以前我焦虑的是技术栈不够新，现在明白了，能让一堆脆弱的脚本和API像杂草一样，在无人照看的服务器角落里自己活着、自己修复，这种能力，比会写一百种炫技算法更值钱。身体是第一生产力，系统的身体也是。
