报警疲劳的后果通常在真实事故发生时才显现
别名: 报警疲劳潜伏后果 · alarm fatigue
概念解释
报警疲劳造成的损害往往是潜伏性的：日常运行中，操作员看起来把大量报警都及时确认掉了，系统运转正常，直到某一次罕见的真实事故发生，才会暴露出漏检、响应延迟或者处置优先级排错这些问题，这时候才发现原本以为在起作用的人机保护屏障其实早就已经失效了。这条讨论的是这种潜伏性本身、以及该怎么提前发现它，脱敏怎么形成、信任损耗还包括什么、该从哪些工程手段降低误报，分别是同组另外三叶的内容。
机制
很多组织习惯用"所有报警都被确认了"作为报警系统运转正常的成功标志，但这个指标只能证明有人点了确认按钮，完全没有测出操作员是不是真正理解了消息、有没有采取正确的动作。真实事故本身发生的概率很低，能拿来验证的真实样本因此非常稀少，日常状态下操作员表现出来的"快速确认、系统顺畅运行"，很容易被误当成团队应对能力强、系统运行良好，实际上这种表现可能只是脱敏之后的适应行为，跟真正的应急能力完全是两回事。
边界
不能因为潜伏期看起来一切正常，就选择等到事故统计数据出现明显异常之后才承认有问题，那样代价太高；但另一方面，用仿真或者演练去替代真实事故进行验证，本身也受限于场景是不是足够真实、参与人员的动机是不是和真实情况一致、以及演练能不能持续足够长的时间才能复现出真实的疲劳状态，仿真结果不能直接等同于真实表现。疲劳程度、日常工作负荷高低，以及对报警系统的不信任程度这三件事，成因和表现都不一样，必须分开测量，不能混在一起用一个笼统的分数去代表。
怎么落地
建立一组领先指标来提前预警，比如不需要任何动作的报警占报警总数的比例、同一条报警被反复重新确认的次数、响应时间的整体分布、屏蔽清单的积压情况，以及情景演练中的命中率，而不是只等真实事故发生后才复盘。具体的验证办法是在一段长时间、持续存在低价值报警的报警潮之后，突然插入一个关键的真实事件，观察操作员能不能识别出来、有没有正确排出处理优先级，以及第一步有效动作出现得够不够快。