故障需要区分设备本身、网络与云端服务三个层面
别名: 三层归因 · 云依赖故障 · troubleshooting
概念解释
同一个「设备不工作」的症状，源头可能在三个完全不同的层面：设备本身（硬件坏了、固件卡死）、家庭网络（路由器、Wi-Fi、网关掉线）、云端服务（厂商服务器宕机、账号异常）。三层对应的处置动作互不通用——重启设备、修网络、等厂商公告——所以面向用户的故障呈现必须把层分出来，这是智能家居故障排查的第一课，通常叫故障归因（fault attribution）。
云端这一层是智能家居特有的维度，也是最难被用户想到的：远程控制、语音、联动这些「智能」本质跑在厂商服务器上，云一宕机，家里完好无损的设备也集体表现为坏。
机制
用户的归因难来自链路不可见。一次语音开灯要经过：唤醒与识别、云端解析、指令下发、网关转发、设备执行——任何一环断，到用户那里都收敛成同一个症状「没反应」。症状在末端，故障在链上，而链路对用户完全透明，于是归因只能靠猜。
猜错的代价是无效动作循环：云宕机时反复重启一台好设备、逐个重置重新配网，折腾半小时不如等十分钟。智能家居实地研究里，这种围绕错误归因展开的折腾是家庭对智能设备失去耐心的常见转折点。
更深的机制是心理所有权错位：用户把智能设备理解为「家里的物」，坏了该在家里修；但它同时是「云服务的终端」，它的失能可能来自千里之外的服务器。日常经验里没有这个类别，用户缺的不是信息而是一整个心智模型。
怎么研究
Edwards 与 Grinter 2001 年对家庭泛在计算挑战的分析已指出：家庭基础设施的不稳定与不可见，使管理负担落到居民头上。智能家居故障排查的实地与访谈研究普遍发现用户归因路径混乱——把云问题当设备问题、把信号问题当设备老化（此段按领域共识泛写）。
实验做法：给用户一组故障场景卡（设备/网络/云各若干），度量归因准确率与首选处置动作；或者在部署研究中记录真实故障后用户的行为序列，统计「无效动作」的占比。方法论注意点：真实家庭里三层故障会叠加（断网导致设备离线，同时云侧会话也超时），单一故障注入测不出叠加态下的归因行为，评估应包含复合故障场景。
边界
- 三层是用户侧模型，不是完整技术拓扑。 链路上还有 Zigbee/Thread 子网、集线器、账号授权等更多环节，但面向用户呈现三层已是上限——再细就变成把系统内部结构倒给用户。
- 复合故障要呈现「最先失效的层」。 断网时设备离线与云超时同时出现，提示应指向根因层，否则用户会逐层修一遍。
- 云层的可诊断性受厂商透明度限制。 云状态页不总是实时准确，账号问题与云宕机在用户端症状相同；能做到的是「明确告知云侧异常、排除用户侧责任」，而非精确定位。
怎么落地
- 诊断入口按三层提供自检分支：设备本地是否响应（看指示灯/按物理键）、网关是否可达、云服务状态是否正常，一步步排。
- 故障提示文案带层标注：「设备离线」（设备/链路）与「服务中断」（云）是两种不同的提示，不要都写成「无法连接」。
- 云宕机时全局统一提示一次，而不是每个设备各报一遍错——几十个相同的错误卡片会把云问题伪装成全屋设备集体故障。
- 验证办法：分别制造三层故障——拔设备电源、断路由器、用防火墙拦截云端域名——逐一检查提示是否指向正确层；再制造复合故障（断网），检查提示是否归到网络层而非设备层。