<% if session("name")<>"" then response.write("当前用户:"&session("name")) response.write("  注销") response.write("  修改资料") else if request.cookies("name")<>"" then response.write("当前用户:"&request.cookies("name")) response.write("  注销") response.write("  修改资料") end if end if %>
首页 >经验与观点>技术管理 >应用管理的概念和流程

应用性能管理

 
  • 在服务器端进行数据库审计的优势
  • 服务器端审计工具与所谓非侵入性审计工具的比较
  • 如何提升运维管理
  • ITIL提升中国电信运维管理系统建设
  • 提高Java性能的几个高效用法
  • 提高J2SE性能的代码技巧(上)
  • 提高J2SE性能的代码技巧(下)
  • 应用管理的概念和流程
  • 应用管理的运营和优化
  • 开源时代:Navicat实现从MS SQL到MySQL的数据迁移
  • 使用Navicat导入数据到MySQL
  • 单元测试中贯彻持续性能管理
  • 单元测试性能分析报告
  • 利用Hyperic HQ管理WebLogic
  • Hyperic HQ监测Linux系统10条最佳成功经验
  • 什么是服务等级管理
  • 服务等级管理的步骤
  • 服务等级管理中的关键控制要素
  • 服务等级管理中需要注意的几个问题
  • 什么是容量管理
  • 容量管理的几个重要环节
  • 容量管理中的关键控制要素
  • 容量管理中需要注意的几个问题
  • 持续性能管理的先决条件
  • SQL Server调优的五个步骤(上)
  • SQL Server调优的五个步骤(下)
  • J2EE性能问题的分析
  • J2EE性能问题的诊断
  • J2EE性能问题的诊断示例
  • 应用性能管理-从操作系统做起
  • SQL Server常见性能问题的优化
  • 应用性能管理(APM)的价值分析
  • Bea WebLogic Portal的性能监测和诊断
  • 数据库性能基准的五个问题
  • Portal的性能挑战
  • 在多种数据库环境下管理业务需求(下)
  • Oracle DBA如何管理DB2(下)
  • 在多种数据库环境下管理业务需求(上)
  • Oracle DBA如何管理DB2(上)
  • SQLServerSQL调优技巧
  • 诊断应用数据库的性能瓶颈
  • Oracle优化的五个方面
  • Microsoft的优化SQL方法
  • 理解SQL Server的SQL查询计划
  • 自动化性能测试
  • 优化应用质量和性能,支持和推动业务发展
  • 从PMO到CIO办公室—PMO的发展趋势
  • 实施自动化功能测试的解决方案
  • 软件自动化测试流程
  • 测试自动化的成功经验
  • 无计划的变化导致的IT风险
  • 降低无计划的变化导致的IT风险
  • 应用性能管理中的价值链分析
  • 应用系统"亚健康"的严重性
  • 应用系统"亚健康"现象和原因
  • 性能测试的准备
  • 性能测试的六个阶段
  • 性能测试的容量评估
  • 优化DB2数据库的十个最佳实践
  • 优化DB2数据库的十个最佳实践(续)
  • 在生产中监测和优化J2EE应用性能
  • 改善J2EE性能和用户体验的管理变革
  • 跟踪数据库性能变化
  • 优化ERP应用
  • 在生产中测量J2EE应用性能
  • Oracle SQL性能优化技巧1
  • Oracle9i查询优化工具初探
  • APM的方法和技术实现
  • J2EE性能问题的症状和优化
  • 构造高性能J2EE应用10个技巧
  • 软件工程与知识管理

     
  • 采用CASE工具管理多个并行应用软件开发项目
  • "软件工程"中的分工有效吗?
  • 实施知识管理软件的几个细节
  • 拯救知识管理
  • 知识管理与知识管理软件
  • IT培训师指要
  • 推荐产品的使用

     
  • Toad快速入门
  • PerformaSure J2EE性能诊断
  • PerformaSure J2EE健康检查示例
  • Spotlight实时诊断WebSphere Server实践
  • Spotlight实时诊断WebLogic Server实践
  • JProbe实践之"性能瓶颈"
  • JProbe实践之"短期对象循环"
  • JProbe实践之"内存泄露"
  • JProbe实践之"代码覆盖"
  • Quest Jprobe最佳实践(上)
  • Quest Jprobe最佳实践(下)
  • Foglight-APM与SLA的有力武器




  •  应用管理的概念和流程


            www.InnovateDigital.com 整理

          

    应用管理概述


          企业运作其中的外部环境要求企业及其IT部门能够对外部挑战做出快速的反应,并实施变更。

          IT部门不仅应该支持企业对外部环境所需要的灵活性,还应该帮助提高这种灵活性。这给负责维护支持业务正常运作的应用系统的IT部门提出了极大的挑战。由于应用系统的引入使得其有可能承担组织内大部分的业务流程,这就迫使企业有必要通过应用管理(Application Management)将其所使用的应用系统作为公司资产管理。

          

    应用管理的概念

          应用管理(Application Management)是流程和活动的组合,它描述了在应用系统的整个生命周期(包括运营和维护)对其所进行的管理。该生命周期包括了应用开发和服务管理流程两部分(解释如下)。

          

    应用管理的流程

          

    管理业务价值

          为企业创造价值的不是技术,而是技术得以部署从而满足业务需求的方式。通过在规划和实际创造的IT的业务效益的过程中实施应用管理,应用系统可以支持大部分的业务需求。


    1.整合业务和IT

          整合业务需求和IT主要是在应用管理流程中进行的。必须建立业务和IT管理规划和评审流程,据此业务负责人和IT管理人员可以识别企业内部的业务功能(业务单元和部门),也可以了解那些处于变化之中的业务流程和业务目标。这个管理规划流程对于实现IT和业务的整合是非常关键的,并有助于对IT应用系统的开发和部署进行规划和支持IT基础设施。 规划流程应该使用一种建筑学的方法根据组织的业务功能描述现有的和需要的IT服务和应用系统。

    2.高级别的业务和IT体系结构

          组织需要制定适当的业务和IT体系结构来指导IT的开发以支持组织的业务功能。该体系结构的范围可由战略整合目标模型(SAOM)来表示。

          战略整合目标模型是基于这样一个原理,即业务流程是由应用系统来支持的,而应用系统又构成了下面模型中右边的关键业务驱动因素和服务级别协议(SLA's)以及运营级别协议(OLA's)之间的关系。

    Application _Management

          

    战略整合目标模型图

          战略整合目标模型中各组件之间的特性可以由图中所示的实体联系图来表示。

          战略整合目标模型提供了一个很好的工具来根据业务驱动因素和应用需求显现关键业务功能与IT服务与能力之间的关系。

    3.关键业务驱动因素和SMART目标

          支持应用管理生命周期控制的前提假设是关键业务驱动因素,可定义如下:

          关键业务驱动因素是决定一个业务流程的实施和绩效从而确保组织的战略目标能够实现的某些属性。

          定义关键业务驱动因素是一种ITIL最佳实践的作法。他们控制了企业愿景和使命的实现情况。对这些关键业务驱动因素统一地加以考察,有助于对那些全企业都应该集中精力去做好的事情形成一个普遍的认识。无论一个公司怎样定义其关键业务驱动因素,它们都应该具有如下表所示的几项公共特征。

          

    表 SMART业务驱动因素

          

    S Specific具体化
    M Measurable可量化
    A Agreed to一致认可
    R Realistic切合实际
    T Time Specific具有明确的时间

          上述SMART属性不应仅限于关键业务驱动因素,而应该拓展至由这些关键业务驱动因素所推导出的目标和需求。尽管SMART概念在设定目标(包含关键业务驱动因素)方面并不是一个创新,但仍然没有得到一贯的应用。许多项目没有成功的完成,也是因为这些项目都基于一些模糊的或定义不清的目标。

          这里的挑战就在于如何将关键业务驱动因素与应用管理生命周期结合起来,从而对整个生命周期的结果加以控制。

    4.组合管理和应用组合

          大多数企业都有许多应用系统在其业务流程中支持其业务功能。组合管理(Portfolio Management)是应用管理规划流程的一部分,它帮助企业管理大型和复杂的应用系统,帮助了解这些应用系统在数据共享、支持端到端业务流程以及对IT基础设施的使用方面是如何协同工作的。

          应用组合可被视为一个可以存储大部分应用属性和提供一个关于应用系统之间关系的结构图的信息系统。应用组合还可以提供有关特定的应用系统或应用系统套件的信息,还可帮助了解一个应用系统与另外一个应用系统发生关联的方式。这使得可以更早地规划业务驱动性的变更以及更快地做出有关的投资决策。

    5.准备就绪评估和交付战略

          许多IT部门在不具备构建和管理复杂应用系统的能力的情况下就开始安装一些复杂的应用系统。因此,规划流程必须要确保有一个胜任的部门来创建和管理应用系统,该部门要能够维持必要的人员、流程和技术。

          安装复杂的应用系统,无论是定制的还是统一封装的,都需要规划一个开发良好的协调系统来确保组织能够控制开发团队之间的合作以及对应用开发和管理指南的遵守。引进新的技术要求IT部门具有足够的灵活性,从而能够尽快地吸收新的信息并将不熟悉的技术嵌入组织的方法和流程中去。能力评估和成熟度模型,如CMM,通常被用来确定一个IT部门可以开发或支持复杂的应用系统的准备就绪度。

          在应用系统的购买或支持过程中利用第三方供应商可以提供另一种应用系统交付战略,在规划业务应用和应用基础设施产品组合时值得考虑。

    6.集成应用管理生命周期

          应用开发和应用管理之间通常具有很大的区别。在应用管理生命周期方法下,应用开发和服务管理紧密结合在一起,对它们的活动也需要加以协调。

          ITIL中的应用管理主要是基于服务管理角度的。对IT服务提供具有重大影响的服务管理方面的问题在应用管理生命周期早期阶段就应该得到处理。最重要的一个方面是需要在整个生命周期各个阶段都实现基础性支持结构和工具的更好的集成。为了实现服务创建和提供之间更好的契合,需要下列信息:

          

    • 应用组件及其相互依赖关系;
    • 规划中的应用发布;
    • 规定可以表明一个应用系统的状态和绩效的警报与事件;
    • 规定用于监控一个应用系统的主要交易的具体指标;
    • 服务级别;
    • 运营需求;
    • 支持需求。

          为了补充与应用管理相关的信息,通常有必要通过应用组合、应用体系架构和应用框架来定义一个应用系统是如何与其他应用系统以及应用基础设施发生关联的。这将取得如下效益: ·可以加强应用开发、基础设施开发和服务管理三方之间对其相互依赖关系的互相了解,从而确保在应用管理生命周期早期就做出审慎的决策;

          

    • 从第一次设计大纲到最后的部署,实现完整的应用规划;
    • 有关能力和绩效的数据可以较早地纳入应用管理生命周期,从而能够为引进应用系统做好基础设施方面的准备;
    • 对开发、测试和运营环境的管理得到控制,从而极大地减少了定义、构建、变更和终止上述各种环境的成本;
    • 可以开发参考体系结构和框架,从而使创建服务(如推出服务时间)和服务提供(如可用性)两方面的需求都得到了考虑;
    • 为阶段转换定义绩效指标时开发人员和服务经理可以使用一种共同的语言;
    • 开发人员在构建应用系统时可以考虑服务经理的需求,从而使应用系统在移交以前可以得到管理。

    7.贯穿应用管理生命周期

          由于应用管理具有反复进行的特性,一个应用系统在任一个时间点上都可能同时处在多个应用管理生命周期的多个阶段上。这需要严格的版本控制、配置管理和发布管理。这些问题基本上都包括在《ITIL服务支持》一书中。取决于所选择的开发方法的不同,一个应用系统在某几个阶段的进展可能比其他阶段要快得多。同样,一个应用系统在部署前可能经历了几个完整的应用管理生命周期。然而,所有的应用系统在其生命周期内都必须多次经历应用管理生命周期的所有阶段。

          组织需要测度一个应用系统在其生命周期内的效果和效率。流程中的变更和应用管理生命周期内各阶段之间的信息交流对应用系统的质量具有一定的影响。正确地评价每个阶段的原有特性以及某个阶段内的决策是如何影响其他阶段的活动对于应用管理生命周期内的综合管理方法是至关重要的。这种评价以及相应的行动在很大程度上决定了方法和工具的选择。

          在应用管理中还需要考虑应用系统的使用寿命。维护的效果和效率受到文档记录质量的影响,而文档记录的质量又受到用于分析、设计和开发的技巧、方法和工具的影响。有些应用系统在组织愿意停用或替换之前很长一段时间可能已经过时了,这就产生了相应的维护问题。

    8.其他生命周期模型

          这里陈述的生命周期是指用于应用管理生命周期中的一种重复性的方法,如在应用开发中用到的RAD和RUP。也有一些传统的应用开发方法,如瀑布法,但这些方法一般都不鼓励使用重复和递增步骤。

          使用重复性方法的主要原因是将与传统开发方法相关的风险减小到最低。这种使用递增步骤的方法意味着,一个应用系统需要在许多小步骤中逐渐交付。这种方法的优点在于,对于应用开发期间由不确定性引起的风险更易于管理。针对某些需求推出相应服务的时间也被降低了。

    (北京铸锐数码科技有限公司 www.InnovateDigital.com)


     
    北京铸锐数码科技有限公司 版权所有 © 2008
    中国·北京市海淀区大钟寺13号华杰大厦8A9-2室
    邮编 100098 电话 010-62139280 传真 010-62135268    京ICP备05019494