可操作性应在报警设计阶段解决而非事后逐条修补
别名: 报警设计生命周期 · alarm lifecycle · alarm rationalization
概念解释
可操作性前置指把每一条报警当成一项风险控制功能来设计——在投运之前就同时定义清楚它的触发条件、后果、可用响应窗口、责任岗位和验证方式，而不是等系统上线、操作员投诉某条报警看不懂，再逐条去改文字。这属于报警生命周期（alarm lifecycle）里报警合理化（alarm rationalization）阶段的工程工作。这条讨论的是"在哪个阶段解决"这件事本身，具体消息该怎么写、响应窗口够不够、文字含不含糊，分别是同组其他三叶各自的内容。
机制
事后修补天生只能看到已经触发过、被人投诉过的那部分报警，看不到从未触发过的报警、被拆成好几条却互为因果的重复逻辑，也看不到多个报警共享同一个上游故障的系统性依赖。而且事后最常见的修补手段是给某条烦人的报警加静音或降优先级，这个动作会改变整个报警系统在报警潮期间的行为，但决策依据往往只是这一条报警本身，没人回头核对对整体的影响。在设计阶段从危害场景和操作员实际要执行的任务出发去推导，才能判断这个信号究竟应该做成一条人工报警、一套自动联锁，还是压根不需要特别呈现的普通状态量。
边界
前置设计不可能穷尽运行期才会出现的新工艺状态和此前未知的故障模式，所以运行期的性能监测和变更管理仍然是必要的补充，不能指望一次合理化评审就永久管住报警质量。前置设计也不意味着每一条报警都要单独走一遍完整流程——同类设备、同类故障模式可以复用同一套判定逻辑；把它做成僵化的一次性签字仪式，反而会让评审流于形式，起不到应有的作用。
怎么落地
在设计评审环节要求每一条候选报警必须能回答：对应什么场景、需要什么动作、可用窗口有多长、谁负责响应、优先级依据是什么、用什么方法测试验证——任何一项答不出来的候选项，都不允许进入实时报警通道。投运之后定期用真实报警日志核对当初的假设是否成立，比如实际响应时间是否落在预期窗口内；发现不成立就走受控变更流程去调整，而不是私下改一下文案就算了事。