平台功能清单与优先级规划

日期：2026-04-06

1. 文档目的

本文档用于重新梳理当前平台的功能全貌，并给出下一阶段应重点加强和持续完善的方向。

目标不是重复描述“系统做过什么”，而是明确三件事：

1. 当前平台已经具备哪些正式能力
2. 哪些能力已成型，哪些能力还需要继续加固
3. 后续资源应该优先投入到哪里，避免功能分散扩张

2. 平台定位

当前平台的核心定位应统一为：

公寓宽带计费、业务下发、智能管理平台

平台不是单一的计费系统，也不是单一的 TR069 工具，而是围绕以下业务对象构建的一体化系统：

• 宽带账号
• 套餐
• 订单
• 在线会话
• 设备
• 区域
• 现场网关 / NAS
• 微码 / 扫码入口
• 用户续费行为

这意味着后续规划必须围绕“业务闭环”和“稳定交付”展开，而不是只按协议模块拆散推进。

3. 功能清单总览

3.1 计费与认证域

当前已具备的能力：

• RADIUS Access-Request 认证
• Accounting-Start / Interim-Update / Acct-Stop 记账
• 在线会话维护与离线归档
• 流量、时长、配额扣减
• 配额耗尽自动断线
• RADIUS 日志与数据库核验工具

当前判断：

• 这是平台最成熟的业务底座之一
• 已具备长期承载正式业务的基础

仍需加强：

• 与订单、续费、设备状态的联动收口
• 多现场、多 NAS 条件下的数据口径统一
• 计费异常、补偿、追账场景的规则化

3.2 NAS / iKuai 运维域

当前已具备的能力：

• NAS 设备信息维护
• iKuai 接口参数管理
• PPP 在线会话查询
• PPP 用户踢线
• VPN 账号与网关边界接入配合
• 区域维度 NAS 与接入资源统计

当前判断：

• 已达到真实现场可操作水平
• 是平台当前最直接的运维抓手之一

仍需加强：

• 厂商识别与设备建模标准化
• 设备健康状态、连通性、接口异常的统一看板
• 批量运维动作与审计能力

3.3 TR069 设备纳管与业务编排域

当前已具备的能力：

• CWMP 入口与 Inform 入库
• 设备列表、详情、事件、参数快照
• 模板任务下发
• WiFi 修改、重启、下载、参数读取
• 手动 Connection Request
• 自动初始化、自动回读、自愈基础能力
• 多品牌兼容框架基础

当前判断：

• 这是平台最有差异化价值的能力域
• 已进入真实可用阶段，但工程复杂度最高

仍需加强：

• 统一真实执行链路
• 任务生命周期、错误分类、超时恢复标准化
• 失败持久化重试、进程重启后恢复
• 多品牌兼容维护成本控制
• 批量巡检、参数漂移、异常归因能力

3.4 前台扫码、绑定与续费域

当前已具备的能力：

• 微码扫码识别
• 装维绑定设备与宽带账号
• 设备状态与 WiFi 信息查询
• 套餐选择与支付入口
• 续费结果反馈

当前判断：

• 已形成用户入口和装维入口雏形
• 对平台闭环价值很大，但当前更偏“主流程可用”，还不够“产品稳定”

仍需加强：

• 绑定、支付、恢复链路的异常兜底
• 到期提醒、欠费提醒、续费成功恢复的自动联动
• 正式前台入口收敛，避免多套前台并行演化
• 前后台状态口径一致

3.5 业务对象与后台工作台域

当前已具备的能力：

• 宽带账号管理
• 套餐管理
• 订单管理
• 区域管理
• 微码管理
• 设备管理
• 任务与模板管理
• 基础日志与统计入口

当前判断：

• 功能面已较全
• 问题不在“没有页面”，而在“对象之间联动不够强”

仍需加强：

• 房间 / 住户 / 账号 / 套餐 / 订单 / 设备的一致性联动
• 面向客服、装维、运营三类角色的工作台重组
• 更清晰的区域运营视角与异常视角

3.6 部署、监控与平台治理域

当前已具备的能力：

• Go 后端构建与运行基础
• 前端静态构建能力
• VPS 部署路径
• MySQL / Redis / Nginx / systemd 基础依赖说明
• 健康检查基础入口

当前判断：

• 已具备上线基础
• 但离长期稳定运营还差治理体系

仍需加强：

• 多环境配置管理
• 密钥、证书、支付配置治理
• 监控、日志聚合、告警体系
• 发布、回滚、备份恢复标准化

4. 功能成熟度分层

4.1 已成型能力

• RADIUS 计费认证主链路
• NAS / iKuai 运维主链路
• TR069 基础纳管与下发主链路
• 微码绑定与基础续费入口
• 后端与前端基础部署能力

这些能力说明平台已经越过“能不能做出来”的阶段。

4.2 可用但需继续加固的能力

• TR069 调度可靠性与异常恢复
• 多品牌兼容扩展与映射治理
• 前台支付与恢复链路稳定性
• 运维工作台体验与状态表达一致性
• 区域运营与现场诊断视角

这些能力已经能用，但还不足以支撑低风险规模复制。

4.3 下一阶段重点建设能力

