BOSS接口监控及应急分析

　　BOSS作为移动运营商业务支撑的最核心系统，在提高运营能力、控制成本、分析市场等方面都发挥关键作用。随着数据业务的快速发展，外围系统不断增加，系统之间的数据传递与功能交互也呈剧增趋势。

由于历史与公司发展策略等多种因素，佛山移动的BOSS系统中存在着多种系统并存的情况。而多数系统由不同公司开发，也导致数据格式、消息机制等不尽相同。其中的惟一相同点，是外围系统都必须通过“接口”才能与BOSS产生交互,接口有效地保证了数据安全与模块独立，同时也意味接口中断将割裂内外部系统的连接。

根据规范，所有功能与业务的设置都必须由BOSS发起，一旦发生接口故障，涉及外围系统的一切操作都将失败。以目前的用户基数，即便是短时间内发生异常，所造成的影响也是不可估量。因此，研究如何保障接口的高稳定性与可靠性意义重大。

BOSS2.0接口系统框架 　　

BOSS接口系统并非独立存在，图1描述了接口系统的技术框架，如图中所示，在整个技术架构中，BOSS接口所处的位置、与关联模块的对接方式、内部实现原理等因素，都是能有效维护BOSS系统的基本前提。

图1 BOSS2.0接口系统框架 　　

由图1可知，从调用方向的角度看，接口可分为主动接口和被动接口，分别表示BOSS调用外围系统服务，以及外围系统调用BOSS服务。主动接口由BOSS应用服务器驱动，即BOSS应用服务器上的主动服务接口进程，是调用CICS对相关待处理表进行轮询，并将每一条记录封装为一条消息放入MQ队列（该队列均由消息组成），接口机上的主动接口再从队列中取出消息进行解析，进而根据控制信息发送到指定系统执行。被动接口则是由外围系统驱动，通过接口机上的CICS客户端调用BOSS应用服务器上的业务层服务操作数据库。

值得一提的是，作为BOSS与外围系统的承接点，接口的功能最终可归结为对BOSS与外围系统数据库的操作。其中，主动接口的实现逻辑对BOSS2.0接口监控措施的实现至关重要。

接口监控措施 　　

监控接口是避免故障突发的重要措施。通过分析运行情况，监控接口能实现异常情况的提前预警，有效地缩短故障持续时间。

从分析方法的角度看，监控可分为定性和定量两种，前者关注受监控体相关因素本质是否发生变化，是常用手段，而后者则深入到相关因素变化的数量，使分析更为彻底。

1.接口定性监控 　　

接口的本质是进程，监控进程一般采用查看进程状态以及日志分析。作为有具体应用的进程，接口还有其特殊性，因而接口的定性分析至少覆盖以下4个层次。

1)系统环境 　　

指操作系统及硬件环境稳定，提供进程足够的信息资源，不存在非兼容应用等情况，这些是接口赖以生存的基本条件。

2)进程状态 　　

在系统环境满足的情况下，检测进程状态是最重要的方法，但必须注意进程活跃并不等同于进程正常工作，在Linux系统中，其进程可能因异常而停止工作，但仍能在活跃列表中查询到，此时需配合日志做进一步定位。发生后这种现象的原因是，在正常情况下，所有的进程动作都会被写入log文件。

3)日志分析 　　

在日志分析环节，主要包括写入状态与日志内容，如果检测到日志处于写状态，则说明对应进程是活跃的，但进程正常与否尚需进一步判断日志内容。异常操作时，在日志中会有失败代码关键字返回，如failed、error等。

4)进程时态 　　

进程时态指从业务角度看进程活跃的时间段。并非所有进程都是24小时处于工作状态，正如银行划扣接口一般只允许在夜间启动，因此白天期间检测日志是无法判断该进程是否正常，若不考虑该特性，则可基本判断该进程结果是否有可能出错。

在接口的定性监控方面，只有充分结合以上4个因素，才能对接口运行情况形成较全面认识。

在具体实施上，为了形成统一的体系以方便监控并达到告警信息与实时的反馈，可将以上4个层面因素纳入IBM公司开发的TIVOLI监控系统。除此之外，为实现告警信息的自动推送与分发，可将自行开发告警信息转发程序接入TIVOLI监控系统信息库。一旦检测到异常信息存在则立即进行短信或邮件的发送，确保维护人员及时了解接口系统运行情况。整个过程如图2所示。

图2 TIVOLI监控接口模型 　　

2.接口定量监控 　　

上文措施均从接口本身入手，并定性分析其运行情况。根据图1对主动接口实现机制的描述，本节文字将从外系统（BOSS库表）的角度提出监控措施，并利用表面不关联的数据实现对接口性能的定量分析。

由于主动接口的业务数据来源于BOSS库表，那么，库表数据累积情况即反映了接口的运行情况，而库表数据的递减情况也就反映了接口的性能。示意图如图3。

图3 库表数据变动逻辑示意图 　　

