简要回答

有用的架构审查不仅仅是确认架构图中有设备、代理、存储和应用。它使身份、降级行为、数据契约、租户边界、发布安全、可观测性、恢复和业务归属变得明确。此清单为跨职能团队提供十个提示来引导这场对话。

勾选每一项并不认证架构。勾选意味着团队已审查该控制项并能指出当前证据。如果证据是一个未来的工单、一个未测试的假设或某人的记忆，请保持该项未勾选并指定负责人。

各控制项的含义

十项控制覆盖不同的系统边界：

  1. **受管身份：**每台设备可以被认证、轮换、吊销和追踪，而不将共享密钥当作身份。
  2. **离线行为：**产品和运维团队就设备在连接、时间、存储或依赖降级时的行为达成一致。
  3. **版本化消息契约：**生产者和消费者可以演进，而不会静默地重新解释同一载荷。
  4. **租户隔离：**身份、授权、主题、存储、缓存、日志和支持工具保持边界。
  5. **数据留存：**原始遥测和持久业务事件有不同的用途、归属和留存策略。
  6. **安全 OTA：**发布使用分阶段队列、兼容性门控、健康信号、暂停标准和经测试的恢复。
  7. **恢复可观测性：**运维人员可以看到积压、错误率、饱和度和服务恢复时间。
  8. **密钥生命周期：**凭据可以在设备群规模下签发、轮换、吊销、审计和恢复。
  9. **故障恢复：**设计经过了代表性故障演练的考验，而非仅限于正常路径的负载测试。
  10. **业务闭环：**告警和自动化动作最终由负责的归属人和可观测的结果收尾。

评分方式

百分比简单为：

已勾选控制项 ÷ 10 × 100

所有控制项权重相等。这是刻意的：分数报告审查完成度，而非风险严重程度。一项缺失的设备身份控制可能比几项已完成的文档控制更重要。将结果用作议程和证据索引，绝不用作审批阈值。

示例分析

假设一个团队将身份、消息契约、租户隔离、留存、密钥生命周期和业务闭环标记为完成。结果是 60% 证据：六项已勾选，四项仍未完成。缺失的是离线行为、OTA 恢复、恢复可观测性和恢复测试。

有成效的下一步不是机械地追求 100%。团队应为每个缺口附加负责人和证据要求。固件团队可以负责编制离线状态机文档；发布工程可以负责回滚证据；运维可以定义恢复仪表盘；平台团队可以执行重连和积压排空演练。下次审查应检查这些工件，而非仅仅重新勾选。

清单的局限

这不是威胁模型、安全论证、隐私评估、合规审计、详细设计审查或渗透测试。它不考虑产品特定风险、区域法规义务、无线电认证、制造控制、物理访问、供应链风险或组织能力。等权重意味着百分比不可跨产品比较或用作成熟度基准。

使证据适应系统。一个电池传感器、工业网关、联网车辆和医疗设备即使控制标签看起来相似，也要求非常不同的深度。

隐私与可携带结果

检查清单完全在页面中运行。勾选状态编码为当前 URL 中的简单 item 标志，使审查状态可以重新打开或分享。URL 不包含备注、证据、凭据或上传文件，因为工具不收集这些内容。不过，已完成的控制模式在某些组织中可能敏感，请仅与目标受众分享链接。

复制和 JSON、CSV 或 Markdown 导出均在本地完成。不发送任何数据到 IoT 01。

常见问题

100% 意味着架构已就绪吗？

不。它意味着每个提示都被标记为完成。批准需要可信的证据、产品特定的风险分析和至少一次真实的故障演练。

谁应参加审查？

包括产品、固件、硬件（如相关）、平台、安全、数据、运维、支持以及受设备行为影响的业务流程归属人。

每个团队都应使用相同的证据吗？

不。保持问题足够稳定以便比较审查轮次，但使证据与产品的风险、规模、生命周期和合规环境相称。

相关指南

阅读设计设备运维闭环以将遥测、决策、动作、确认和归属结果贯穿架构的各个层面。