运维改革探索(二)：构建可视化分布式运维手段(4)

然后就是对用户操作业务聚合,即按时间顺序、用户操作的业务名称、用户号码等对用户真实的操作情景予以重建,这样做的好处是从整体上了解某一笔业务的操作繁琐程度(难易度、友好性)；了解某一笔业务在哪一步较慢,是慢在网络层面、客户端层面、服务器层面还是用户自身原因(如间歇性停留)导致的；了解业务分布情况及成功率、转化率等.为确保业务聚合的并行计算高效,我们采取了spark流处理机制完成.目前主要应用了如下几个场景：

场景1：以下图为例,通过大数据的数据聚合+分组手段,实现对用户行为的模式匹配,将多个操作归结到一笔业务中,实现用户体验不好根本原因是IT原因造成还是非IT因素造成(用户问题、营业员操作问题)：

场景2：结合大数据的分析,掌握用户的操作规律、操作习惯,并基于这些分析进行页面优化,如在合适位置投放广告,发布符合大众需求的产品与优惠：

场景3：实现基于业务监控的入侵检测机制,我们基于集中日志分析,利用大数据技术实现基于业务聚合的CC攻击分析方法,将用户操作与浏览器请求建立关联,首先将URI请求按用户操作聚合,形成用户操作序列,再按照时间先后顺序及一定的业务规则将用户操作聚合为业务单元,通过对业务单元数据分析判断是否存在入侵检测.大大提高了针对仿真式DDos攻击的鉴别准确度.

下图是近期发现的感染木马病毒的终端列表：

3、深入性能诊断

我们基于集中日志实时分析,可用于性能诊断等场景,并总结了一些宝贵经验：如网络故障关联分析和诊断、诊断企业总线调用外部域时发生的故障、基于接口报文的后端交易调优、针对RPC的性能分析等.

1)网络故障诊断

网络延迟故障一般可以从用户体验的网络耗时一项直接诊断定位,但有时很难一下子定位,也需要从用户请求中,如从HTTP服务器和WAS服务器的耗时份额对比中推导,亦可以从用户请求服务器代码路径中推导出来.

从下图1看,某用户请求在IHS(HTTP服务器)上耗费的时间为14.69s,而端到端路径分析,在WAS(APP服务器)上的耗费时间为2.57ms,因此分析可知时间主要耗费在HTTP服务器上,而HTTP服务器主要作为一个代理与用户终端交互,因此分析得知有2种可能：在终端用户到HTTP服务器之间的链路上出现了网络故障,或HTTP服务器出现了性能问题,而经过监控发现其他业务运行均正常,HTTP服务器线程池使用正常,如图2所示,因此通过排除法得知网络故障可能性较大.

图1 端到端路径分析

图2 HTTP服务器的线程池使用情况

另外通过服务器响应字节数进一步证实之前的推论,返回大小相比其他同类请求来说较大,如下图所示.

2)基于接口报文进行的后端交易优化

我们CRM交易处理程序基于C/C++实现,这导致交易中间件无法向基于JVM的前端Web服务一样实现运行时环境注入并动态改变监控行为,只能通过捕获应用程序触发的操作系统底层业务逻辑实现,这种情况下无法实现前端与后端的单笔交易关联.为解决此问题,首先对CICS应用服务进程启动多线程跟踪,将truss日志输出流重定向到UDP,发送给外部服务器,truss会跟踪到一些极基础的函数调用,使用truss跟踪的好处是,当和被跟踪进程依附和解除依附时,对被跟踪的进程不会造成影响,因此可以在生产环境中使用.此外,可以对CICS连接到Oracle的会话,在数据库中启动10046事件跟踪,跟踪数据库的调用轨迹,这种方式的好处是：填补了CICS跟踪的空白,实现了对业务的梳理；坏处是：只能小范围开启,需要在生产隔离出单独的一套中间件,并在此环境中回放报文处理过程.

下图是通过启用数据库10046事件跟踪后,梳理出的合约机校验接口的业务逻辑(部分).

服务篇：建立面向云服务的运维架构

目前我们的运维模式是基于ITIL的,从服务台、时间管理、变更管理、可用性管理、容量管理、CMDB等思路逐步建设整个系统,这种运维思路在传统架构下没问题,但在云计算下大规模运维的时候,越来越难以应对,或者说过多的聚焦于流程和规范的情况下,很难提升运维敏捷性和精细性.当前,IT支撑系统正在向资源池、SOA架构快速演进,系统支撑能力逐步具备了服务化的能力.通过对系统能力组件化和服务化,并配合系统弹性伸缩等能力,将支撑系统的能力以“服务”的形式提供,屏蔽内部过多的细节,可以实现“IT即服务的新型敏捷支撑与运维模式.

（编辑：ASP站长网）