高峰时段报警数常用于评估事故下的可用性
别名: 峰值报警负荷 · peak alarm rate
概念解释
高峰报警负荷（peak alarm load）衡量的是最繁忙的那段短时间窗口内报警到达的数量以及形成的积压，用来判断真正发生事故、系统受到扰动的时候，报警通道会不会仍然可用。这条只讨论峰值窗口这一个统计维度该怎么定义和使用，长期均值该怎么解读、哪些报警是坏演员、指标该多久复核，分别是同组另外三叶的内容。窗口长度这个参数必须和实际的响应任务相称，并且要在报告数字的时候明确写出来，不能藏在方法论细节里不提。
机制
平均负荷可以整体上看起来很低，同时在数分钟之内出现极高的爆发——这两件事并不矛盾，因为平均值本来就是把峰谷都抹平之后的结果。峰值分析能同时暴露好几个问题：显示界面本身能不能承载这么多条同时出现的报警、报警排队和呈现的顺序逻辑是否合理、多个角色之间会不会因为同一批报警产生职责冲突，以及团队实际的服务能力上限在哪里。但只数到达的数量还不够，还需要看关键报警是不是得到了足够快的首次处置，以及积压什么时候才真正消退下去，这两点单靠一个到达数字看不出来。
边界
历史上出现过的峰值不能被当成"最坏可信事故"的上限，真实事故完全可能超过历史记录；另外通信中断恢复之后，被缓存的消息往往会集中批量补发，这种情况下测出来的峰值反映的是通信恢复的行为，而不是过程本身真实的报警负荷。不同长度的窗口算出来的数字互相之间没有可比性，不能为了让结果好看而挑选对自己最有利的那个窗口长度去报告。
怎么落地
预先规定好几个和实际任务相关的窗口长度，比如事故发生后最初几分钟、以及某个更长的持续处置阶段，分别报告到达数量、未确认的积压量、关键报警的首次响应时间和恢复到正常水平所需的时间。压力测试场景既要用历史上真实发生过的事故重放，也要结合危害分析推导出来的、更严重但仍然可信的场景一起测，不能只用出现过的最坏情况当作测试上限。