<% 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 %>
首页 > 铸锐论坛>应用性能管理 >降低无计划变化导致的IT风险

应用性能管理

 
  • 在服务器端进行数据库审计的优势
  • 服务器端审计工具与所谓非侵入性审计工具的比较
  • 如何提升运维管理
  • 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的有力武器





  • 降低无计划变化导致的IT风险
               www.InnovateDigital.com 整理

    1.  降低IT变化成本的良方:IT纪律和IT自动化

         如果IT组织对他们的应用交付和管理行动采用严格的纪律和自动化,那么可以消除大部分改变的成本。

    1.1应用交付

         很多应用故障是由于在开发和部署新应用和应用改变时缺少控制和纪律导致的。

         如果不能正确控制应用的计划,开发和部署,那么将导致:

    • 对其他组建或应用产生意外的副作用;
    • 由于不完善的版本控制,丢失改变的源代码或其他程序;
    • 由于错误的优化和没有在上线的压力下测试,出现上线的性能问题;
    • 由于费事且易于出错的手工部署的错误,出现混合或不兼容的上线版本.

         在应用生命周期的开发和部署阶段,进行小心细致的计划和控制可以消除这些问题。

    1.2计划

         严格的应用交付开始于计划。计划中经常会忽略的几个方面包括:

    • 影响性分析
    • 容量计划
    • 高可用性计划

         如果没有实施应用改变的影响分析,可能会导致意外的停机和性能问题。例如,为了满足一个业务变化对数据库模式作了一处简单的修改,可能也需要对其他模块进行改动。如果没有注意到这些改变而没有做相应的修改,就可导致错误的结果,糟糕的性能或应用的停机。这样的问题通过对应用改变的影响作仔细分析就可以很好地避免。最有效的影响性分析最好是使用自动化工具,该工具可以理解源代码和程序对象之间或其他应用组件之间的关系。

         缺少容量计划是另一个可能导致意外应用故障的问题。分析出在生产环境中可获得充足应用性能所需要的处理器,内存和其他资源等是非常重要的。例如,如果不能提供足够的计算资源处理预计的用户数量,那么就可能导致应用的性能问题和停机。

         最后,缺少为满足高关键应用的可用性而必要的冗余和快速恢复机制计划可能导致代价高昂和长时间的停机。某些故障是非常难以预料的。例如,硬件故障的发生通常没有前兆,并发生在极不方便的时间。IT组织必须为这些故障作计划,并且考虑高可用性体系结构和程序。

    1.3开发

         控制良好的开发过程为多种多样的应用故障提供了重要防线。应该组织这些过程保证所有重要的开发任务,例如说明,编码,优化和测试,能够正确执行。好的过程也需要在相关步骤上作严格的评审。这保证正确的检查和平衡能够捕获不适当或不正确的改变。版本控制是所有良好开发过程的关键环节。不充分的版本控制可能导致丢失源代码的改变,模块的混乱版本和丧失对运行的生产系统全面的信心。所有开发成果都应该在版本控制系统中仔细保留和管理,以防止覆盖重要的改变。

         功能的正确性,性能和扩展性的验证应该紧密地集成在开发过程中。大多数开发组织能够认识到验证软件功能正确性的重要性。而性能和扩展性的问题只是当在生产的负载下应用出现问题时才会注意到。这里需要特别强调的是,性能和扩展性需求应该在普通开发人员编码和测试中验证,同时也以应该在QA过程验证。关键应用交易应该使用分析工具进行准确测量。而且,应用性能也应该在生产级别的压力下测量。最好使用压力测试工具可以帮助你进行自动测试仿真适当的用户负载程度。

    1.4部署

         正确的控制也应该扩展到应用的上线部署阶段。通常,一个应用的更新版本需要在不同的系统上同时部署。另外,也可能依赖系统软件,运行时库和其他共享组件的不同版本。因此,局部或偶尔的部署可能导致错误,故障或糟糕的性能。

         围绕部署的问题通常与手工部署有关,因为手工容易出错。自动部署机制可以保证把正确的组件在正确的是件交付到正确的系统,以防止部署的灾祸。

    2.管理上线应用

         在应用交付中再多的计划和控制也不会消除应用的故障。即使最完善的质量控制过程也不会发现所有的缺欠。同时,最好的容量规划过程也不会预见到意外应用的使用。因此,需要以及时和主动方式管理应用的可用性和性能。

         早期的识别和解决方式的关键是减少应用问题的影响。通过正确的监测,很多应用问题可以在停机前被发现和解决。

         最终用户的体验监测是应用监测的重要部分。最终用户的响应时间应该一直被测量,并与现有的服务等级协议比较,在问题变得严重之前,能帮助识别和解决性能变化趋势。

          现在我们可以采用先进的技术帮助组织捕获,分析和回放完整地最终用户会话。这样的数据对于再现和诊断与应用功能相关的问题而言是非常重要的。这些技术可以被用来分析电子商务和其他自助服务Web应用的可用性问题。

          除最终用户的体验数据外,资源利用情况和性能数据应该根据应用技术栈的层次进行采集,包括Web Server,应用服务器,数据库和网络。这些数据可以在情况变得严重前提供有关问题的重要信息。例如,缺少一个索引导致的性能问题,只有在过量的表扫描时才能采集到特征数据。在对最终用户产生严重影响之前,表扫描监测应该很早就可以发现这个问题。与此类似,Java应用中的内存泄露问题往往很长时间都不会被发现,通过监测内存使用就可以在灾难之前发现这种问题。对相关组件(包括网络,操作系统,应用服务器,数据库和应用等)的细粒度监测和报警,通常可以在停机前发现应用的问题。

          即使采用最好的,能够尽早报警的系统,有时应用也会很快出现问题,导致严重的性能下降甚至停机。这时,公司才会切实感觉到销售额的下降或成本的显著上升。不幸的是,在这种情况下,诊断问题是很困难的。在当前的复杂应用环境中,一个问题可能与很多变化的因素有关。下面是一些造成应用响应时间突然下降的可能原因:

    • 更改应用代码后未经优化
    • 未经优化的SQL语句
    • 意外删除的索引
    • 意外的数据库资源竞争
    • Java内存泄露
    • Web服务器进程数量过多
    • 网络性能问题

         识别像上面的这些困难问题可能需要多种IT技术。重要的是技术人员应该方便地掌握恰当的数据以便快速缩小问题的可能性。技术人员应该能够快速察看应用,应用服务器,数据库,Web服务器,操作系统和网络的性能和资源特征,并可将这些数据与具体的交易响应时间的下降相关联进行综合分析。拥有合适的工具以简明的方式提供数据时快速解决问题的关键。

    3.结论

         商业组织必须不断地适应变化的市场环境。这给IT部门带来很大压力,必须保证公司的应用系统可以支持全面的战略方向。因此,将面对更为复杂的一个用环境。没有正确的控制和管理,应用环境的持续改变将导致糟糕的应用性能和停机。对于一个组织来说,这些问题意味着销售额和生产效率的大幅降低。Gartner估计任务关键应用的每小时停机成本是42,000美元。而通过在应用的整个生命周期(从开发到生产)中采用严格的方法,可以避免大量的损失。采用适当的工具,谨慎地控制工作流程可以俄日大多数IT部门节省巨额成本。


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

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