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 库表数据变动逻辑示意图 　　

假设主动接口在正常工作的情况下进