随着客户对合作厂商能力要求越来越高，已经不能满足于技术方面的能力，工作内容越来越需要业务支持，本次分享给大家主要介绍运营商CRM系统架构及日常运维工作中的告警部署、优化方式。

本次分享分为三个部分：

CRM系统架构大致可分为三层：

1.Web层：指weblogic服务，主要包含：一级BOSS、EUBS服务、能力开发平台、CRM前台web等子系统模块；

2.tuxedo：主要的业务逻辑处理功能，包含：客服、一级boss、电子渠道、营业前台、后台进程、接口、信控等功能模块；

3.数据存储层：主要包含营业数据库、账务数据库、服务开通库、coherence、Vsearch、hadoop；其中Vsearch存储的是各个业务的产品信息，coherence存储的是用户的访问会话信息，hadoop存储的是系统采集用户的二代证信息及人像。

根据业务途径可以分成以下4个主要子系统：

CRM营业前台

主要指BOSS（业务运营支撑）系统的前台页面，用户通过访问该页面进行业务办理；

应用主要包含：CRM营业前台weblogic服务，营业前台tuxedo，无纸化weblogic服务等。

用户营业前台办理开户，在营业前台weblogic服务采集到的二代身份证及人像信息，分别经过后台进程与无纸化weblogic服务存放到hadoop；

而产品订购及语音等通信功能的开通则是在营业前台weblogic服务进行操作后，通过调用营业前台tuxedo中间件来实现；

如果是产品订购的是全网业务，还需经过一级BOSS系统处理；

开通语音等通信功能，省支撑的用户数据需要通过服务开通模块同步到网管中心。

服务开通

主要向网管同步用户数据，由网管提供移动通信基础服务功能；

由tuxedo中间件处理后的数据首先会存放在营业库，通过工单复制进程，把工单数据从营业库同步至服务开通库，最后工单发送进程把数据同步至网管中心。应用主要包含：相关工单后台进程。

一级BOSS

受理全网业务；作为发起方向集团或者外围平台厂商发送交易请求，作为落地方接受并处理集团或者外围厂商平台发送的交易请求；

应用主要包含：一级BOSS业务weblogic服务，一级BOSS业务tuxedo；

外围平台包括支付宝、微信；校讯通、农信通等；

一级boss业务从业务请求方不同可以分为落地方业务与发起方业务；

1.落地方业务：

用户在外围平台办理业务，由一级BOSS的weblogic服务接收到服务请求后，调用一级BOSS业务的tuxedo中间件，进行业务处理、数据入库，并反馈业务处理结果，应答给外部平台，完成整个落地方业务流程；Weblogic服务：根据报文的格式又可以分为T模块（xml）与R模块（json）；

2.发起方业务：

用户在前台办理业务，用户数据通过营业前台系统入库，随后主要由后台进程从数据库中抽取数据向外部平台发送业务办理请求，收到外部平台返回的应答，完成整个发起方业务流程；

电子渠道

主要承接非营业前台途径受理的本地业务，例如短厅办理，网厅办理等；

应用主要包含：EBUS业务weblogic服务，能力开发平台weblogic服务，电子渠道tuxedo，客服tuxedo；

外围平台包括短信营业厅、网上营业厅、在线公司等；

根据外围平台承载的业务不同，短信营业厅、网上营业厅、在线公司等各个平台的业务都会调用新能力开发平台与EBUS的weblogic服务；weblogic服务接收到请求后，再调用对应的电子渠道及客服tuxedo中间件进行业务的逻辑处理。

目前整个CRM系统的告警监控工作，在日常部署及处理告警监控分两大类：

1.系统监控

性能监控:CPU使用率、内存使用率、文件系统利用率；

2.业务监控

进程监控：进程数异常；

数据监控：数据库表数据积压、数据处理失败、数据处理的及时性；

日志监控：日志报错信息；

随着新项目的接入以及为了预防故障而增加相应告警，告警数量会越来越多，自然而然的增加了日常工作压力，怎么来应对越来越多的告警呢？是摆在一线运维工作人员面前的一道重要问题。

目前主要的处理方式是每隔一段时间处理的告警进行收集、分析并总结，上会讨论并确定告警优化方案，最终根据告警优化方案，再次部署告警，实现告警压降。

告警优化主要分为以下4种方式：

1.部署定时清理任务；

2.告警处理前移；

3.调整告警策略及阀值；

4.趋势告警。

目的

应急开机是为预防因系统出现异常时用户未及时开机而导致大面积投诉的情况，通过多种方式将用户进行快速开机从而恢复用户服务的一套程序，最终目的是避免用户投诉。

业务逻辑

1. 账务侧抽取需要进行应急开机的数据（三种类型：指定号码，缴费应急开机，服务开通停机回捞），插入营业库一张中间表；

2. 通过应急开机进程处理中间表的数据，向营业侧传输数据；有两种传输模式：营业信控与服务开通；

3. 营业信控模式：应急开机数据导入营业库工单表，再由营业工单复制进程与send进程从营业库同步到服务开通库工单表中；

4. 服务开通模式：应急开机数据直接导入服务开通库中的工单表中；

5. 服务开通库的工单表由对应的HLR进程及PROVSION进程处理工单数据，向网管进行数据同步。

监控

各环节的监控，以前均是通过手工登录对应主机或者物理库执行监控脚本的形式进行检查；监控链条长，形式多样，纯手工操作容易形成顾头不顾尾的局面，导致部分节点遗漏监控，降低应急开机的及时性，使应急开机的效果大打折扣。

核心业务拓扑图

加快核心业务流程梳理，建立业务拓扑图并在自动化运维平台进行部署；

运维工作自动化

梳理日常工作中常态化的人工操作，编写脚本，迁移至自动化运维平台；

经验积累沉淀转化

故障、告警处理经验总结，形成前置性标准规范及自检，加强问题隐患的前置性处理。