H3.14.3error report rate as an alarm signal设计研究
上报频率异常升高本身就是需要告警的信号
别名: 上报突增 · error spike · 频率告警
概念解释
单条上报说明有人失败了。单位时间内同类上报突然变多，说明一条路同时断了——发布、依赖、配置或攻击。频率升高本身要告警，不要等工单堆积或等到有人碰巧看见仪表盘。这条管把速率当信号，不管单条载荷里写什么。
机制
交互失败在平稳期有一个底噪：某地区网络、某旧设备、某条少走的路径。底噪的突变比单条堆栈更快指出「现在和十分钟前不一样」。人的投诉有延迟，自动上报的速率几乎没有。告警要把「条数」换成「相对自己的基线」：同一版本、同一小时的同比，而不是一个全球绝对阈值——日活上涨也会抬升绝对数。不告警的突增会在用户已经改走别的产品之后才被当事故处理。误报会训练值班忽略，于是真突增也被点穿，和确认框的习惯化是同一机制。
怎么研究
用历史上报序列回放：在已知事故窗口和无事故窗口上跑不同的检测（绝对阈值、相对基线、分版本）。
自变量：检测方法、窗口长度、是否按版本或地区切片。 因变量：已知事故的检出延迟、无事故窗口的误报次数、值班是否开始忽略某类告警。
不要用「我们觉得这次该响」当标签。用事后已确认的事故时间窗。
边界
发布瞬间的短暂尖峰可能是客户端一齐升级，需要与版本号对齐，避免每次发版都叫事故。客户端时钟错误会造成假突增，服务端接收时间更可靠。用户反复重试同一失败会放大速率，应按用户去重后再比基线，否则一个人的死循环等于万人故障。告警静默时段对交互失败通常不成立：用户不会因为夜里就不失败。
怎么落地
- 对关键错误类型建基线，突增按相对变化告警，并带上版本与路径切片。
- 同一用户短时间的重复上报先折叠再计数，避免重试策略污染速率。
- 告警要能点进样本路径，而不是只丢一个整数。
- 验证：用一次真实或演练的故障看从速率爬升到人接手的时间。若靠工单才知道，频率就还没被当成信号。