Oncall Bot 与前端监控

问题

第三方交接环节（例如 NFC 校验）中的悄然流失，往往要几天后才通过客服反馈发现。我们的告警基于固定阈值，噪音很大，大家早已学会忽略它们。

方案

• 使用相对基线，而不是固定阈值。 告警服务对 ClickHouse 运行 SQL，把每个指标与上周同一小时比较。转化率下降 20%，在东京凌晨 3 点和柏林中午的含义完全不同，全球流量的正常波动也不再引发误报。
• 告警自带上下文。 告警触发时，会在内部聊天平台发布一张事件卡片。后台任务随后从 ClickHouse 收集近期的前端错误堆栈，从配置服务获取当前生效的配置版本，再加上 Kubernetes 部署日志，整理成结构化提示词发送给企业级 LLM API。
• 在对话串里给出摘要。 机器人回复一个可能的根因，例如：日本第 3 步转化率下降 32%，NFC 桥接封装层出现空指针错误，15 分钟前部署了一次配置变更，同时后端的供应商网关超时。

结果

发现问题的时间从数小时或数天缩短到 5 分钟以内，缓解时间减少 65%，误报告警减少 80%。我还跟踪了告警信噪比（对应真实事件的告警占比）以及前端模块的平均故障间隔时间。

为什么这样做

普通告警只告诉你出了问题。自动收集数据并生成摘要，则弥合了“一个指标”与“有人真正理解它”之间的差距，而大部分响应时间正是耗在这里。