1.动机

从话单中深入统计基站/信道使用情况时，出现了性能问题，同时由于新的分析统计需求带来的bug导致网管的重启，崩溃，从而网管最核心的配置与监控功能得不到保障

2.分析

运营数据包括话单/短信记录/拜访用户/信道监控/GPS/录音/告警

从业务耦合度考虑，拜访用户需要网管和交换双向交互，其他几类都是单向输出数据

从需求的易变性考虑，对运营数据的分析统计属于易变的，不同客户都有定制的可能性

从需求的重要性考虑，运营数据要比配置与监控功能低

GPS和录音之前也是作为独立的服务设计的，从概念上将话单/短信/拜访用户/信道监控/告警都可以独立，但拜访用户和告警牵涉网管核心功能，不能简单的独立，话单/短信/信道监控逻辑上都能做到简单的独立

通过网管上集成其他运营数据的服务，对客户而言也可以做到没有变化

综合以上几点，将运营数据的查询/分析/统计模块与网管其他模块独立，对网管而言，会有更好的扩展性和稳定性，对独立出去的一个或多个运营数据服务而言，也能更加灵活部署，更加灵活开发

3.方案设计

直观的方案

缺点：耦合度大，数据仓库需要了解网管内部逻辑，例如号码编解码，各种业务属性枚举

优点：网管几乎不做改动

建议：不推荐，否则可能后患无穷

缺点：相对现状，涉及改动的设备太多，改动内容太大

优点：耦合度低，模式具有普遍性，不局限与处理运营数据，适用于各类设备与网管的所有交互

建议：现阶段不推荐，如果将来有机会进行大的重构，可以考虑发展

缺点：访问查询/统计服务时，存储的数据有冗余，输入的查询条件存在局限性。例如存储话单时，每条都要报春“用户名称”/“单位”全称，按照“单位”查询时也不能按树状结构选择

优点：耦合度低，改动量不大

建议：推荐，

4.