1.动机
从话单中深入统计基站/信道使用情况时，出现了性能问题，同时由于新的分析统计需求带来的bug导致网管的重启，崩溃，从而网管最核心的配置与监控功能得不到保障
2.分析
运营数据包括话单/短信记录/拜访用户/信道监控/GPS/录音/告警
从业务耦合度考虑，拜访用户需要网管和交换双向交互，其他几类都是单向输出数据
从需求的易变性考虑，对运营数据的分析统计属于易变的，不同客户都有定制的可能性
从需求的重要性考虑，运营数据要比配置与监控功能低
GPS和录音之前也是作为独立的服务设计的，从概念上将话单/短信/拜访用户/信道监控/告警都可以独立，但拜访用户和告警牵涉网管核心功能，不能简单的独立，话单/短信/信道监控逻辑上都能做到简单的独立
通过网管上集成其他运营数据的服务，对客户而言也可以做到没有变化
综合以上几点，将运营数据的查询/分析/统计模块与网管其他模块独立，对网管而言，会有更好的扩展性和稳定性，对独立出去的一个或多个运营数据服务而言，也能更加灵活部署，更加灵活开发
3.方案设计
直观的方案
缺点：耦合度大，数据仓库需要了解网管内部逻辑，例如号码编解码，各种业务属性枚举
优点：网管几乎不做改动
建议：不推荐，否则可能后患无穷
缺点：相对现状，涉及改动的设备太多，改动内容太大
优点：耦合度低，模式具有普遍性，不局限与处理运营数据，适用于各类设备与网管的所有交互
建议：现阶段不推荐，如果将来有机会进行大的重构，可以考虑发展
缺点：访问查询/统计服务时，存储的数据有冗余，输入的查询条件存在局限性。例如存储话单时，每条都要报春“用户名称”/“单位”全称，按照“单位”查询时也不能按树状结构选择
优点：耦合度低，改动量不大
建议：推荐，
4.