Z7.02.1Layered fault localization设计研究
故障可能在设备、网络或规则的任一层
别名: 分层故障定位 · 设备-网络-规则三层 · layered troubleshooting
概念解释
智能环境的每一次自动化，都跑在一条串行的分层链路上：设备层（传感器与执行器的硬件工作正常吗）、网络层（消息传得过去吗）、规则层（逻辑判断有没有触发）。同一句「灯没有按时关」，可能由任何一层造成——诊断的第一步不是修，而是先确定层。
把故障先归层，是这个领域排查方法的地基。IT 运维里的分层排查（layered troubleshooting）传统由来已久：从物理连通到应用逻辑逐层隔离。智能环境把这条经验搬进家庭，并新增了一个传统网络没有的层——规则层：用户自己配置的条件逻辑，它会坏在没有任何报错的地方。
机制
为什么症状不能直接指出层？因为链路是串行依赖的：任何一环断掉，下游的表现都相同——动作没发生。症状是链路末端的输出缺失，它天然掩盖上游原因。
三层的故障各有面孔，但面孔之间有重叠：
- 设备层最有物理线索：设备完全不响应、指示灯异常、电池耗尽——但「设备在线却不执行」也可能是网络丢包。
- 网络层最狡猾：故障常是间歇性的（信号边缘、拥塞、漫游），症状时有时无，重启后「莫名」好转，最难与另两层区分。
- 规则层是自动化系统特有的盲区：它的故障是静默的——条件写错永不为真、被另一条规则的结果覆盖、时区或单位错位。没有报错，没有物理线索，只有「没触发」这一个否定性症状。
层间还会互相伪装：电源是跨层公共因子（断电看起来像网络故障）；规则高频触发会耗尽电池供电的设备（规则层原因呈现为设备层故障）。不归层就动手，等于在错误的楼层找钥匙。
怎么研究
- 家庭现实挑战清单：Edwards 与 Grinter 对泛在计算进入家庭的经典分析，把「故障发生时谁负责排查」列为实验室原型不会遇到、家庭现实必然遇到的问题——故障的跨层性正是责任不清的技术根源。
- 排查策略访谈：智能家居实地研究里请用户复盘故障排查过程，稳定看到的是从「症状」直接跳到「重启/更换/放弃」的行动，缺少中间的归层步骤——这既说明了故障为什么难定位，也预示了诊断工具的缺失。
- 故障注入：在受控部署里分别在三层注入故障（断设备、断网、改坏规则），度量用户定位到正确层的比例、耗时与错误归因率。这是把「归层」当因变量的直接范式。
方法论注意点：三层故障在实验室注入时容易区分（条件干净），真实家庭里故障常是多层的（断电同时打断设备与网络）；只用单层注入得出的「用户能定位」结论会系统性偏乐观。
边界
- 三层是家用自动化的常用切分，不是普适真理。 生态更复杂时，云端服务值得独立成层（远程规则执行与语音入口依赖它）；切分粒度应跟着故障责任边界走，而不是照搬清单。
- 用户可自查的层有限。 设备层的物理检查、网络层的简单连通（手机连同一网络能否控制）可以交给用户；规则层没有任何物理线索，必须由产品提供触发记录，否则对用户就是永久黑箱。
- 归层不能自动化到底。 系统可以提示「疑似网络层」，但把归层做成自动裁决会剥夺用户核对的机会——误判的自动归层比不归层更难纠正。
怎么落地
- 把「动作没发生」的排查路径固化为按层顺序的三问：设备在线吗 → 本地网络通吗 → 规则最近触发过吗。每问配一个可点的自检入口，而不是让用户自己想到。
- 规则层必须留触发日志（命中了什么条件、何时），它是三层中唯一没有物理线索的层。
- 记录跨层事件以便识别伪装：设备离线时刻与规则触发时刻放在同一时间线上，电池供电设备的「无故」离线要能关联到其参与的高频规则。
- 验证办法：故障注入演练三层各注入一次，统计用户定位正确层的比例与耗时；上线分诊向导前后各测一轮。定位率不升，说明排查路径没有真正按层组织。