把 MQTT 项目从可运行的 Demo 推进到生产设备群，本质上是在消除模糊地带：每台设备都要有负责人，每个主题都要有契约，每份凭据都要有生命周期，每种故障都要有处置方法。
这份清单用于评审新的 RunMQTT Broker 是否具备上线条件。建议由固件、后端、安全、支持和计费负责人共同完成，而不是由某一个团队单独勾选。
1. 限定第一批生产负载
先定义边界清晰的首批设备，而不是从最终规模倒推所有设计。
- 列出首批上线的设备型号和固件版本。
- 估算并发连接数、平均载荷大小、稳定发布速率和突发峰值。
- 标出不能丢失或重复的指令与事件。
- 写明对产品真正有影响的延迟和可用性目标。
- 明确 Broker、设备注册表、下游消费者和事故响应的负责人。
将这些假设整理为压测模型。如果容量数据仍然来自猜测，应先采集试点设备的真实流量并在预发布环境回放。
2. 固化主题与载荷契约
在批量创建设备前，先写出有代表性的发布和订阅示例。主题层级需要表达稳定的所有权和消息方向：
prod/{tenant}/{site}/{deviceId}/telemetry
prod/{tenant}/{site}/{deviceId}/state
prod/{tenant}/{site}/{deviceId}/command
记录字段、单位、时间戳、Schema 版本、最大载荷、QoS、Retain 和过期规则。加入拒绝场景测试：一台设备不能冒充另一台设备发布，也不能订阅自身前缀之外的主题。
更完整的方法见 MQTT 主题设计指南。
3. 准备安全的设备访问
设备凭据属于基础设施，不能当作表格里的普通字段管理。
- 为生产环境创建专属 Broker，不复用公共或预发布端点。
- 为每台设备或职责单一的客户端签发唯一身份。
- 只授予该身份必要的发布和订阅过滤器。
- 所有生产连接启用 TLS 并校验服务端证书。
- 设备支持时，将密钥保存在硬件安全区或受保护的应用存储中。
- 在首批设备出厂前完成轮换和吊销演练。
共享凭据会放大单台设备泄露的影响，也无法单独吊销。完整的 TLS、身份和主题授权模型见 MQTT 安全指南。
4. 演练完整消息链路
不要只验证“成功连接 Broker”，而要覆盖端到端链路：
- 使用与生产固件相同的客户端库和 TLS 设置连接；
- 按实际用途分别验证 QoS 0 和 QoS 1；
- 检查所有订阅者、转换任务、数据库、告警和看板；
- 强制断开设备，确认 Last Will 行为；
- 注入 QoS 1 重复消息，验证消费者幂等性；
- 模拟离线后重连，检查会话、重试和过期规则；
- 尝试越权主题，确认 Broker 明确拒绝。
免费公共 MQTT Broker 适合验证客户端基础连接。负载测试或接近生产的数据必须使用隔离的托管 Broker。
5. 设置运维护栏
在故障发生前建立告警，至少覆盖：
- 当前与峰值连接数；
- 连接抖动和认证失败；
- 发布速率、载荷大小与处理延迟；
- 排队和过期消息；
- 下游消费者延迟与错误率；
- Broker 健康状态和计费状态。
每条告警都要有负责人、基于负载模型的阈值和简短 Runbook。上线窗口还需明确回滚条件，以及谁有权限轮换凭据、禁用客户端或暂停发布。
6. 分批进入生产
按批次发布，避免固件或策略错误影响整个设备群。
- 先连接内部金丝雀设备。
- 观察一个完整业务周期，而不是只看几分钟流量。
- 扩展到一个小型客户或站点批次。
- 对比实际连接数、吞吐、延迟、失败率与预测。
- 达到约定阈值时自动暂停。
- 上一批稳定后再继续扩量。
为每个批次记录固件版本、策略模板、Broker 套餐和主题 Schema，这会显著降低回滚与事故分析成本。
7. 在 48 小时内复盘
上线后对比假设与真实行为，记录异常重连、噪声主题、授权拒绝、载荷增长和 Runbook 缺口，并将结论转成有负责人的工作项。
如果试点已经需要独立运行环境，可以查看 MQTT Broker 定价与套餐，或直接创建账户部署第一个托管 Broker。