电信BSS业务监控系统的设计与应用研究

许玉华

（南京中兴软创软件技术有限公司，江苏 南京 210000）

0 引言

当前的运营商发展速度已经逐渐趋于平缓，但行业之间的竞争却是越发激烈。同时，电信企业内部的系统，尤其是BSS系统规模正在逐步扩大，带来了维护成本显著提高的问题。运营商为了谋求进一步的发展，就必须要保障用户的使用体验，而这就需要一个强大的运维系统作为支撑。由于之前BSS设计十分重视功能堆积，对业务监控系统的设计不予重视，使得有关服务的业务监控及异常处理完全不存在，极大地影响了用户的使用体验，为此，本文针对电信BSS业务监控系统的设计展开了研究。

1 电信BSS业务监控系统的总体目标

设计电信BSS业务监控系统的主要目标，就是在通信网络中可以借助流量的分析和理论的挖掘，做到实时监测和记录整个电信业务过程，并借助原定设置的规则配置手段，将不健康的内容进行过滤，并对一些非法业务进行及时的阻断，从而影响达到保护通信网络，提升整体服务质量的目的。从当前的情况来看，电信业务种类十分繁多，根据不同的角度也可以做出不同类型的划分。就比如其中的浏览业务，就是指用户借助充当浏览器来访问相应的网站的行为，这种业务根据所采用的浏览技术上的差异，可以分为WAP浏览器和Web浏览两种，由于受到终端技术和WAP协议的限制，浏览类的业务在最初发展的时候只能够访问一些数量有限且内容单一的WAP网站。但是在手机处理能力不断提升的影响下，WAP的协议也得到相应的扩展，再加之网络带宽的增加，使得用户可以访问到内容较为丰富的互联网网站。

2 电信BSS业务监控系统的设计原则

在设计电信BSS业务监控系统的过程中，需要遵循如下几个方面的原则：第一，易用性原则。BSS整个业务系统内部的各个业务系统是孤立建设的，整个业务系统的内部和系统之间存在较为复杂的交互以及数据之间的传递工作，从而导致整个企业的信息系统管理工作复杂程度相对较高。在设计业务监控系统的过程中追求可视化和易操作，可以逐步减少对于专业人员的过度依赖，同时这也是当前整个BSS业务监控系统设计所追求的原则之一[1]。第二，可靠性原则。业务监控系统设计的最初目的就是为了确保电信企业实现智能化运维的目标，这也就意味着监控系统不可以对BSS系统内部的基础业务运行和性能产生相应的影响，系统在设计的环节中需要遵循标准和规范化的原则，保证整个系统具备较高水准的可靠性，以此来确保基础性质的业务能够正常的运转。第三，安全性原则。BSS系统内部保存着有关客户的重要资料，这也就意味着系统需要对外部的各种恶意攻击和病毒入侵做出有效安全的防范，并且需要对访问权限做出严格细致的管理，对于一些特殊性质的操作和重要的数据，必须在经过有关用户的授权之后方可进行使用，而这些要求也就意味着整个系统必须具备相应的数据加密、身份认证等安全措施。业务监控系统在设计的环节中，也需要沿用原有电信BSS系统中固有的安全加固模式。第四，扩展性原则，在电信业务不断发展的影响下，BSS业务监控系统往往会出现无法全面监控的情况，同时监控的范围和场景也会出现相应的变化。在这种情况下，整个业务监控系统就需要添加全新的功能模块，或者是和其他的工作软件进行连接使用。在这些要求下就需要确保整个业务监控系统具备良好的拓展性，需要在设计标准化接口的前提下，做到轻松和第三方软件进行相应的对接，从而真正意义上做到不同应用平台间直接进行信息的有效交互，以便更好地解决运维工作的管控、业务系统间的协同和适配问题。第五，伸缩性原则[2]。

3 电信BSS业务监控系统的部分功能模块设计

3.1 服务调用设计

