网管职责重构（2014年）
一. 分离职责, 海阔天空
1. 网管职责
职责: 面向客户, 包括设备接入/业务配置/运营状态/运营数据
包袱: 数据存储代理/工程与开发配置
2. 通用数据存储代理服务
职责: 面向不直接支持访问标准数据库的平台(VXWORK), 提供访问代理.
概念: 数据库/表/表结构/表数据/命令(增删改查)与参数
分类: 公共数据库/私有数据库
3. 通用设备访问协议与工具
职责: 面向工程人员/开发人员, 提供与具体业务无关的设备访问工具
概念: 设备自呈现/项/元数据/键值对/表/命令与参数/消息/工程与开发权限
通信: 工具->设备(同步异步), 设备->工具(异步)
范围: 所有设备/服务都需要实现, 通信模块是开发平台(VXWORK / WINDOW .NET / LINUX C++ / LINUX JAVA / LINUX .NET)内部通用的, 与项目无关, 与设备无关, 各个具体设备/服务只需要自定义待配置的内容
实施: 网管上以及其他配置工具上, 用户看不懂的都可以去掉, 使用这种通用工具配置, 工程人员视图关心依赖客户实际环境的配置, 开发人员视图关心具体模块/对象的状态.
大部分开发人员都区分不好客户视图(多角色)/工程视图/开发视图, 需要在实践中领悟.
(上图是键值对型数据)
(上图是表型数据)
二. 面向客户的业务, 以不变应万变
1. 设备接入
概念: 所有设备信息都在这
鉴权通过后, 其他设备可以获得所有关联设备的IP等配置信息. 例如GIS服务器以前需要BGW地址/域名, 现在需要配置主备SSU地址/域名, 其实只需要配置网管地址, 域名都不要知道, 通过网管接入后, 可以查询到想要的信息, 这样的初始化流程就会很稳定/通用.
2. 业务配置
原则: 站在客户角度看问题, 制定通用网管协议
网管不需要为特定某个设备的制定专门的协议, 只要面向(客户)业务制定, 例如”通话限时”, 其他设备如果需要这个业务参数, 那么主动向网管获取和订阅, 网管无需关心是哪类/哪个设备用到, 网管更无需关心具体实现”通话限时”时, 交换-基站-终端之间是什么协议与通信方式. 这样的设计在逻辑上去除了业务(接口)和系统设计(实现)的耦合, 除了更能适应变化, 还会简化网管与设备间接口, 提升通用性, 也直接支持离线配置.
3. 运营状态
透视: 告警只是状态的一部分, 制定设备的当前健康状态/告警的通用接口
网管需要显示业务/设备的状态, 大部分人认为状态就是告警, 这个误区其实很严重, 这里不做探讨. 和第2点类似, 运营状态中的设备的当前健康状态/告警是可以通用的, 可以面向所有接入设备.
4. 运营数据
方法: 以界面控件作为通用接口
网管上直接拥有的信息只有设备接入/告警/状态变迁, 话单/录音/GIS/勤务/短信之类的信息需要通过相应的应用服务器提供, 使用界面控件的方式直接集成到网管是最理想的方式.
三. 网管之外, 融会贯通
1. 应用中心, 成为正规军
软件下载/更新门户: 提供首次下载界面, 提供各设备的自动更新服务(也可以支持设备)
客户端: 调度台/网管客户端/勤务客户端
网管服务器:
应用服务器: 话单/录音/GIS/勤务/调度
服务管理器: 服务本身是没有界面的, 定制一个管理界面方便很多, 可以查看网管服务器/应用服务器, 甚至其他核心网设备服务是否运行, 以及自动检测并重启
(上图是软件下载/更新门户示例)
(上图是服务管理器示例)
2. 统一客户端平台, 任重道远
方法: 依赖于权限的插件化软件
依据不同的权限, 显示不同的界面, 但界面整体框架是一致的, 这样易用性较好.
另一方面, 小公司尽量不要重复造轮子, 开发成本高, 维护成本高, 对具体开发人员依赖性强, 应该尽量复用, 持续重构, 打造精品, 精益求精.
B/S架构的方式下, 部分功能无法实现, 特别是需要依赖第三方硬件的地方. 集群系统属于企业内部应用, 不是必须使用B/S网站方式部署应用, 使用可自由扩展/支持自动更新的C/S架构方式也很合适.
悲剧的是, 对应用软件的交互流程/界面设计, 公司的”专家”太多, 意见太多!!!
3. 每套设备标配路由器, 点石成金
如果标配一个路由器, 部署在机房中的公司内部的成套的其他所有设备都必须接入该路由器, 内部所有设备的IP和端口都可以固定不变(或是区间不变), 例如网管固定成192.168.0.1,
交换固定使用192.168.0.2, 等等, 这样的好处是和在别的厂商联调时, 部署到客户现场环境时, 所有对外互联都只要配置一下路由器的外部地址和端口就行. 网管开局时, 设备接入可以使用大量的默认配置就行了, 这样可以节约大量配置时间, 也不容易出错. 如果路由器能支持端口镜像, 那么直接可以抓取路由器内外的所有数据包, 保留原始的证据, 配合定制的解包工具(通用性也是很强的), 对诊断问题的效率影响, 或许是自行车和地铁的差距, 对诊断问题的可信度和准确性也有很大的提高. 如果路由器支持WIFI, 通过笔记本临时部署/调试也方便很多.
四. 总结
文中多次提到”通用”二字, 因为采用以应用为导向的抽象思路, 所以易扩展/易复用. 设计上, 整体逻辑清晰, 简洁. 效益上, 应用的时间越长, 效益越高.
后话:
如果过渡到LINUX系统, 如果都是以面向对象的设计为基础, 应用软件(客户端/服务器)开发与交换机服务开发, 在软件设计上, 相互交流和借鉴的空间很大. 希望能做到更多的”通用”
