用商业方式管理IT范文

从技术角度管理IT

“20世纪90年代是一个由技术驱动业务的时代,”美国USAA保险公司首席运营官(COO)TimHandren说:“在那个时候,像我这样热衷于追求先进技术的狂热者在企业里可以做任何我们想做的事情,那真是我们的梦想天堂呀!”但是,TimHandren后来发现在此期间,一个令人可怕的问题正在慢慢滋生,并且逐渐暴露了出来:USAA公司的IT投入在疯狂上涨,而公司业务的增长速度却远不及此。1998年,USAA公司的业务利润增长了5%,而IT成本却上涨了10%;而在紧接着的1999年,其业务利润提高了9%,IT开支竟剧增了19%。而与此同时,在USAA公司两个已经持续了数年而且投资都已经分别超过1亿美元的IT项目也夭折了。USAA公司CIOYates说:“公司预算在不断攀升,而我们所提供的服务却在下降,这是一件多么可怕的事情呀!”同样,在今天的中国,这样的现象并不少见:软件系统越来越庞大、服务器越来越多、存储空间越来越膨胀、网络也越来越复杂,但是企业的服务水平和业绩却并没有随着IT的膨胀而水涨船高。从运转的情况来看,也许很多人都能感觉到系统的性能存在问题,例如在银行,营业厅提交操作请求时响应速度非常慢,进而影响了客户的满意度,这是很多人都能感觉到的。但是现实情况往往是经过IT部门相关专家的仔细测试,数据库专家认为Oracle数据库一切运转正常,存储专家认为磁盘响应速度也很正常,网络专家则认为网络带宽的利用率也不存在任何问题,服务器专家同样认为各项技术参数都没有超出警戒值。为什么“一切正常”但是整体性能却不理想呢?于是CIO很自然地想到了一个原因,那就是系统需要更新了,或者需要增加新的设备了,于是新一轮的采购和实施开始了。如此往复,直至无穷……

正像USAA公司CIOYates所说的那样,这是一件可怕的事情,是企业的噩梦!这种由信息技术推动而不是由业务需求驱动的信息化建设与发展,并且不对信息系统的效益进行评估,最终的结果必然造成大量不必要的IT投资,这样就会产生“非理性的繁荣”。当这种“繁荣”的泡沫大到一定程度时,泡沫就会破裂,产生的后果可能需要人们用几年、几十年的时间去偿还。互联网泡沫的产生很大程度上就是由于这个原因。

解决IT投入产出失调的关键应该在于让CIO的眼光从“技术”转移到“业务”,让CIO与CEO用同一种业务语言进行沟通。

从商业角度管理IT

其实,CIO所看到的“一切正常”只是技术参数的一切正常,而某一个技术参数所反映的仅仅是一个非常微观的局部特征,即使所有的这些技术参数都表现得很正常,也只能说明系统中每一部分都没有问题,并不能说明系统整体运转正常。而且,单纯通过这些技术参数值并不能很容易地发现造成系统整体性能下降的原因所在。这种管理IT的方式,我们姑且称之为“从技术角度管理IT”的方法。

但是,从理论的角度来看,如果能够获取足够多的技术参数值,那么结合企业需要达到的业务性能,通过对这些数值进行有效分析,是可以找到系统的瓶颈所在的。不过,这里显然有两个前提,一个是获取到足够充分的而且准确的技术参数值,另一个是对数字的分析要结合企业对业务性能的要求。首先看第一个前提,为了达到“充分”的目的,需要设定尽可能多的考核参数,对于一个庞大的企业级系统来说参数的个数少则数百项,多则成千上万,那么要准确获取这些参数相应的数值,就需要在业务运行的峰值时期,在同一时间获取。这样的条件对于往往只有数十人的IT部门来讲,可以说是不可能完成的任务,别的且不说,单就业务峰值的模拟都难以实现,因为对于像银行、电信这样的企业级系统来讲,每秒钟处理的交易数就可能数以万计,这又怎么可能通过人工模拟呢?其实,这些还不是最主要的,我们假设能够获取相应的参数值,那么面对如此庞大数量的数据,恐怕最有经验的IT专家也无法从中分析出任何有价值的信息来,因为没有人知道在某种业务性能的要求下每一项技术参数的正常值应该是多少,而且它们之间关联程度之复杂也不是轻易就能梳理清楚的。

