北京
一个微服务挂了，所有调用它的服务跟着一起挂。值班工程师的屏幕上瞬间涌进成千上万条告警，而叫得最响的那一条，通常只是受害者，不是元凶。
微软 Codathon 的第三道赛题，要的就是一个能定位根因的 AI 引擎。五人团队 Ace Azael 做出了 Antibody：它读取日志、指标、链路追踪和服务事件，把属于同一次故障的信息折叠成一个事件，再按证据和置信度给可能的根因排序。团队在学院内拿了第一，9,900 分，项目已开源。
最让作者自豪的，是第一天就写下的那条规则：自动化先于 AI。
Antibody 里的每个决策都是确定性的、可复现的：检测、关联、排序、建议。语言模型只负责把引擎已经算好的证据改写成通俗英文，而且这段文字会被标注为 AI 生成。模型挂了也不影响运行，模板会用同一批证据写出解释。
整条流水线因此长成这样：
- 采集：从链路追踪的 span 里学出依赖图，谁调用谁
- 检测：按服务做 EWMA 基线、z 分数，看错误日志和错误 span 的比例
- 防抖：连续两个异常周期才算数
- 关联：新出现的异常服务如果调用链指向故障，就并入已有事件
- 排序：8 个信号合成 0 到 1 的 RCA 分数，注意这不是概率
- 判定：按固定规则给出 HIGH / MEDIUM / LOW，LOW 的含义是“证据不足”
- 建议：匹配故障特征，给出重启、回滚或扩容
- 闭环：人工确认、执行修复、验证恢复、结案、记住
8 个排序信号里，包括异常图上的个性化 PageRank、谁最先出问题、有多少调用方的错误日志指向它、本地故障特征（崩溃、坏部署、泄漏、CPU、慢查询）、近期是否有部署，以及是否匹配历史上已解决的事件。
一个被允许说“我不知道”的引擎
大多数演示会先排出个第一名，然后用十足的把握把它端上来。这个团队想让置信度标签真正有意义，所以它由固定规则产生：头号嫌疑领先第二名多少、有多少种独立证据互相印证、有没有东西跟它矛盾。规则不满足时，Antibody 直接弃权。
基准测试共 84 个场景：7 个服务、6 种故障类型、每种 2 个随机种子，每个场景都有已知的根因。引擎看不到标准答案，标准答案只用于打分。跑一遍 python bench.py 大约 7 秒。
困难模式下的置信度标签：HIGH 出现率 78.6%，其中 98.5% 是对的。LOW 即弃权，出现率 8.3%，在这些场景里强行猜一把，正确率只有 42.9%。整体上，Antibody 一旦给出答案，正确率是 95.8%。
接下来是评委迟早会翻到的部分，团队干脆先写进了 README：
- 在干净流量下，两个更简单的基线也能拿到 100%。这说明模拟器太容易，分不出模型高下。
- 困难模式里，完整模型的总成绩只是和“最响的异常”打平。它赢下了所有安静崩溃的级联场景——根因自己不出声，调用方却吵翻天。它输在故障位于依赖图高层、下方还蹲着一个红鲱鱼的时候。
- 那 6 次失败里，有 5 次被置信度标签标成了 LOW 或 MEDIUM。也就是说，它错的时候，大多知道自己不确定。
其他数字：两个互不相关的故障同时发生，6 对全部被识别为独立事件；检测时间中位数 2 秒；一次数据库崩溃把约 2,000 条事件折叠成一个事件，5 个服务在报警，数据库排在第一。
它现在还做不到的事
- 7 个服务都是模拟的。采集 API 能接真实数据，但还没接过真实系统。
- 故障特征是模式规则，遇到新型故障只会给出“去排查”，而不是一个有把握的修复方案。
- 历史修复的记忆存在进程内，重启就清空。
- API 没有鉴权，它只是个本地演示。
作者从 Antibody 里带走、并在此后每个项目里复用的经验是：用代码做决定，用模型做解释，把“我不确定”当成一等公民的答案。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
