物联网平台私有化部署指南：边界、安全、备份与上线验收
一句话结论：私有化部署的核心不是“把平台装进自己的机房”，而是从上线第一天起，可用性、数据安全和升级责任全部由自己承担。 团队能接受这份责任并配齐备份、监控和演练，私有化就带来完全的数据主权与定制自由；做不到，再低的授权费也会在后期变成事故成本。
本文只讨论实施与运营决策：部署边界、形态选择、安全、备份、升级、运维成本与验收。版本与授权怎么选属于另一个问题，请阅读商业版与集群版选型指南，本文不再重复。
1. 先划清私有化部署的边界
“私有化部署”在采购沟通中常被当成一个词，实际包含三种差别很大的形态：
| 形态 | 基础设施归谁 | 运维责任 | 典型场景 |
|---|---|---|---|
| 本地机房（On-Premises） | 自购服务器与网络 | 硬件、系统、平台全部自担 | 数据不出内网、合规强约束 |
| 私有云 / 专有云 | 云厂商提供资源池 | 平台与系统自担，硬件由云承担 | 集团统一资源池 |
| 公有云 VPC 自建 | 租用云主机与网络 | 平台与系统自担，底层硬件由云承担 | 需要弹性但不用托管 IoT 服务 |
选择前先把四类边界问题写成书面答案：数据是否允许出域、断开外网时系统是否必须继续运行、等保或行业合规的审计要求、客户合同里对部署位置的承诺。这些答案决定后面所有架构选择。
同样重要的是反向边界：私有化部署不等于自建一切。操作系统补丁、数据库、消息中间件、反向代理都应使用成熟组件，FastBee 的部署文档也是按 JDK、MySQL、Redis、EMQX、Nginx 这类标准组件组织的（见物联网系统部署）。把人力留给业务逻辑，而不是重复造基础设施。
2. 选择部署形态：Docker 验证、单机生产、集群扩展
形态决策建议按“验证 → 生产 → 扩展”三步走，而不是一步到位上集群。
- 验证期：目标是跑通业务流程，不是追求性能。开源版可用 Docker 一键部署，或按系统部署手工装齐组件；商业版可用快速部署。
- 生产期（单机）：中小项目按物联网系统部署部署后端、前端与 Nginx，各组件按需参考 MySQL 安装、Redis 安装、EMQX 安装、Nginx 安装、时序数据库安装与启用等分篇。单机生产的前提是做过压测与故障演练（见第 4、7 节）。
- 扩展期（集群）：当单节点容量或可用性不再满足目标，再评估集群路径：FMQ 集群部署、Kafka 安装、集群负载均衡。集群带来的是运维复杂度，不是免费的容量；团队没有相应能力时，宁可在单机上调优。
无论哪种形态，都先在测试环境完整走一遍安装，再进生产。FastBee 提供本地运行与可视化用于在本机验证集群链路，“先在本地复现”的习惯能省掉大量上线事故。
3. 安全基线：把“内网”当成需要证明的假设
私有化环境最常见的安全错觉是“我们在内网，所以没事”。内网里同样有弱口令、越权访问和被入侵的办公终端。上线前至少落实：
- 入口收敛：只暴露必要端口，管理后台、Broker 管理口、数据库一律不对公网开放；必须远程运维时走 VPN 或跳板机。
- 传输加密：MQTT over TLS 与 HTTPS 证书启用并记录到期时间，内部组件之间的认证凭据单独管理。
- 凭据管理：改掉所有默认账号密码，EMQX/FMQ、MySQL、Redis、Nginx 的凭据分开保存，纳入人员离职回收流程。
- 漏洞响应：订阅所用组件的安全公告，把补丁窗口写进运维计划；FastBee 自身的修复节奏可参考系统漏洞修复说明。
更系统的分层做法见物联网平台安全防护的六个层次。安全项要进入验收清单（第 7 节），一次性检查不算完成，需要定期复查。
4. 备份策略：先确定要恢复什么，再决定怎么备
备份方案从恢复目标倒推。先和业务确认两个数：RPO（最多允许丢多久的数据）与 RTO（最长允许停机多久），再盘点一套 FastBee 部署里的数据资产：
| 数据资产 | 内容 | 备份要点 |
|---|---|---|
| MySQL | 设备档案、用户、规则、告警等业务数据 | 定期全量加必要的增量，异机存放 |
| 时序数据库 | 设备历史上报数据（启用 TDengine 时） | 数据量大，按保留周期评估快照或导出策略 |
| Redis | 缓存与临时状态 | 通常可不备，但要知道丢缓存后的重建影响 |
| Broker 配置 | EMQX/FMQ 的认证、ACL 与规则配置 | 配置文件纳入版本管理 |
| 上传文件与站点配置 | 平台上传的文件、Nginx 配置、证书 | 与数据库同周期备份，记录恢复步骤 |
三条硬性要求：
- 备份必须异机或异地：与生产库放在同一台机器上的备份，会在磁盘故障时一起消失。
- 定期恢复演练：没有成功恢复过的备份不算备份；演练要计时，结果与 RTO 对比。
- 升级前必做全量备份：这是回滚的前提（见第 5 节）。
5. 升级与回滚：把每次升级当成一次小发布
私有化平台没有“自动更新”这回事，每次升级都是自己执行的一次发布。FastBee 商业版的升级指南给出了升级前准备、升级顺序、SQL 脚本、Docker 部署升级、缓存与时序库处理、升级后验收与回滚策略，建议直接把它作为升级 SOP 的骨架。要点：
- 先在测试环境用生产数据副本完整演练一次升级；
- 按官方顺序升级组件，SQL 脚本逐个执行并留存执行记录；
- 升级后按清单验收：登录、设备在线、上报入库、规则触发、告警、可视化逐项确认；
- 回滚方案提前写好：回滚 = 恢复备份 + 切回旧版本，前提是第 4 节的备份真实可用。
跳过测试环境直接升生产，是私有化项目最常见的自我伤害。
6. 运维成本：人力账单比服务器账单更难估
私有化的真实成本主要在人。以一套单节点生产系统为例，持续的运维工作包括：
- 每日巡检：服务状态、磁盘、数据库、消息积压。FastBee 的运维监控给出了每日巡检清单、常用命令和平台内运维入口，可直接复用。
- 容量观察：CPU、内存、磁盘趋势，连接数与吞吐和压测基线对比（压测方法与指标见商业版压测报告）。
- 安全维护：补丁、证书续期、账号审计。
- 备份与恢复演练：按第 4 节执行并记录。
- 升级执行与故障响应：升级每年若干次，故障响应需要明确的值班或响应约定。
预算建议：至少一名能同时处理 Linux、数据库和 Java 应用的运维或开发角色承担主责，并指定备份责任人，避免“只有一个人懂”的单点。做三年总成本对比时，把这部分人力与服务器、带宽、存储一起算，对比方法可参考选型指南的总成本一节。
7. 上线验收清单
| 验收项 | 通过标准示例 | 证据 |
|---|---|---|
| 功能闭环 | 设备接入、上报、规则、告警、可视化全链路用真实设备验证通过 | 测试记录 |
| 容量 | 峰值模型下连接、吞吐、时延达标且有资源余量 | 压测原始数据 |
| 备份恢复 | 演练恢复到备用环境成功，耗时满足 RTO | 演练记录与计时 |
| 高可用（集群时） | 节点故障后业务在目标时间内恢复 | 故障注入记录 |
| 安全 | 端口扫描、弱口令检查、TLS 与凭据核查通过 | 检查报告 |
| 升级与回滚 | 测试环境完成一次升级加回滚演练 | SOP 与执行记录 |
| 运维交接 | 巡检、告警、备份、升级都有人认领并实操过 | 交接文档与实操记录 |
验收标准在上线前定死，不要看到结果后临时放宽。
8. 推荐的实施顺序
- 确认部署边界与合规要求（第 1 节）；
- 用 Docker 或单机完成验证环境，跑通业务流程；
- 按真实设备与峰值模型压测，确定单机或集群形态；
- 落实安全基线与备份策略，完成一次恢复演练；
- 在测试环境完成一次升级与回滚演练；
- 按第 7 节清单验收，完成运维交接后上线。
9. 常见问题
9.1. 私有化部署最少需要多少人运维？
单节点生产系统至少需要一名能覆盖 Linux、数据库与应用的主责运维，并指定备份责任人。集群形态还需要 Kafka、负载均衡与 Broker 集群经验，人力要求明显更高。
9.2. 开源版可以直接用于生产吗？
技术上可行，但开源版按官方清单为 AGPL 3.0 非商业用途。商业项目应先解决授权合规，再谈部署形态，详见授权说明与版本选型指南。
9.3. 没有专职运维团队怎么办？
优先单机形态加 Docker 简化部署，把巡检、备份做成脚本和定时任务，必要时购买部署支持与运维服务；不要在没人具备集群经验的情况下上集群。
9.4. 私有化部署后还能获得官方更新吗？
商业授权包含首年源码更新，后续按订阅方式获取。每次更新仍需自己按第 5 节的流程执行升级与验收——私有化环境下不存在自动升级。