屏蔽状态需可见且需复核
别名: 屏蔽可见性 · suppression audit · shelving register
概念解释
屏蔽状态可见指的是把当前所有没有进入实时报警通道的规则——它们对应的对象、被屏蔽的理由和预计到期时间——作为一等运行状态直接展示给操作员，而不是只藏在配置菜单里。这条讨论的是"团队怎么知道有哪些东西被拿掉了、要不要拿回来"这个总体可见性和复核机制问题，跟同组前两叶各自讨论的"什么时候该自动抑制"和"人工屏蔽本身该怎么加期限和理由"是不同层面的问题——没有这一层，前两叶再规范也没用，因为没人会去看。
机制
一旦某条报警被屏蔽，它实际上改变了整套系统的监测覆盖边界，这件事必须和其他态势信息一样进入团队的共同认知，尤其要进入班次交接的内容，否则接班的人是在一个覆盖范围已经缩水、自己却不知道的系统上工作。复核则是另一件事：定期检查当初批准屏蔽时依据的运行模式、理由和替代保护措施是不是还站得住脚。如果屏蔽信息只出现在设置菜单的某个二级页面里，没有配置权限、平时不进那个页面的人根本无从判断当前系统承担了多大的风险。
边界
把完整的屏蔽清单原样铺在主界面上也会带来新问题——清单一旦变长，持续占据显著位置反而会跟真正的活动报警抢注意力，造成新的噪声。可行的做法是分层展示：屏蔽总数和风险最高的几项应该常驻在总览里，具体明细可以点进去查；涉及安全联锁或权限敏感的屏蔽信息可以按角色控制查看范围，但不能做到让实际承担风险责任的人反而看不到这些信息，这条底线不能因为分层设计而被突破。
怎么落地
在系统设计上把"当前没有任何屏蔽"和"屏蔽清单读取失败、拿不到数据"设计成两个不同的、明确区分的状态，绝不能让后者在界面上退化成看起来和前者一样的空列表，那会让人误以为系统很干净。总览界面固定展示屏蔽总数、当前风险最高的一项、最早即将到期的一项，以及有没有出现异常的反复续期。细节页面则记录是谁、什么时候批准、基于什么理由、配了什么补偿措施。每班次交接时至少核对一遍关键屏蔽项，并定期专门审计到期未处理、反复续期和长期未修复根因这三类异常模式。