职责边界不清会导致关键动作被双方都当作对方负责
别名: 责任扩散 · responsibility ambiguity · false redundancy
概念解释
职责边界不清会产生责任扩散（diffusion of responsibility）：一个关键动作看似由多人可见、多人可做，却没有写明谁是主责、谁是备责，于是每个人都可能"合理地"以为对方已经在处理，结果谁也没动手。它和真正的双人冗余覆盖不是一回事——冗余覆盖是两人都知道自己要做、只是互为备份；责任扩散是两人都不确定自己要不要做，进而都选择等待。
机制
共享告警只证明多人可见，不证明有人拥有。人在高负荷下不会逐项核对职责清单，而是依据角色脚本快速筛选"这归我管吗"；交叉区域的任务如果没有被写进任何一方的脚本，就会形成看似有人覆盖、实际无人认领的"虚假冗余"。
这个失效模式随负荷变化会翻转方向：负荷低时，两人都有余力主动确认，责任不清顶多导致两人重复处理同一件事，浪费精力但不致命；负荷升高、双方都靠脚本快速决策时，责任不清才会转为双方都跳过，因为脚本里没有这一项，谁都不会主动去补。所以责任扩散不是一种恒定的人为疏忽，而是一种在高负荷下才会显现的系统性空档，低负荷演练里往往测不出来。
另一层容易被忽略的机制是"指派"和"接受"的区别。把一个人的名字挂在某个事件旁边只是指派，指派和这个人真正接受并开始处理之间存在一段时间差；如果界面只显示指派状态、不要求显式的接受动作，指派本身就会被误当成已处理，责任扩散就发生在这段没有人确认的空档里。
怎么研究
可以在团队仿真里做一个 2×2 操纵：负荷（基线 vs. 并行次任务）× 职责显示方式（主责/备责/超时升级明确标出 vs. 只有共享告警的默认可见）。记录每次事件的首个动作时间、重复动作次数、完全无人动作的次数，以及期间的口头沟通序列。
一个更直接的检验办法是对照报警日志核算响应时间：把事件产生时间与操作日志里第一次相关操作的时间戳对齐，统计"静默期"——从告警产生到任何一方做出可辨识动作之间的间隔——并按职责显示方式分组比较静默期的分布，而不是只看平均响应时间是否达标。事件复盘时还应比较正式职责表与当时界面上实际呈现的分派状态，两者经常不一致。
边界
- 这个机制只在没有专属工位的事件上成立，比如跨越两个控制台共同覆盖的系统；单一控制台独占的告警本身职责清晰，不属于这个问题。
- 备责如果只是名义上的挂名、没有人实际盯着备责画面，正式指派并不能解决问题——备责必须配合主动监视，否则和没有备责一样。
- 超时升级的时间阈值要匹配任务节奏：定得太短，在正常沟通延迟下会触发大量误升级，反而增加负荷；定得太长，在快速恶化的事件里升级已经来不及。
- 对于发展缓慢、留有充分沟通时间的异常，责任扩散通常会在过程中被口头澄清自行化解，这个问题集中出现在起始快、边界模糊的事件上。
- 职责明确不能替代团队互相监测，也不能把系统性的空档设计问题简单归咎于某个当值操作员的疏忽。
怎么落地
- 每个跨边界的关键事件在界面上同时显示主责、备责、接管条件和当前的接受状态（而不只是指派状态），接受状态需要操作员显式确认才能置位。
- 设置与任务节奏匹配的超时升级：超过阈值仍未被接受，自动升级给上一级或广播给全体在岗人员，而不是保持沉默等待。
- 无法接受某个指派时（比如正在处理更高优先级的事件），要求显式转派而不是放任指派悬空。
- 验证办法：设计专门落在两个控制台职责交叉点上的故障演练，事后核对操作日志里是否出现"双方都在等待"或"双方都在处理、互相覆盖指令"的时间窗口，这类窗口就是职责边界设计有缺口的直接证据。