论文部分内容阅读
在IT投资庞大之后，如何尽可能释放它的效能成了企业CIO们最操心头痛的事。
“一辆正在行驶的汽车，您被告知它的速度是120英里／小时，但事实上只达到了80英里／小时，找不到问题只能干着急”，这一幕一定会让不少企业的系统维护人员产生共鸣，如何找回那丢失的40英里／小时，这就是应用性能管理的使命。
性能跟不上应用的扩张
今天，IT企业不得不面对这样的窘境：用户一面享受着各种复杂的应用，一面又追逐着更高的性能。然而随着应用复杂度在不断地爬坡，系统性能的提升就显得更加举步为艰，两者间的微妙关系，还真的一言难尽。
众所周知，信息技术现已成为企业核心竞争力的一个重要组成部分，是业务成败的决定因素。信息技术通过不断地技术创新，一方面不断完善自身的体系结构和实施手段；另一方面，它引导新业务模式的产生，成为生产力提升和变革的原动力。正是由于信息技术对于企业经营模式，乃至整个社会沟通方式所产生的显著而巨大的影响，它已经从一个辅助性的角色，转变成为众人所瞩目的重点话题。
让我们把目光从整个社会的大范畴聚焦到一个企业，信息技术的发展已经到了一个极致。7x24的全天候访问，跨越软硬件平台的无限可扩展性，简单、一致的用户自助服务界面……诸如此类的苛刻要求，都是为了满足业务部门”更快、更高、更强”的要求而制定的。然而，在信息系统满足了上述的种种要求之后，其自身的结构也变得异常的复杂。
在一个典型的企业应用环境中，从后台的硬件存储开始，往往要通过数据库，应用服务器、Web服务器和客户端应用几个技术层次来实现业务操作，其中还会由若干承担具体任务的中间件产品和技术扩展，来提供诸如均衡负载、高可用性、可伸缩性等企业计算所必须具备的功能。
如此复杂和功能强大的信息系统为企业业务目标的实现提供了技术上的保障，然而，这还不足以实现提高生产力的最终目标。一个企业应用的评估标准应该有两个，一个是可实现性，一个是运行效率。对于前者，我们通过基础架构和技术组件来达成，而后者，传统的实现方法是通过专门的维护团队来保证的。对单一类型的应用而言，“效率”，也就是“性能”，通过这种方式，是能够得到保证的。无论是数据库，还是应用服务器，乃至在更加复杂的定制应用和打包应用领域，都有厂商或者集成商的专业技术人员来为之提供支持服务。对于用户而言，无论是依靠厂商的服务，还是自己拥有的系统维护团队，对于单一类型的应用系统尚且能够确保性能。然而，随着特定技术之间的交叉、融合，只单纯掌握一种技能的维护人员已经越来越难以应付系统性能所提出的挑战，再者，庞大的维护队伍显然将带来另一种压力。
基于Web，有喜有悲
在进入21世纪之后，随着Web技术成为数据展现和操作访问的事实标准，企业利用这个平台，将原来分散的子系统进行整合。尽管应用整合可以通过多种手段来实现，但J2EE的出现，由于其天生具备良好的开放型和可扩展性，使之在应用整合和开发的过程中发挥了愈来愈显著的优势。
采用J2EE技术部署基于Web的应用，已经显著改变了服务的基本经济原则、竞争力和用户界面。基于Web的应用迅速代替成本更高的“人员协助”传统服务。这种新一代应用为企业提供了独一无二的机会，使之能够利用传统系统，在多个服务“层”之间分配应用，充分利用新计算技术的优势。虽然这些基于Web的应用为公司提供了无与伦比的灵活性，但却使所在的基础设施面临不断地改变和超高的负载，应用性能的下降所导致的不良用户体验，反而降低了客户的满意率和忠诚度。
当今的用户都期望能在世界各地随时访问网站。如果应用的用户发现屏幕底部的蓝色进度条从左到右前行的速度过慢，他们就会离开该网站，而且通常不会再次访问。同样，如果服务水平没有达到期望值，现有客户端通常会重新使用陈旧的、高成本的旧应用来处理业务，或者开始关注其他供应商或服务。从而，企业的管理者认识到，由于目前业务对于信息系统的依赖性，如果不能遏制应用性能下降导致的客户流失，如果不能克服复杂性所导致的迟缓的故障排查，对于J2EE在内的新技术的使用都会适得其反，导致业务的下滑。
应用性能管理的使命
就在人们对于应用性能逐渐缺乏耐性的时候，一种对于应用性能进行监控、报告、分析，改进以及趋势预测的技术应运而生，我们把这类技术成为应用性能管理(Application Perfor-mance Management，APM)。
应用性能管理究竟会为我们的系统性能带来怎样的改变?也许英国电信的互联网业务部的亲身经历更有说服力。两年前，他们开发了一款全新的尖端网络中心系统称之为BT Openworld，用以提高ISP的性能和可用性，改进客户体验。而这款网络中心系统同样面临性能管理的挑战。“我们的团队认识到，系统并没有达到最佳运行状态，客户订单经常不能在协议规定的交付时间执行，而且需要不断对系统进行人工调节，负责处理订单流程的人员还要负责不断地以手工方式进行系统调优、打补丁和风险管理，”回想起那段日子，负责系统运行维护的经理Neal Kelshaw觉得苦不堪言，而现在，这一切一去不返，他接着说，“当VERITAS i3完全投入使用的第一天，它就找出了问题的确切原因：设备数据库中存在一个Oracle性能问题，该问题影响了系统的容错性，导致订单排队的失败。我们及时解决了该问题，这应该归功于应用性能管理。”两相比较，Neal Kelshaw显然更信任应用性能管理。
其实Neal Kelshaw的遭遇只是冰山一脚，很多系统管理人员都面临这样或者那样的性能问题。而更让人揪心的是他们看得到症状，却找不到根源，因此越来越多的人寄希望于各种APM软件。然而APM毕竟不同于一般的性能调优工具，他需要有完善的方法论和解决方案作为保障，这是每一个用户应该首先明确的。我们可以从四个层面来解读APM的使命：
一、APM着眼的是应用系统整体的性能管理，而非仅仅针对某个技术层次的“烟囱式”的解决方案。
从性能指标的检测开始，APM就是以最终用户的响应时间为主要的衡量标准，在第一时间将问题定位于某个技术层次在问题得到修改之后，它也会从应用整体响应时间的角度，测量改进之后的性能。
二、APM的视野不仅足够宽广，而且足够深入。
对于每个技术层次，APM都能够溯本求源，准确定位导致性能下降的根本问题。而且，它提供专家级的建议，通过最佳实践帮助使用者尽快进行修复。
三、APM考察应用系统的性能依据，来自于用户的真实操作数据。
同比传统性能调优工具使用的模拟数据，APM才能够收集到用户实际的体验，将使用习惯，业务波动和技术指标综合考虑。显而易见，这种数据只能来自于生产环境，而APM依靠其对于应用超低的负载，能够实施7x24的长期监控，是那些产生高额负载的性能调整工具所不能比拟的。
四、APM拥有专门的数据存储。
APM将采集的数据经分析之后存放起来，而非在考察之后就抛弃，或者仅仅保留短时间的性能数据。只有这样，使用者才能够通过对于长时间的历史记录的分析得到结论，从而了解过去曾经发生过什么，现在正在发生什么，以及今后即将发生什么。这就使得，APM不仅仅是一个在性能问题出现后进行补救的工具，而且能够为系统的维护团队提供预警信息，在性能问题真正开始影响用户的使用之前，就将其改正，保证为用户提供一个性能可靠，坚如磐石的应用系统。
“一辆正在行驶的汽车，您被告知它的速度是120英里／小时，但事实上只达到了80英里／小时，找不到问题只能干着急”，这一幕一定会让不少企业的系统维护人员产生共鸣，如何找回那丢失的40英里／小时，这就是应用性能管理的使命。
性能跟不上应用的扩张
今天，IT企业不得不面对这样的窘境：用户一面享受着各种复杂的应用，一面又追逐着更高的性能。然而随着应用复杂度在不断地爬坡，系统性能的提升就显得更加举步为艰，两者间的微妙关系，还真的一言难尽。
众所周知，信息技术现已成为企业核心竞争力的一个重要组成部分，是业务成败的决定因素。信息技术通过不断地技术创新，一方面不断完善自身的体系结构和实施手段；另一方面，它引导新业务模式的产生，成为生产力提升和变革的原动力。正是由于信息技术对于企业经营模式，乃至整个社会沟通方式所产生的显著而巨大的影响，它已经从一个辅助性的角色，转变成为众人所瞩目的重点话题。
让我们把目光从整个社会的大范畴聚焦到一个企业，信息技术的发展已经到了一个极致。7x24的全天候访问，跨越软硬件平台的无限可扩展性，简单、一致的用户自助服务界面……诸如此类的苛刻要求，都是为了满足业务部门”更快、更高、更强”的要求而制定的。然而，在信息系统满足了上述的种种要求之后，其自身的结构也变得异常的复杂。
在一个典型的企业应用环境中，从后台的硬件存储开始，往往要通过数据库，应用服务器、Web服务器和客户端应用几个技术层次来实现业务操作，其中还会由若干承担具体任务的中间件产品和技术扩展，来提供诸如均衡负载、高可用性、可伸缩性等企业计算所必须具备的功能。
如此复杂和功能强大的信息系统为企业业务目标的实现提供了技术上的保障，然而，这还不足以实现提高生产力的最终目标。一个企业应用的评估标准应该有两个，一个是可实现性，一个是运行效率。对于前者，我们通过基础架构和技术组件来达成，而后者，传统的实现方法是通过专门的维护团队来保证的。对单一类型的应用而言，“效率”，也就是“性能”，通过这种方式，是能够得到保证的。无论是数据库，还是应用服务器，乃至在更加复杂的定制应用和打包应用领域，都有厂商或者集成商的专业技术人员来为之提供支持服务。对于用户而言，无论是依靠厂商的服务，还是自己拥有的系统维护团队，对于单一类型的应用系统尚且能够确保性能。然而，随着特定技术之间的交叉、融合，只单纯掌握一种技能的维护人员已经越来越难以应付系统性能所提出的挑战，再者，庞大的维护队伍显然将带来另一种压力。
基于Web，有喜有悲
在进入21世纪之后，随着Web技术成为数据展现和操作访问的事实标准，企业利用这个平台，将原来分散的子系统进行整合。尽管应用整合可以通过多种手段来实现，但J2EE的出现，由于其天生具备良好的开放型和可扩展性，使之在应用整合和开发的过程中发挥了愈来愈显著的优势。
采用J2EE技术部署基于Web的应用，已经显著改变了服务的基本经济原则、竞争力和用户界面。基于Web的应用迅速代替成本更高的“人员协助”传统服务。这种新一代应用为企业提供了独一无二的机会，使之能够利用传统系统，在多个服务“层”之间分配应用，充分利用新计算技术的优势。虽然这些基于Web的应用为公司提供了无与伦比的灵活性，但却使所在的基础设施面临不断地改变和超高的负载，应用性能的下降所导致的不良用户体验，反而降低了客户的满意率和忠诚度。
当今的用户都期望能在世界各地随时访问网站。如果应用的用户发现屏幕底部的蓝色进度条从左到右前行的速度过慢，他们就会离开该网站，而且通常不会再次访问。同样，如果服务水平没有达到期望值，现有客户端通常会重新使用陈旧的、高成本的旧应用来处理业务，或者开始关注其他供应商或服务。从而，企业的管理者认识到，由于目前业务对于信息系统的依赖性，如果不能遏制应用性能下降导致的客户流失，如果不能克服复杂性所导致的迟缓的故障排查，对于J2EE在内的新技术的使用都会适得其反，导致业务的下滑。
应用性能管理的使命
就在人们对于应用性能逐渐缺乏耐性的时候，一种对于应用性能进行监控、报告、分析，改进以及趋势预测的技术应运而生，我们把这类技术成为应用性能管理(Application Perfor-mance Management，APM)。
应用性能管理究竟会为我们的系统性能带来怎样的改变?也许英国电信的互联网业务部的亲身经历更有说服力。两年前，他们开发了一款全新的尖端网络中心系统称之为BT Openworld，用以提高ISP的性能和可用性，改进客户体验。而这款网络中心系统同样面临性能管理的挑战。“我们的团队认识到，系统并没有达到最佳运行状态，客户订单经常不能在协议规定的交付时间执行，而且需要不断对系统进行人工调节，负责处理订单流程的人员还要负责不断地以手工方式进行系统调优、打补丁和风险管理，”回想起那段日子，负责系统运行维护的经理Neal Kelshaw觉得苦不堪言，而现在，这一切一去不返，他接着说，“当VERITAS i3完全投入使用的第一天，它就找出了问题的确切原因：设备数据库中存在一个Oracle性能问题，该问题影响了系统的容错性，导致订单排队的失败。我们及时解决了该问题，这应该归功于应用性能管理。”两相比较，Neal Kelshaw显然更信任应用性能管理。
其实Neal Kelshaw的遭遇只是冰山一脚，很多系统管理人员都面临这样或者那样的性能问题。而更让人揪心的是他们看得到症状，却找不到根源，因此越来越多的人寄希望于各种APM软件。然而APM毕竟不同于一般的性能调优工具，他需要有完善的方法论和解决方案作为保障，这是每一个用户应该首先明确的。我们可以从四个层面来解读APM的使命：
一、APM着眼的是应用系统整体的性能管理，而非仅仅针对某个技术层次的“烟囱式”的解决方案。
从性能指标的检测开始，APM就是以最终用户的响应时间为主要的衡量标准，在第一时间将问题定位于某个技术层次在问题得到修改之后，它也会从应用整体响应时间的角度，测量改进之后的性能。
二、APM的视野不仅足够宽广，而且足够深入。
对于每个技术层次，APM都能够溯本求源，准确定位导致性能下降的根本问题。而且，它提供专家级的建议，通过最佳实践帮助使用者尽快进行修复。
三、APM考察应用系统的性能依据，来自于用户的真实操作数据。
同比传统性能调优工具使用的模拟数据，APM才能够收集到用户实际的体验，将使用习惯，业务波动和技术指标综合考虑。显而易见，这种数据只能来自于生产环境，而APM依靠其对于应用超低的负载，能够实施7x24的长期监控，是那些产生高额负载的性能调整工具所不能比拟的。
四、APM拥有专门的数据存储。
APM将采集的数据经分析之后存放起来，而非在考察之后就抛弃，或者仅仅保留短时间的性能数据。只有这样，使用者才能够通过对于长时间的历史记录的分析得到结论，从而了解过去曾经发生过什么，现在正在发生什么，以及今后即将发生什么。这就使得，APM不仅仅是一个在性能问题出现后进行补救的工具，而且能够为系统的维护团队提供预警信息，在性能问题真正开始影响用户的使用之前，就将其改正，保证为用户提供一个性能可靠，坚如磐石的应用系统。