• 账号、订单、设备、续费、限制、恢复的一体化闭环
• 批量运营与异常巡检
• 安全与运维治理体系
• 交付 SOP 与现场复制标准化

这些能力将决定平台是继续停留在“项目型系统”，还是走向“产品型平台”。

5. 优先级规划

P0：必须优先投入

P0-1 TR069 工程化加固

投入原因：

• 价值最高，复杂度也最高
• 当前已经可用，但最容易成为后续维护瓶颈
• 一旦不收口，新增品牌、模板、动作时复杂度会持续失控

重点建设项：

• 统一执行链路
• 统一任务状态机与错误分类
• 超时、重试、恢复、补偿机制
• 调度器可靠性和任务持久化治理
• 自动回读、自愈、写后校验链路一致化

预期效果：

• 降低 TR069 长期维护成本
• 提升现场纳管成功率和任务成功率
• 为多品牌扩展建立稳定底座

P0-2 业务闭环主流程收口

投入原因：

• 当前对象很多，但主流程还没有完全产品化
• 如果账号、订单、设备、续费不能联动，平台就还是“功能集合”

重点建设项：

• 新装绑定后的自动初始化
• 欠费限制策略标准化
• 续费成功后的自动恢复策略
• 账号、套餐、订单、设备、微码状态联动
• 前后台统一业务状态表达

预期效果：

• 平台从可操作系统走向标准业务系统
• 减少人工补操作和跨模块确认成本

P0-3 安全与运维治理

投入原因：

• 当前已具备上线能力，但治理能力偏弱
• 后续规模放大后，这一块最容易暴露系统性风险

重点建设项：

• 配置、密钥、证书治理
• 多环境隔离与发布规范
• 监控、告警、健康检查、日志聚合
• 备份恢复与回滚方案

预期效果：

• 提升线上稳定性
• 降低生产事故带来的整体风险

P1：应紧随推进

P1-1 批量运营与异常巡检

重点建设项：

• 批量任务稳定化
• 离线设备识别与清理策略
• 参数漂移检测
• 批量审计与异常归因
• 区域维度运维巡检看板

优先级说明：

• 这块直接关系到平台能否支撑更多设备和更多现场
• 但前提是 P0 中 TR069 可靠性和业务状态链要先稳定

P1-2 后台工作台重组

重点建设项：

• 面向客服的订单、欠费、恢复工作台
• 面向装维的绑定、纳管、初始化工作台
• 面向运营的区域、续费、在线率、异常率工作台

优先级说明：

• 当前后台“模块齐”，但“角色入口不够清晰”
• 后续不应继续按功能页面堆叠，而应按业务角色重组

P1-3 前台正式入口收敛

重点建设项：

• 统一正式前台形态
• 加固扫码、绑定、支付、恢复状态链路
• 做好到期提醒、状态查询、结果反馈

优先级说明：

• 前台有价值，但不应先投入在视觉扩张或多版本并行
• 应先确保它是稳定、唯一、可持续迭代的业务入口

P2：中期完善项

P2-1 现场交付标准化

重点建设项：

• 不同品牌 ONU 接入 SOP
• 网络诊断清单
• 交付验收清单
• 常见故障处理手册
• 直改 ACS 与劫持接管的切换标准

P2-2 数据与报表产品化

重点建设项：

• 区域经营数据沉淀
• 用户续费、留存、到期分布分析
• 设备在线率、初始化成功率、恢复成功率报表
• 运营趋势与异常趋势可视化

P2-3 多品牌复制扩展

重点建设项：

• 沿兼容框架逐步补品牌，不继续堆型号特判
• 固化兼容指纹、能力探测、映射生成、校验回读流程

优先级说明：

• 这部分很重要，但必须建立在 P0 已经收口的工程基础上
• 否则会把 TR069 复杂度进一步放大

6. 不建议当前优先投入的方向

当前不建议优先做的事情包括：

• 单纯为了展示而继续扩官网或宣传页
• 在工程基础未收口前继续大面积铺新品牌
• 继续按“哪个模块缺个页面就补个页面”的方式扩张
• 在业务闭环未明确前过早做重型 BI 或复杂经营策略系统

原因很简单：

• 当前平台的主要矛盾不是“缺几个新功能”
• 而是“已有能力如何收口为可稳定交付的标准平台”

7. 建议的推进顺序

建议按以下顺序推进下一阶段工作：

1. 先做 TR069 工程化加固、安全运维治理、业务主流程收口
2. 再做批量运营、工作台重组、前台正式入口收敛
3. 最后做交付标准化、报表产品化、多品牌规模复制

这条顺序的核心原则是：

先做稳，再做通，最后做大。

8. 最终结论

当前平台已经具备明确价值，也已经形成较完整的能力骨架。

下一阶段不应继续纠结于是否还要证明“平台能不能做”，而应集中投入以下主线：

• 把 TR069 从“真实可用”推进到“稳定可交付”
• 把业务对象从“功能并列”推进到“主流程闭环”
• 把部署运行从“可以上线”推进到“可长期治理”
• 把现场经验从“个人能力”推进到“标准化复制能力”

如果后续资源投入方向正确，这个平台具备从当前可用系统继续演进为正式产品平台的基础。