本文讨论了在ERP，CRM，电子商务和定制的应用环境中治理可用性，性能和应用服务等级时所面临的问题。本文的目标读者是负责应用可用性，性能，服务等级和容量计划的业务和IT治理人员。文中涉及到下面的IT基础架构部分：MIS，应用/Web治理和电子商务等。
概述
在当今的财富1000强公司中，IT部门一直面临巨大压力，他们必须提供有可靠价值的技术服务以支持公司业务的发展。公司希望IT部门在现有或更少的人员和资源的情况下能够向业务用户提供给有的或更好的应用服务等级。同时企业通过实施IT应用在内部部门，合作伙伴，供给商和电子商务客户之间持续优化业务过程并提高效率。所有这些将给IT部门带来更多压力。
此外，这些应用具有复杂的多层的体系结构，运行着多种操作系统和一系列相互依靠的防火墙，服务器，操作系统，进程，Web服务器，J2EE应用服务器，数据库和一些其它子部件等。
然而，用户并不关心这些治理应用基础架构的复杂性。用户主要关心的是系统在一个可预知时间内是否能够完成一个业务过程，是否能够更新工资单，查找客户信息或查找网站并下订单等。是否能够成功完成业务过程是应用可用性的起码要求－要么能完成要么不能。性能问题或可用性的不足都可影响生产效率，收入和用户信心--也许是最重要的。
在建立应用服务等级治理时，业务和IT部门应该考虑使用业务过程的性能。使用基于业务过程应用服务等级，业务治理人员可以使IT部门承担更多的责任，IT部门可以通过比较具体业务过程或业务过程的组合随时测定服务质量的可用性和变化。
应用服务模型将业务过程映射到具体IT资源和应用组件上。基于业务过程的应用服务等级与应用服务模型相结合给业务和IT部门带来很多好处。本白皮书讨论了实现这个模型的挑战和机制，并提出了下面这些要害问题：
为什么对业务过程性能的测量比对传统的设备或服务器的测量能更精确地反映应用服务的可用性。
为什么要将业务过程映射到具体的IT应用基础资源，例如Web服务器，J2EE应用服务器和数据库服务器。
业务过程性能:测量应用服务可用性的一个更好方法
用于测量应用服务的传统方法各有不同，这主要取决于企业文化，业务目标和应用基础架构的规模等。一些企业使用了商业化的系统监测产品，定制开发的脚本，或两者组合使用来监测应用中所包含的操作系统进程是否在正常运行。这些产品往往依靠操作系统的工具如ping，vmstat，df，top和perfmon测定进程的可用性。
假如组成应用的网络，操作系统，和操作系统进程运行正常，我们就可以假定应用的运行是正常的。这些观察方式都是测量应用服务等级性能的间接方法，没有考虑到在一段可预知的时间内或从不同的地域位置实际执行完成业务过程的能力。直到最近，这些间接方法仍然是用于测量应用服务等级最常用的方法，因为我们还不具备在一段时间范围内直接并可靠地测量业务过程的能力。
现在，技术已经成熟可靠，我们可以通过记录业务过程并反复回放的方式模拟用户的业务过程。这些被记录的业务过程可以被部署到指定的地方并且可以监测到业务过程的可用性和反应时间。
业务过程是应用交付的最终产品，代表了应用服务可用性的一种直接测量方法。因此业务过程应该被用来确定应用服务等级。在实现基于Web的业务流程模拟之前，对用于记录和回放业务过程的产品应该包括下面的一些功能：
显示一个完整的基于Web业务流程的总反应时间，以及具体到每个用户操作步骤或动作（如登录，搜索产品，购买产品，注销）的具体时间。
估计严重或致命性能等级的期望反应时间。
在用户每步操作之间以间断和不间断两种方式重新执行整个业务过程。
将已记录的脚本部署到外部的自动化机器上，然后以自动方式反复执行。
将已记录的脚本自动地存储到一个中心目录中。
统一处理服务器和后端应用的可用性和性能信息。
提供一个中心数据库存储和使用所产生应用服务报告。
将业务过程映射到具体的应用基础资源
用户确切想要的是-从任何位置以可预知性能持续不断地运行业务过程。保证性能的下一个逻辑步骤是把业务过程性能正确地映射到具体的IT层次和组成应用基础架构的组件，包括性能信息和影响Web，应用和数据库服务器的事件。
将业务过程映射到应用基础架构这一中心概念是以应用技术栈为基础的。所有的应用都能分解成如下表所示的组件层次。这些层次是有次序的，从下到上表示从网络到操作系统，再到应用，集成组件和业务过程的路径。重要的一点是业务过程与应用栈的每一层次都是有关的，因此必须把它们联系在一起考虑，才能对性能有全面的理解。
表1：应用栈。由于业务流程必然要使用栈中的各个层次，所以业务流程层次准确地反映了应用的业务流程可用性。
