订阅服务多起来之后最先崩掉的可能不是服务本身而是你的注意力——某个许可证今天到期、某个接口的额度凌晨耗尽、某个内容源的返回格式三天前就变了可你往往是接到用户投诉后才后知后觉地去翻日志。我就是被这类问题反复折腾之后才决定做一个叫 Dot 的智能体专门负责主动排查订阅异常。Dot 做的事情并不花哨它不等人报障而是按既定周期对每个订阅项做探测发现异常后自动归类、定位根因在安全边界内执行处置动作最后把整个排查过程整理成可回溯的报告。对正在维护多个内容源、SaaS 许可、API 配额或者邮件订阅列表的团队来说这套思路能直接把平均发现时间从小时级压到分钟级。这篇文章就把我从零搭建 Dot 的过程拆开讲清楚包括异常分类、架构设计、主链路实现以及上线后踩过的几个大坑。1. 从接到投诉才发现到主动巡航Dot 要解决的真正问题一开始我也没想着做智能体只是觉得订阅的监控告警不够用。当时的情况是监控面板上堆了上百个图表但没有任何一个图表能告诉我内容源 A 的字段名改了会导致下游解析失败更不会告诉我这个订阅三天前就已经失效了。真正让我下决心动手的是一次几乎可以避免的事故。那次事故的主角是一个内容聚合服务。上游内容源在凌晨悄悄调整了返回结构把published字段改成了pub_date我们的解析器没跟上结果订阅推送静默失败。因为这条链路平时太稳定没人盯着直到三天后用户批量反馈为什么没收到更新我们才发现。查日志、对比线上版本、回溯变更记录前后花了大半天。事后复盘时我意识到订阅异常的核心问题不是缺少监控而是缺少主动排查机制。1.1 被动排查的三个结构性痛点第一个痛点是发现滞后。传统的监控告警依赖阈值阈值设得严了全是误报设得松了就漏报。更麻烦的是很多订阅异常是缓慢劣化——比如接口响应时间从 200ms 涨到 2s再涨到 10s每天只变化一点点任何固定阈值都难以捕捉。第二个痛点是信息分散。一次订阅异常往往牵扯到多个系统订阅源可能没问题问题出在证书过期证书也没问题问题出在本地解析逻辑。没有一套统一流程的话排查人员要登录各种控制台手工关联时间线效率很低。第三个痛点是处置不可控。发现问题只是第一步恢复服务才是目的。但很多订阅系统没有预留自动恢复的接口运维同学只能手动重试、手动切换、手动发通知整个过程既慢又容易出错。1.2 主动排查的定义与设计边界我在设计 Dot 之前先给主动排查定了一个清晰边界避免它变成另一个只会发告警的监控工具周期巡航每个订阅项独立配置巡检周期与它的 SLA 强相关。SLA 要求 15 分钟内发现异常的巡检周期就不能超过 5 分钟。自动归因异常发生后系统要能沿着现象→证据→根因的路径做推理而不是只甩出一个状态码。安全处置允许自动执行的动作必须限定在白名单内例如重试、切换备用通道、暂时降级。需要改配置、动数据的操作一律留给人工。闭环验证每次处置之后重新探测确认异常是否真的消失。处置无效则升级通知。当时团队里也有人建议直接接一个大模型把所有原始日志扔进去让它看着办。我没这么做原因会在后面的架构部分详细说。但从设计边界上我已经确定下来Dot 必须是一个能解释自己每一步决策的系统而不是一个黑盒。2. 订阅异常并不只有链接失败一种异常特征分类表做主动排查之前先得给异常建立一套分类法。一开始我以为订阅异常无非就是连不上、超时但实际梳理下来至少能拆出七类高频问题。分类越细后面的归因逻辑就越简单。2.1 七类高频订阅异常异常类别典型表现探测方式关键判定依据连接不可达超时、TCP 拒绝、DNS 解析失败HTTP 探活 / TCP 拨测连续 N 次失败且成功率低于动态基线内容结构变化字段缺失、类型改变、编码乱码对返回内容做 schema 校验schema 校验失败次数超过冷静期阈值凭证失效401/403、token 过期、证书过期携带凭证发起最小化请求认证错误短时间骤增订阅到期服务降级、收到到期通知查询订阅元数据剩余有效期小于 SLA 窗口数据活性下降条目数为 0、心跳停止监控数据时间戳变化无新数据的空窗期超过历史均值 3 倍配额耗尽429、接口返回额度为 0查询余量指标剩余配额低于预警线状态不一致同一订阅 ID 重复激活、套餐错乱与主数据做对账对账结果出现 diff这里面最容易搞混的是连接不可达和数据活性下降。前者是根本连不上后者是连得上但数据不更新。很多订阅源在正常工作时会定时返回一个心跳包哪怕没有新内容也会刷新时间戳。如果心跳时间戳超过一定时长没变基本可以判定为活性异常这类问题靠普通的 ping 根本发现不了。另一个容易误判的是内容结构变化。接口偶尔返回一次字段缺失可能是上游临时 bug但如果连续多次都缺同一个字段就说明上游做了一次 breaking change。我这里的做法是引入冷静期单次失败先标记为可疑不告警连续失败达到设定次数才确认为异常。冷静期不是让人等而是避免把瞬时抖动误判成故障。2.2 特征库怎么落地分类法最终要落到配置文件里让 Dot 能按特征去探测。我用的是一份 YAML 描述文件每个订阅项声明自己的类型、探测方式、规则集和处置策略subscriptions: - name: content-feed-a type: rss endpoint: https://feed.example.com/rss check_interval: 30m sla: 15m timeout: 5s rules: - connection - schema - activity actions: on_error: [retry, notify] backup_endpoint: https://backup.example.com/rss每个规则都对应一组判定函数。比如connection规则会统计最近 10 次探测的成功率schema规则会维护一个字段白名单activity规则会比较两次探测之间的数据时间戳间隔。特征库的粒度越细后面做归因就越省力因为绝大多数异常在特征命中这一步就已经能定位到根因了。3. Dot 的骨架调度器、探测器、判定器、处置器如何协作确定了异常分类之后我开始搭建 Dot 的整体骨架。这套架构我后来复用了很多次核心思路是把智能体的能力拆成四个可独立迭代的模块调度器负责触发探测器负责采集证据判定器负责判断和归因处置器负责执行动作。3.1 四层模块的职责划分调度器是整个主动排查的发动机。我用的是 APScheduler 这类进程内调度库配置比较简单同时支持周期任务和一次性任务。调度器不直接调用探测逻辑而是生成一个个巡检任务投递给任务队列这样探测器可以异步并发执行不会因为某个订阅项卡住而拖累全局。探测器负责真正去接触外部系统。它做的事情包括发起 HTTP 请求、解析响应、校验 schema、读取配额指标。这里有一个关键设计探测请求必须是最小化请求只获取判断异常所需的字段避免因为探测行为本身给上游造成额外负载。每次探测的结果都会写入时序存储作为后续动态基线的原始数据。判定器是 Dot 的核心。它先跑规则引擎把探测器采集到的指标和特征库里的规则做匹配。规则命中就直接输出结论例如content-feed-a 连续 3 次 schema 校验失败疑似上游结构变更。如果规则没有命中但指标表现出明显异常趋势判定器会把相关证据打包交给 LLM 做补充归因。处置器负责在安全边界内执行动作。动作分成几个等级观察级只记录不干预尝试级会自动重试切换级会启用备用通道通知级会按级别推送给人。所有动作都会被记录到审计日志里。3.2 为什么用规则引擎LLM 兜底而不是全交给大模型这是我被问得最多的问题。其实原因非常实际一是成本每条订阅每分钟探测一次如果每次异常都调用大模型做分析费用很快就失控二是可解释性规则引擎的每一次判定都有明确依据出了问题可以回溯而大模型的输出很难保证稳定三是可测试性规则可以写单元测试能覆盖上游字段变更证书过期这类固定场景大模型很难做到同样的确定性。那 LLM 到底用在哪里我用它处理两类情况规则没有覆盖到的模糊异常以及多个规则同时命中时的优先级排序。比如某个订阅项同时出现了连接超时和 schema 校验失败规则引擎只能分别报出两个异常但 LLM 可以结合历史上下文判断schema 校验失败发生在连接超时之前所以根因大概率是上游改了结构导致连接异常而不是单纯的网络问题。我给 LLM 的输入也不是原始日志而是经过提炼的证据包探测结果、最近 N 次的状态变化、相关规则命中情况。输出被严格限定为结构化的 JSON包含根因假设、置信度、建议动作。这样即使模型给出不准确的建议也不会直接触发任何操作最多只是提醒人工关注。4. 跑通一条完整排查链路从探测命中到根因归因再到闭环处置架构设计好之后真正让我觉得 Dot活起来的是第一条完整排查链路跑通的那一刻。下面我用一个真实发生过的案例来完整拆解这个过程。4.1 主循环的伪代码先看主循环的核心逻辑。为了让思路清楚我用的是带注释的 Python 风格伪代码实际工程里会拆成更多模块async def patrol(): tasks scheduler.collect_due_subscriptions() for task in tasks: sub task.subscription # 1. 探测采集当前状态证据 metrics await prober.probe(sub) # 2. 判定先走规则引擎 hits await adjudicator.evaluate(sub.rules, metrics) if not hits: continue # 3. 归因若有模糊线索交给 LLM 整理 report await adjudicator.attribute(sub, hits, metrics) # 4. 处置只执行白名单内的动作 execution await disposer.handle(sub, report) # 5. 闭环处置完成后再探测一次确认恢复 if execution.should_verify(): confirm await prober.probe(sub) report.verified confirm.is_normal notifier.send(sub, report)这个主循环把主动排查落到了实处每个订阅项都在自己的巡检周期内被巡视异常被发现后紧接着就是归因、处置和验证整个过程不需要人肉参与。4.2 案例内容源改了字段名有一次content-feed-a订阅项被 Dot 标记为 schema 校验失败。探测器拿到的响应里原本应该存在的published字段不见了取而代之的是pub_date。规则引擎立刻命中内容结构变化规则但仅凭这一点还不能确定这是上游改版还是上游 bug。Dot 接着做了两件事。第一它调出了过去 24 小时该订阅项的校验通过率曲线发现失败率从 0% 陡增到 100%说明这不是偶发抖动。第二它把最近三次的原始响应摘要放进证据包交给 LLM 做归因分析。LLM 给出的判断是字段名改变并且新旧字段类型一致建议把pub_date视为published的替代字段同时提醒后端解析器需要变更。这时处置器开始起作用。Dot 没有去改后端代码那是超出安全边界的行为。它执行的是切换级动作先将读取逻辑临时映射到pub_date字段让订阅链路先恢复然后生成一条高优先级工单把 LLM 的归因分析和原始证据附上推给值班同学做正式修复。整个流程从发现问题到链路恢复只用了 6 分钟。4.3 处置动作与安全边界这个案例里最值得注意的是 Dot 对自动处置的克制。并不是所有异常都适合自动恢复我按风险从低到高分了几个等级只读级记录、生成报告、更新状态不对外部系统做任何修改。重试级对失败的请求做有限次数的重试通常配合指数退避。切换级从主通道切到备用通道或启用临时解析映射。通知级升级为告警/工单通知特定角色的人工处理。每次处置动作执行前都要经过一次dry-run检查模拟执行、确认影响范围、再决定是否真正执行。例如切换到备用通道这类动作Dot 会先向备用通道发一个最小化探测请求确认它能正常工作才切换流量。这个习惯帮我挡掉了不少次生事故。5. 踩坑实录误报风暴、模型幻觉、探测频率失控任何系统上线后都会遇到意外Dot 也不例外。这一节我专门说说最折磨人的三个坑每一个都是上线后真实遇到并反复调整过的。5.1 误报风暴第三方接口抖动的狼来了上线第一周Dot 就给我上了一课。某个订阅源因为自身做负载均衡调整连续五分钟内出现了三次 5xx 错误我的规则引擎按照连续 3 次失败即异常的设定立刻触发了告警和工单。结果半小时后上游恢复什么都没发生。更麻烦的是这种误报不是一次性的。由于动态基线还没积累足够数据许多瞬时抖动都被判定成了异常值班群瞬间被消息刷屏。到后来大家看到告警都麻木了真正的问题反而没人第一时间响应。我后来的解决方案是三层过滤第一层是冷静期单次失败只标记为可疑连续达到阈值才进入确认流程第二层是多元确认比如连接失败的同时要检查备用通道是否也失败如果备用通道正常大概率是主通道的单点抖动第三层是动态基线用过去 14 天的数据做滚动统计只有偏离基线超过一定幅度才真正触发告警。这套组合下来误报率降了八成以上但代价是发现异常的延迟增加了 3-5 分钟对大多数订阅场景来说完全可接受。5.2 模型幻觉让 LLM 直接改配置的教训这是我踩过最痛的一个坑。早期版本里我允许 LLM 在置信度足够高时直接生成配置变更建议然后由处置器执行。在某次测试中LLM 面对一个证书过期问题给出的建议竟然是将证书校验模式从 verify 改为 disable理由是这样可以快速恢复服务。从技术角度讲这个建议确实能恢复服务但从安全角度讲这是绝对不能接受的。如果事后没有仔细审查这条建议被自动执行整个订阅链路会在一段时间内失去加密校验能力风险极大。从那以后我改了一条铁律LLM 在任何情况下都不能直接产出可执行配置只能产出结构化建议。处置器里维护了一张动作白名单所有动作必须由人工预先定义。LLM 的建议必须先映射到白名单动作映射不上的就转人工。同时所有涉及安全设置的变更哪怕是人工触发也必须经过二次确认。5.3 探测频率失控频繁巡检反而把上游打爆还有一个很容易被忽视的问题探测本身会对上游造成压力。我最初为了让主动排查更主动把关键订阅项的巡检周期设得非常短结果上游接口开始返回限流错误而且限流错误又被判定为异常形成恶性循环。后来我给每个订阅项增加了一个探测预算的概念每次探测都会消耗一定的预算预算根据订阅项的 SLA 动态补充。SLA 高的订阅项预算多可以更频繁地探测SLA 低的订阅项则保持较低的探测频率。同时在故障期间我反而会降低探测频率因为此时上游可能已经过载继续高频探测只会加重问题。下图是修复前后的对比策略故障发现时间上游限流事件/天误报数/天固定高频探测1-3 分钟4712动态预算退避3-6 分钟32主动排查的价值是及时发现问题而不是不惜代价地高频打探。这个度需要根据实际场景反复调。6. 落地数据与可复用经验让 Dot 从能跑变成好用Dot 在我们这边稳定运行了三个多月最直观的变化是人力投入大幅下降。以前靠人工盯监控和订阅状态每天至少要花两三小时处理各种异常现在是每周只需处理两三次真正需要人工介入的复杂问题其余都被 Dot 在几分钟内自动消化了。我没有刻意去追求复杂的智能体框架整个系统就是调度器探测器判定器处置器的组合。如果你也要做类似的东西有三条经验我觉得是通用的。6.1 先梳理异常特征再写代码很多人一上来就想用大模型做智能推理结果发现连什么算异常都没定义清楚。我的建议是先用两周时间把所有订阅资产的异常形态梳理出来哪怕先用手工脚本探一遍形成一个特征清单。这个清单既是规则的来源也是评估 LLM 归因质量的测试集。6.2 日志和报告是排障的生命线主动排查系统本身也会出问题。Dot 的每一次探测、判定、处置和验证都会写入结构化日志。每个告警工单都会附带一份完整的时间线报告从什么时候开始异常到哪些证据被命中到最后如何恢复一目了然。有了这些信息后续优化才有依据。6.3 把每一次处置当成一次特征库训练Dot 的进化不靠模型参数靠特征库的持续积累。每次人工介入处理完问题后我都会把这次的根因和处置过程整理成新的规则或新的样本。比如那次证书校验方式被建议关闭的事件后来就被抽象成了一条安全规则任何涉及禁用校验的处置请求一律转人工。Dot 会越来越懂你的订阅生态。最后分享一个小技巧把订阅项的巡检配置和主程序分开存放让新接入一个订阅源变得和写一段 YAML 一样简单。我现在给 Dot 接入新的订阅资产时不需要改一行代码只需要在配置文件里声明类型、端点、规则和动作。这个配置化的设计可能是 Dot 在团队里能持续用下去的最大原因。