于是,我们提出这样一种设想:借助一定的工具模拟业务运转,如果系统性能没有达到要求,那么就对运转过程中自动获取的相关参数值进行分析,与事先输入的模板数据进行对比,利用计算机强大的分析能力将问题进行定位,并提出相应的解决办法。而对于IT管理人员所能看到的就是对系统业务性能的要求、系统未能达到这一要求的原因定位以及相应的解决办法,他们并不需要知道具体的技术参数值是多少,他们是以一种“业务语言”与系统进行对话,而不是“技术语言”。这样做的好处是可以对尽可能多的技术参数进行分析,而且这些参数值的获取也更加容易,并且无论是数据的同步性、准确性,还是分析的准确性和全面性都会非常高。我们可以把这种摆脱了技术细节纠缠,而只关心业务性能的IT管理方式称之为“从商业角度管理IT”的方法。

用IT手段来管理IT系统,这对企业来讲是一件令人兴奋的事情,因为在此过程中有太多的工作单靠人力是无法完成的。但问题的关键在于这个IT手段是从商业的角度出发的,而不是从技术的角度出发的。

用IT管理IT

目前,企业应用系统必须支持的对象包括:成千上万的用户、多种应用环境以及来自不同供应商的复杂的产品组合。由于用户负荷量的难以预测,以及应用程序的日趋复杂,使公司时刻面临一种系统性能的危机,碰到的问题有用户等待时间过长、系统失灵等,其结果就是导致公司收益的损失。美国Mercury公司在全球比较早地提出了“从商业角度管理IT”这一概念,在其相关解决方案中,企图利用一定的工具(LoadRunner)在应用系统生命周期的每个环节中,通过测试企业应用质量、可靠性和可扩展性,来帮助企业维持稳定的业务和收益,在不添置额外硬件设备的条件下最大限度地提升IT性能,并确保最终用户的性能体验。

因此,上述这样的工具便成为整个解决方案的核心,根据我们在上文的分析,它首先应该具有轻松创建虚拟用户的功能,它应该能够通过虚拟用户来模拟业务流程和真正用户的操作行为。它先记录下业务流程,如下订单或机票预定,然后将其转化为测试脚本。利用虚拟用户技术,系统可以在Windows、Unix或Linux机器上同时运行成千上万个测试,因此极大地减少了负载测试所需的硬件和人力资源。建立测试脚本后,测试人员可以开始对其进行参数化操作,这一操作能让测试人员利用几套不同的实际生产数据来测试应用程序,从而反映出企业系统的工作负载。

以一个订单输入过程为例,参数化操作可将记录中的固定数据,如订单号和客户名称,用可变值来代替。在这些变量内随意输入可能的订单号和客户名,来匹对多个实际用户的操作行为。该工具直接连于数据库服务器的后端,从这它可以获取所需的数据(如订单号和用户名),并直接将其输入到测试脚本,避免了人工数据处理的需要,从而节省了大量的时间。

另外,使用这个工具,测试人员应该能够很快组织起多用户的测试方案———确定在每一个负载服务器上运行多少业务流程和多少数量的实际用户。所以,这样的工具应该能够提供一个互动的环境,在其中测试人员既能建立起持续且循环的负载,又能管理和驱动负载测试方案。

至于参数值的获取一般都是通过植入应用系统内部的监测器来获取的,但是目前存在两种实现方式,一种是用户需要在应用系统中安装相应的软件,另一种就是所谓的“无”方式,它不需要在原有应用系统中另外安装任何软件就可以直接进入系统内部,读取系统运行参数值。显然,后者对降低资源浪费有极大好处,性能监控系统几乎不消耗应用系统的任何资源,而且管理起来也方便得多。这些实时监测器在负载测试过程的任何时候,都可以观察到应用系统的运行性能,并且实时显示交易性能数据,如系统反应时间、以及其他系统组件的即时性能———系统组件包括应用服务器、Web服务器、网络设备和数据库等。这样,测试人员就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运行性能,从而更快地发现问题。

一旦测试完毕后,系统收集汇总了大量的测试数据,剩下的就是通过其提供的分析和汇报能力,来迅速查找到性能问题并追溯缘由。例如,其细节分析机制能够分析是否因为一个大尺寸的图形文件或是第三方的数据组件造成应用系统运行速度减慢。这一部分应该说是整个解决方案的核心,它已经不纯粹是一个技术问题,而更多地是一个业务问题和方法论的问题。这一功能的好坏直接取决于解决方案提供商对业务的理解程度和积累程度。因为它需要把测试中获得的数据与“标准”数据进行比对、分析,从而定位问题根源,并找出解决问题的办法。而这个“标准”数据不是一朝一夕就能获得并且完备的,系统分析能力的强弱正取决于此。在分析阶段,分析模块可以提供自动关联(AutoCorrelation)功能,其原理是将最终用户的体验(相应时间、性能变化等)和系统属性信息,包括系统平台、网络、应用系统等的数据进行自动化的关联处理,一旦关联形成,测试/分析人员可通过分析得出的具体结果迅速定位性能和可用性问题根源,并采取快速的解决方案。