论文部分内容阅读
随着电信行业竞争的加剧，全面提升管理水平和运营能力成为电信企业能否成功的关键，这就使得业务应用的管理不再是一种纯粹的支出，而是业务本身的一部分。
从某种程度上说，未来电信运营商的竞争能力不再单纯依赖于电信资源，而将是越来越多地取决于以IT技术为支持的管理能力。因此，业务应用管理在未来将发挥越来越重要的作用。
电信行业应用系统的用户一般可以分为两大类：外部客户和内部客户。外部客户是指电信业务的服务对象，既有最终用户，也有增值服务提供商(ICP、ISP等)客户；内部客户是指运营支撑系统在企业内部的使用单位和使用者，对内部客户的支撑有一部分最终转化为对外部客户的服务，因此如何对内部客户实施有效支撑也非常关键。
面向客户的管理就是保障电信运营企业的这两类客户能够方便、敏捷、高效的的使用应用系统，提高客户的满意度，发掘应用系统的最大价值，为企业的最终价值目标服务。
面向客户的管理不是一个主观的产物，而是市场的成熟和竞争导致电信运营企业必须实现管理从面向网络系统资源到面向用户的转变。这是企业发展的战略需要和运营管理的需求。
资源管理向客户管理转变的挑战
业务的需求是推动应用系统技术架构进行转变的根本因素，这个转变的过程是从业务需求同技术架构之间的矛盾开始的，这一点对于电信业务应用的管理来说也是如此。
长期以来，电信核心应用系统的管理更多定位在面向网络等系统资源方面，很少把后台应用系统与支撑客户和客户服务联系起来。
随着市场变化和企业运营理念的变革，核心应用系统的管理面向客户的需求越来越迫切。一方面，系统的管理和优化、资源的调配和优化越来越需要客户的信息和资料；另外一方面，外部客户(特别是大客户或者是签署了SLA的客户)，也需要在一定程度上参与系统管理和资源调配。因此，如何使管理实现面向用户就成了当前电信应用管理的最大挑战。
在这方面，电信运营商也在进行不断的探索和尝试，但以系统架构为核心的应用管理无论如何优化和完善，都很难满足以业务为核心、面向用户的需求，对管理的定位和中心进行调整看来是不可避免的。
以业务为核心的平台管理
真正地实现应用管理系统面向客户是一个企业管理问题。随着电信业务应用系统的日渐复杂，前后台界限变得模糊，对企业的核心应用系统进行面向业务管理的需求越来越迫切，这个系统将帮助企业的内部和外部用户获得优质的应用服务。
完善的应用管理系统的建设是一个长期的过程，而且因各运营商的不同具体情况也会导致管理系统具有不同的模式特点。从目前的发展情况来看，管理系统建设的发展趋势的共性体现在三个方面：以客户为中心、规范化的流程和良好的整合机制。
全球业务优化科技（BTO）的领导者美科利公司的应用管理策略可以说是针对传统应用管理系统的不足提出的。
我们看到，传统的应用管理问题在于它采用的是一种以IT系统架构管理为基础、自底向上的管理方法，这种方法导致了管理手段和管理目标的背离。
美科利的应用管理采用的则是一种以业务应用为核心，自顶向下的管理方法。这种方法实现了管理视角的转变，即管理的出发点或最初的着眼点由支撑业务应用的系统架构变成业务应用本身。
美科利公司提出的以业务应用为核心的电信应用管理平台采用了先进的以业务应用为核心，自顶向下的管理方法，实现了电信行业IT系统管理出发点由支撑业务应用的系统架构变成了业务应用本身的转变。
目前大多数电信行业的用户都针对OSS/BOSS进行了管理系统的建设，这些系统在系统架构监控方面做了很多工作，而在业务应用监控方面相对不足，美科利针对电信应用设计的应用管理方案也是以解决这方面问题为主来进行的。
如果不考虑业务数据的采集（指来源于交换机或智能网的数据），业务支撑系统的核心架构可以分为三个层次，分别是客户端瀏览器、中间业务逻辑和后台核心数据库。任何一项在前端客户端发起的业务都会跨越这几个层次，而前端业务的可用性和性能与这些环节之间的关系是复杂的，很难通过某个环节的监控来倒推出业务在最终用户端的可用性，而美科利推荐的应用管理方案将最终用户端的应用监控作为出发点和核心。
方案设计
针对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。
管理流程
这里说的流程是上述Mercury应用管理方案的一种典型使用场景。因为流程本身与应用有很大的关系，而且同具体的情况也有关。这里给出的是一个比较典型的故障发现和定位流程。
故障发现
故障告警可来源于Sitescope对系统架构的监测，也可以来源于BPM对业务应用的监测。而来源于业务应用方面的告警（由BPM汇报的故障），具有最高优先级，应该首先处理。如BPM汇报网上营业厅的客户账单查询不能正常进行，而后所有地点的BPM汇报了同样的错误，这说明当前的错误同核心应用系统相关。
故障定位
通过对BPM历史数据的回顾，可以发现网上营业厅业务的响应时间超时是引起故障的原因；再通过BPM汇报的交易细分（Transaction Breakdown），我们发现响应时间超时是服务器响应缓慢造成的。然后通过Sitescope故障排查，如果支撑网上营业厅的Web服务器和后台的数据库都没有异常，那就是应用服务器遇到了问题。
故障诊断
接下来通过Diagnostics对J2EE应用服务器进行分析。通过跟踪发现，网上营业厅应用与后台数据库通过JDBC建立连接的时间较长是导致最终应用响应超时的原因。再通过进一步分析，就会发现了故障根源是JDBC连接池缓冲区设置不够大的原因，就可以方便地解决问题。
方案效果
综合来看，该方案的顺利实施可为电信运营商带来如下明显效果：
以明晰的视图展示业务系统，针对不同管理人员，展示不同管理侧重；
从业务的角度主动管理整个企业内部的业务流程和应用；
提供了一种沟通手段，使得业务人员和IT运行维护人员能够互相沟通需求、问题，确定重要程度和优先级；
主动解决应用问题；
管理支撑业务系统的系统架构。
从某种程度上说，未来电信运营商的竞争能力不再单纯依赖于电信资源，而将是越来越多地取决于以IT技术为支持的管理能力。因此，业务应用管理在未来将发挥越来越重要的作用。
电信行业应用系统的用户一般可以分为两大类：外部客户和内部客户。外部客户是指电信业务的服务对象，既有最终用户，也有增值服务提供商(ICP、ISP等)客户；内部客户是指运营支撑系统在企业内部的使用单位和使用者，对内部客户的支撑有一部分最终转化为对外部客户的服务，因此如何对内部客户实施有效支撑也非常关键。
面向客户的管理就是保障电信运营企业的这两类客户能够方便、敏捷、高效的的使用应用系统，提高客户的满意度，发掘应用系统的最大价值，为企业的最终价值目标服务。
面向客户的管理不是一个主观的产物，而是市场的成熟和竞争导致电信运营企业必须实现管理从面向网络系统资源到面向用户的转变。这是企业发展的战略需要和运营管理的需求。
资源管理向客户管理转变的挑战
业务的需求是推动应用系统技术架构进行转变的根本因素，这个转变的过程是从业务需求同技术架构之间的矛盾开始的，这一点对于电信业务应用的管理来说也是如此。
长期以来，电信核心应用系统的管理更多定位在面向网络等系统资源方面，很少把后台应用系统与支撑客户和客户服务联系起来。
随着市场变化和企业运营理念的变革，核心应用系统的管理面向客户的需求越来越迫切。一方面，系统的管理和优化、资源的调配和优化越来越需要客户的信息和资料；另外一方面，外部客户(特别是大客户或者是签署了SLA的客户)，也需要在一定程度上参与系统管理和资源调配。因此，如何使管理实现面向用户就成了当前电信应用管理的最大挑战。
在这方面，电信运营商也在进行不断的探索和尝试，但以系统架构为核心的应用管理无论如何优化和完善，都很难满足以业务为核心、面向用户的需求，对管理的定位和中心进行调整看来是不可避免的。
以业务为核心的平台管理
真正地实现应用管理系统面向客户是一个企业管理问题。随着电信业务应用系统的日渐复杂，前后台界限变得模糊，对企业的核心应用系统进行面向业务管理的需求越来越迫切，这个系统将帮助企业的内部和外部用户获得优质的应用服务。
完善的应用管理系统的建设是一个长期的过程，而且因各运营商的不同具体情况也会导致管理系统具有不同的模式特点。从目前的发展情况来看，管理系统建设的发展趋势的共性体现在三个方面：以客户为中心、规范化的流程和良好的整合机制。
全球业务优化科技（BTO）的领导者美科利公司的应用管理策略可以说是针对传统应用管理系统的不足提出的。
我们看到，传统的应用管理问题在于它采用的是一种以IT系统架构管理为基础、自底向上的管理方法，这种方法导致了管理手段和管理目标的背离。
美科利的应用管理采用的则是一种以业务应用为核心，自顶向下的管理方法。这种方法实现了管理视角的转变，即管理的出发点或最初的着眼点由支撑业务应用的系统架构变成业务应用本身。
美科利公司提出的以业务应用为核心的电信应用管理平台采用了先进的以业务应用为核心，自顶向下的管理方法，实现了电信行业IT系统管理出发点由支撑业务应用的系统架构变成了业务应用本身的转变。
目前大多数电信行业的用户都针对OSS/BOSS进行了管理系统的建设，这些系统在系统架构监控方面做了很多工作，而在业务应用监控方面相对不足，美科利针对电信应用设计的应用管理方案也是以解决这方面问题为主来进行的。
如果不考虑业务数据的采集（指来源于交换机或智能网的数据），业务支撑系统的核心架构可以分为三个层次，分别是客户端瀏览器、中间业务逻辑和后台核心数据库。任何一项在前端客户端发起的业务都会跨越这几个层次，而前端业务的可用性和性能与这些环节之间的关系是复杂的，很难通过某个环节的监控来倒推出业务在最终用户端的可用性，而美科利推荐的应用管理方案将最终用户端的应用监控作为出发点和核心。
方案设计
针对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。
管理流程
这里说的流程是上述Mercury应用管理方案的一种典型使用场景。因为流程本身与应用有很大的关系，而且同具体的情况也有关。这里给出的是一个比较典型的故障发现和定位流程。
故障发现
故障告警可来源于Sitescope对系统架构的监测，也可以来源于BPM对业务应用的监测。而来源于业务应用方面的告警（由BPM汇报的故障），具有最高优先级，应该首先处理。如BPM汇报网上营业厅的客户账单查询不能正常进行，而后所有地点的BPM汇报了同样的错误，这说明当前的错误同核心应用系统相关。
故障定位
通过对BPM历史数据的回顾，可以发现网上营业厅业务的响应时间超时是引起故障的原因；再通过BPM汇报的交易细分（Transaction Breakdown），我们发现响应时间超时是服务器响应缓慢造成的。然后通过Sitescope故障排查，如果支撑网上营业厅的Web服务器和后台的数据库都没有异常，那就是应用服务器遇到了问题。
故障诊断
接下来通过Diagnostics对J2EE应用服务器进行分析。通过跟踪发现，网上营业厅应用与后台数据库通过JDBC建立连接的时间较长是导致最终应用响应超时的原因。再通过进一步分析，就会发现了故障根源是JDBC连接池缓冲区设置不够大的原因，就可以方便地解决问题。
方案效果
综合来看，该方案的顺利实施可为电信运营商带来如下明显效果：
以明晰的视图展示业务系统，针对不同管理人员，展示不同管理侧重；
从业务的角度主动管理整个企业内部的业务流程和应用；
提供了一种沟通手段，使得业务人员和IT运行维护人员能够互相沟通需求、问题，确定重要程度和优先级；
主动解决应用问题；
管理支撑业务系统的系统架构。