假设主动接口在正常工作的情况下进程数为N，库表原有数据量U，业务请求增速恒定Su，经过时间t后U降低为0（生产环境中取接近0，若库表数据随时间不断增加则说明接口性能不满足），则接口单个进程性能为Ci=(U+Sut)/Nt。通过接口性能能够估其吞吐能力，再结合业务量重新调整接口进程数，达到资源优化配置。

对于不间断工作的主动接口（如HLR施工），若其计得性能c，业务请求增速恒定为Su，在相邻的2个单位时间内查得的库表数据量，先后为Ut、Ut+1，则如果|Ut-Ut+1|≈|c-Su|则说明接口正常，否则接口可能存在异常，需要引起重视。

对于被动接口，BOSS库表的作用是保存业务执行结果，因此在计算性能时只需考虑外部请求满负荷情况下库表的增速Sp，即Cp=Sp。但必须注意的是，库表数据的增长速度s低于Cp并不能说明接口一定异常，因为在非满负荷情况下s 　　对于负责业务查询的接口，其数据源与结果均不经过BOSS库表，因此上述方法不具有普适性。

使用定性分析与定量分析的两种监控方法，都只涉及接口的某一特性，在监控时还需充分考虑各种因素，建立完整的接口健康度模型，在定性方法无法判断接口运行状态时需进一步进行定量分析，使得两种方法优势互补，提高监控的有效性。

应急方案与工具 　　

应急是在故障事实既定时的补救措施，主要包括应急方案与工具，前者是完整的流程及措施，后者能辅助方案的顺利实施。

1.制定应急措施并演练 　　

作为BOSS与外围系统的惟一连接点，接口故障将导致内外系统完全中断。因此，最好的应急措施之一就是在故障时立即将服务切换到备机。为保证一次切换成功率，应急方案须详尽、具可操作性与验证性，并至少在方案中详细描述以下关键点。

1)接口机与备机网络环境，包括逻辑连接图、备机IP、网络联通等作为判断条件； 　　

2)接口启动方式与配置参数，包括指令路径及执行方式，配置文件具体修改方法，接口已正常启动的标志； 　　

3)备机具备对主机完全可代替的条件，包括接口进程类型、数量，操作系统环境，配置信息及网络结构等； 　　

4)误操作回滚逻辑，包括操作步骤、命令字，检测回滚成功的方法。该部分的描述在出现切换失败时显得尤为重要； 　　

5)切换结果测试用例，在切换成功后根据预先设计好的输入检测输出是否符合要求，是检测切换结果的有效手段。

必须强调的是，完善的应急预案并不能保障应急成功，只有配合熟练演练才能真正发挥预案的作用。

2.开发应急工具 　　

应急工具能有效缩短故障恢复时间。广东移动通信有限公司自主开发的“BOSS接口异常数据辅助处理系统”便是处理客服接口故障的重要应急工具之一，系统通过将异常数据封装为协议包直接送接口执行，可有效弥补BOSS前台功能不足、或前台界面异常及因流程冗长引起的施工延时或故障，同时由于该方式精简流程，执行效率与成功率高，能有效应对紧急情况。

图4 智能网号码充值流程 　　

以图4智能网充值开机流程为例，其经历的步骤繁多，特别是其中信控判断逻辑复杂，程序处理耗时多，是引起月结用户充值到账但无法及时开机的关键环节。站在服务用户的角度，最直接的应急方式便是提取已缴费入账的号码直接送HLR施工开机，对于存在欠费可能的用户，其开机状态在正常流程进行修复，但对于充值后仍欠费的用户，其开机状态将在经历过信控后自动被修改为停机。

尽管该方式可能产生欠费风险，但考虑到大部分用户将根据欠费额度进行充值，同时流程修复时间也相对较短，该方法依然是可行的。

利用BOSS接口异常数据辅助处理系统执行以上应急流程的方式是：在提取号码后，根据客服协议开机命令字10007格式要求（HandsetNo~工号~返回格式~nCode~sType~备注），将批量号码构造成报文列表并导入系统执行。主界面如图5所示。

图5 系统主界面 　　

该系统的设计模型如图6所示。由设计模型可看出，系统主要实现协议包的封装与发送，后续流程由接口进程完成，因此，只要是接口协议支持的业务系统即可。统计《客服接口说明》命令字可知系统支持的业务类型约计500种，能有效满足多种需求。

图6 系统设计模型 　　

为了调节对接口所产生的压力，系统还实现线程数与执行时间的动态配置，在接口压力较大时可减少系统线程，并把对资源需要量多的任务定时在晚间自动启动，避免对接口日常运作造成不良影响。

总结 　　

本文主要研究BOSS接口的监控方法以及应急措施，将传统手段纳入监控系统，并重点介绍利用库表定量分析。在应急措施中，主要讨论应急方案以及自建系统在应急中的作用，通过监控预防故障突发，利用应急措施降低故障影响范围，形成较完整的接口维护体系，佛山移动目前在实践中已经验证了该方法的有效性。