首页 > 学院 > 网络通信 > 正文

全面提升IT系统质量 美科利电信行业解决方案

2019-11-04 22:14:38
字体:
来源:转载
供稿:网友

  随着电信行业竞争的加剧,全面提升治理水平和运营能力成为了电信企业能否成功的要害,从某种程度上说,未来电信运营商的竞争能力不再单纯依靠于电信资源,而将是越来越多地取决于以IT技术为支持的治理能力。

  ·面临问题

  长期以来,电信核心应用系统的治理更多定位在面向网络等系统资源方面,很少把后台应用系统与支撑客户和客户服务联系起来,随着市场变化和企业运营理念的变革,核心应用系统的治理面向客户的需求越来越迫切。一方面系统的治理和优化、资源的调配和优化越来越需要客户的信息和资料;另外一方面,外部客户(非凡是大客户或者是签署了SLA的客户),也需要在一定程度上参与系统治理和资源调配。因此,如何使治理实现面向用户就成了当前电信应用治理的最大挑战。

  ·解决方案

  针对传统应用治理系统的不足,全球业务优化科技(BTO)的领导者美科利公司提出了以业务应用为核心的电信应用治理平台。这种治理平台采用了先进的以业务应用为核心,自顶向下的治理方法,实现了电信行业IT系统治理出发点由支撑业务应用的系统架构变成了业务应用本身的转变。

  目前大多数电信行业的用户都针对OSS/BOSS进行了治理系统的建设,这些系统在系统架构监控方面做了很多工作而在业务应用监控方面相对不足,美科利针对电信应用设计的应用治理方案也是以解决这方面问题为主来进行的。

全面提升IT系统质量 美科利电信行业解决方案(图一)

  假如不考虑业务数据的采集(指来源于交换机或智能网的数据),业务支撑系统的核心架构可以分为三个层次,分别是客户端浏览器、中间业务逻辑和后台核心数据库。任何一项在前端客户端发起的业务都会跨越这几个层次,而前端业务的可用性和性能与这些环节之间的关系是复杂的,很难通过某个环节的监控来倒推出业务在最终用户端的可用性,因此美科利推荐的应用治理方案将最终用户端的应用监控作为出发点和核心。

  ·方案设计

全面提升IT系统质量 美科利电信行业解决方案(图二)

  针对BOSS应用系统的特点,我们分别选用Mercury BAC server,Business PRocess Monitor,Mercury SAM(Sitescope)和Mercury Diagnostics for J2EE构建了BOSS应用治理系统架构。

  BAC Server是BOSS应用系统的核心,它将接收到的最终用户数据加以处理生成各种业务可用性和性能报告,并处理接收来自其他数据采集器的数据,生成关联视图,为各种运维人员提供监控信息和解决故障的依据。

  业务流程监控(BPM)通过驱动预先录制的脚本来模拟用户对业务应用的访问,通过接受和分析应用对访问的响应来判定应用的可用性和性能。

  Sitescope通过获取的典型数据包括Tuxedo、Weblogic、Oracle等对象的运行参数,然后将这些数据传送到BAC Server,治理人员就可以在BAC Server上进行业务和系统架构之间的关联分析。

  Diagnostics Server可以对J2EE应用服务器的很多性能问题进行深入的分析,指出业务应用本身存在的问题,并将分析的结果统一放到BAC Server上来展现。

  Diagnostics Probe与Diagnostics Server配合使用,是一个需要安装在应用服务器上的探针,它能将采集J2EE应用运行数据到的数据传送到Diagnostics Server。 QQread.com 推出各大专业服务器评测 linux服务器的安全性能 SUN服务器 HP服务器 DELL服务器 IBM服务器 联想服务器 浪潮服务器 曙光服务器 同方服务器 华硕服务器 宝德服务器


  ·治理流程

  我们这里说的流程上是上述Mercury应用治理方案的一种典型使用场景,因为流程本身与应用有很大的关系,而且同具体的情况也有关,因此我们在这里给出的是一个比较典型的故障发现和定位流程。

  故障发现

  故障告警可来源于Sitescope对系统架构的监测,也可以来源于BPM对业务应用的监测。而来源于业务应用方面的告警(由BPM汇报的故障),具有最高优先级,应该首先处理。如BPM汇报网上营业厅的客户帐单查询不能正常进行,而后所有地点的BPM汇报了同样的错误,这说明当前的错误同核心应用系统相关。

  故障定位

  通过对BPM历史数据的回顾,可以发现网上营业厅业务的响应时间超时是引起故障的原因;再通过BPM汇报的交易细分(Transactio·Breakdown),我们发现响应时间超时是服务器响应缓慢造成的。然后通过Sitescope故障排查,假如支撑网上营业厅的Web服务器和后台的数据库都没有异常,那就是应用服务器碰到了问题。

  故障诊断

  接下来我们通过Diagnostics对J2EE应用服务器进行分析。通过跟踪我们发现,网上营业厅应用与后台数据库通过JDBC建立连接的时间较长是导致最终应用响应超时的原因。再通过进一步分析,我们发现了故障根源是JDBC连接池缓冲区设置不够大的原因,我们就可以方便地解决问题。

  ·方案效果

  将业务系统以明晰的视图展示出来,针对不同治理人员,展示不同治理侧重;

  从业务的角度主动治理整个企业内部的业务流程和应用;

  提供了一种沟通手段,使得业务人员和IT运行维护人员能够互相沟通需求、问题,确定重要程度和优先级;

  主动解决应用问题;

  治理支撑业务系统的系统架构。



发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表