对于整个BSS业务监控系统而言，服务调用是其中的高级运维部分，其主要功能就是定位系统故障的发生位置及分析整个系统的运行状态。其具体的分层包括显示层、服务能力、统计分析、存储、汇聚、采集、埋点等。其中的埋点是借由平台的中间件以及业务逻辑，在完全遵循日志规范的基础上，实现日志的埋点输出，具体的日志输出内容调用链的埋点日志、跟踪日志等。部署在业务服务器内部的Uni Agent中的 Flume Agent，主要是负责采集日志的从文件，并将之传输到汇聚层。在日志汇聚之后，需要由Flume集群将存在于Kafak中的数据全部取出，在将这些数据导入原始日志库及搜索完服务器之后，需要进行流式计算即调用链整体状态进行计算，随后将计算得出的结果数据导入到搜索服务器中。

统计分析层则是将原始日志库中埋点日志进行提取和调用，并在进行分析和计算之后将调用链的结果数据生成表格存放到分析结果库中。而服务能力则是为外界提供相应的运维服务结果。

分布性质的服务跟踪系统的主要思路就是借助服务调用链的各个服务处理节点响应产生的日志信息，通过串联同一个生产请求中带有同一个ID的系统和服务，并在经过重组还原之后得到更多具有价值的信息。具体来说，每一个URL请求都生成一个全局唯一化ID，而这个ID在BSS业务监控系统中被称作是Trace ID，同时这个ID将会存在于对应URL请求中全部的服务调用等环节生成的全部日志中。由于这些全部的资源访问行为都是在分布式环境下开展的，如若想要在应用程序中实现打印服务链路日志和传递Trace ID的目标，也就意味着在程序中会有大量的日志打印代码，而且需要以用数据的方式将Trace ID传递到下一个服务节点，而这些环节的存在都为整个系统带来了较大的代码入侵风险。因为BSS业务系统绝大部分都是用Java语言编写的，为此就会在服务框架层和资源的驱动访问层中植入传递Trace ID的功能代码，换言之就是在中间件层面上统一实现了业务监控系统上下文的创建[3]。有效调用上下网在中间件中的网络请求传递，并能够做到将上下文信息的调用保存在本地的Thread Local中，从而有效实现了BSS业务监控平台所需要的上下文调用和日志信息对于系统开发人员完全透明的目标。

3.2 巡检管理设计

整个系统的健康程度评价，也是通过各个系统指标项的得分汇聚计算而来的，就当前的情况来看，系统自身的健康度模型可以将业界内部通用的QOE模型作为参考，并借此设计出一套评估BSS业务系统的健康度模型。这个模型主要是从BSS内部的各个产品和业务服务器中进行业务数据日志和性能指标的收集并严格按照业务流程的维护需求设置相应的KPI。健康度模型中存在的任何一个中间节点的健康度都是由下一层的节点数据经过汇集计算得出的，而叶子节点的健康度主要是由3个KQI的总体评分得出的，主要是针对不同业务所提出的接近用户感受的业务质量参数，包括可用性、性能下降程序及事件扣分。其中每一个KQI评分也是经过不同的KPI得分汇聚而来的，而在电信BSS业务监控系统中的KPI主要指的是应用、服务、资源三者，比如在性能下降中会设置时延平均数、CPU占用率以及内存使用率等。借助基础性能将性能KPI或是业务KPI经过采集上报之后，进行相应的汇聚加工操作，使用相应的计算表达式可以做到标准化处理单个或者是有所关联的KPI，并真正在给出单个节点评分数值的前提下，借助汇聚算法得出父节点的数值，最终就能够得到顶层节点的评分。

4 结语

传统的电信BSS业务系统单纯地注重功能模块设计，忽视了业务监控功能的设计导致无法有效及时地处理整个业务系统运营中出现的故障，直接降低了整体的用户使用体验，这对于电信企业的进一步发展有着极大的损害。本文针对现有BSS业务系统中监控系统的不足，在全面遵循设计原则的基础上就其中的日志管理和服务调用两大模块进行了相应的设计改进，以便为今后的电信BSS业务系统设计改良提供相应的参考。