北京
“事故自动修复”——这句话听起来很诱人，但瑞安（airCloset CTO）在分享自家内部AI平台“cortex”的生产实践时坦言，单靠自动修复远远不够。真正关键的是，每次修复都必须顺手消灭整类问题，让质量门槛在一次次的“自愈+自强化”循环中不断抬高。
过去30天，cortex系统自动合并了115个自愈拉取请求，几乎所有拉取请求都在完全没有人类参与的情况下完成合并和部署。只有当AI判断“这不是代码能解决的问题”时，人才会介入。这115次操作更准确的描述是：监控在生产环境中捕捉到的异常，AI在任何人醒来之前就完成了修复。瑞安提到的“每月真正需要人工确认的事故”已降至个位数。
在这115次自愈动作中，同一个服务反复触发警报的模式非常明显——例如“gcs-transformer”在统计的61次里占了25次。这正是后续要介绍的复发预防循环要做的事：把这些反复出现的反模式转化为代码检查规则、持续集成守卫、类型约束或开发指南。每次自愈修复的拉取请求都会被要求新增一条指南，确保同样的错误模式以后在审查阶段就被自动拒绝。
瑞安还提供了一个诚实的注脚：最近一个月的自愈次数略有膨胀。原因是代码库中曾存在不少“静默捕获”模式——即捕获异常却不记录任何日志的代码块。团队添加了反静默捕获的检查规则，并分批清扫了历史遗留的静默捕获，结果原先隐藏的生产错误被暴露成告警。所以当前数据的一部分是“监控终于追上现实”带来的冲高。但随着复发预防循环将这些暴露出来的问题逐步转化为检查规则，数量最终会趋于收敛。在他看来，“以前看不到的东西现在能看到”本身就是一次质量提升，现在看到的只是补课阶段。
瑞安着重强调了一点：如果依靠人工来完成同样的闭环——认领告警、阅读日志、理解代码、修复、发起拉取请求、审查、部署——115次这样的循环会耗尽任何团队的工程带宽。这套自愈系统之所以有价值，是因为它在无人察觉的情况下吸收了这些扰动，并且同时把修复转化为新护栏，自动纳入代码检查、持续集成守卫、类型约束或指南更新中。正是这个“修一次，堵一类”的机制，让生产环境的质量防线在一次次的自我修复后变得越来越坚固。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
