6个IT神话没根据 假想背后露真相

http://www.sina.com.cn 2004年08月30日 09:43 计世网
　　李建平
　　现在是面对现实的时候了。我们长久以来的一些基本假想，事实上往往没有根据。技术大腕也常常会像所有专业人员一样为过时的信仰所左右。为此，我们讨论剖析了6个常见的IT神话，以便让IT经理们清楚地看到一些重要假想的真相。否则，这些假想可能会成为他们技术计划的破坏因素。
 8月,三星与您激情奥运  玉兰油欧莱雅等6折起  
LG 手机一元抢拍  精彩手机赛事全攻略
　　《InfoWorld》在追踪这些神话的源头后发现，事实上几乎所有这些神话都没有什么依据。例如，有神话认为服务器升级很重要，事实上根本不是这样。另一个神话相信：业务能力是成为一名成功CTO的关键。事实上也不是这样。还有一种神话认为80%的企业数据保存在大型机上。是否如此，不妨亲自检验一下。我们执著的记者发现很多历史悠久的神话需要揭穿，这再一次证明，尽管一些至理名言广为人知，但并不总是合理。
　　神话之一：服务器升级很重要
　　真相：不要为可升级花费额外的钱；你将永远不需要它
　　你最后一次更换服务器上的处理器是什么时候？你拆过运营系统的RAID控制器，用更大的缓存更换它吗？你卸下过机器的镜像18GB Ultra160 SCSI引导硬盘，代之以36GB Ultra360硬盘吗？
　　尽管顶级服务器制造商吹嘘它们的服务器平台的现场升级能力，但是用户会不断地摆弄生产系统是一种荒诞的说法，除非迫不得已需要更换毁坏的零件。如果服务器使用时间不足1年，它很可能在订购时就配备了合适的部件，不需要去改动；如果服务器使用时间超过了1年，任何思维正常的人都不会去拆开它升级CPU。
　　为了调查这个神话，我接触了所有顶级服务器制造商。当问及有关升级服务器的统计数据时，没有一家厂商愿意正式合作。一些厂商说没有这类数据，另一些厂商说这是内部信息，出于竞争原因不能公布。所有厂商都声称发现这个问题令人惊讶，并且都对调查结果很感兴趣。
　　所幸的是，一家不愿透露名称的厂商转交了一位营销经理的非正式评论。这位经理的思索引起了我的共鸣：“我认为大多数顾客从一开始就购买了配置满足未来发展需要的RAM和CPU的服务器。”
　　这位经理补充说：“许多顾客拿到购买硬件的款项后，更容易用这笔钱购买硬件，而不是把钱花在未来升级硬件上。”
　　不升级系统的另一个原因当然包括害怕把事件搞糟：遭遇操作系统、驱动程序或应用程序上的困难。由于只有很小的性能改进(比如说，从2.0G升级2.6G处理器)，而服务器其余部分仍和原来一样，有什么必要冒这种风险吗？
　　很难想像对双处理器1U或2U服务器或服务器刀片上的硬件做很多改动，除了根据需要添加内存外。如果低档服务器不能处理工作负载，解决办法是用功能更强大的服务器更换它，或向负载平衡群集添加更多的服务器。把有限的资金花在老服务器上带来不了ROI(投资回报)。当你考虑新服务器的规格时，要保证系统满足你现有的需要，并在购买时留出这台机器的预期寿命期可能需要的余量。除非你具有IT 专业知识并实际进行过服务器升级，否则不要进行任何升级，不要为能够适应未来处理器平台的可升级CPU卡花冤枉钱。你将永远不会用到它们的。
　　IT神话之二：80%的企业数据保存在大型机上
　　真相：50%，或更少
　　是终结大型机仍保存着80%的企业数据的神话的时候了。大型机自50年代问世后，基本上一直是管理所有关键任务企业数据的无可争议的看门人。IBM因大型机而成为蓝色巨人，因为蓝色正是它们早期大型机的颜色。然而，70和80年代， IBM在大型机市场上的垄断地位遭到了攻击。随着第一批小型计算机以及随后的微型计算机的到来，Fortune 1000公司开始减少了对大型机的依赖。小型和微型计算机带来了将集中保存的数据更靠近用户分散存放的希望。
　　但是，Internet的诞生和由此引发的非结构化数据(如电子邮件、网页、Word文档)的洪水以及各种管理与保存这类数据的技术，让许多人得到了这样的结论：大型机对企业数据的束缚已经逐渐松绑。
　　RedMonk公司高级分析师O Grady说，许多大型机构的财务数据是用几个Excel电子报表管理的，此外再加上各种不经过大型机的网志、即时消息、电子邮件，目前保存在大型机上的数据量在40%到50%之间。Yankee Group高级分析师Gardner说，现在已经有大量的关键财务数据是在大型机之外生成、共享和管理的。Gardner说：“一些企业用户现在拥有 Spreadmarts，即用于管理许多业务流程的、以真正分散方式保存的大型扁平的电子表报文件。”
　　另一个削弱大型机统治地位的趋势是SAN和NAS专用设备的出现。尽管这类设备大多直接连到大型机上，数据在大型机中可以被共享，但越来越多的企业用户倾向于将数据保存在SAN和NAS设备上。
　　IT神话之三：所有大机构都使用多种平台
　　真相：这个“神话”比小说更接近事实
　　正如New Wave乐队的Devo所说的那样：“自由选择是你的权利。来自选择的自由是你的希望。”别无选择难道不是比必须自由做出决定更容易吗？这项原则适应于IT吗？企业是在寻求多样性而不是单一厂商解决方案吗？
　　专家们认为这不是神话。Forrester Research副总裁Gilpin说，一些较小的公司为单一化的公司，而较大的公司由于兼并和收购而不可避免地变为多样化的公司。此外，多样性起到了杠杆作用。Gilpin说：“拥有其他一些厂商总是有用的，你可以将他们当做一种威胁来使用。”Oblix公司官员对此表示赞同，他说：“IT人员喜欢这种他们通过保持多样化环境获得的杠杆。”
　　IBM自治计算部官员Bartlett说：“绝大多数的企业成为多样化企业。”他说，以前，单一化环境与多样化环境之比约为八二开，而现在这个比例至少已经倒了过来。Bartlett说，公司希望全球化、全天候运营以及在Internet上运营的要求导致了多样性。
　　多样化和单一化各有各的优缺点。单厂商解决方案，即所谓的专有解决方案，避免了必须使不同系统一起工作的困难。但专有解决方案让用户受制于一家或很少几家厂商，并且只提供有限的选择。所谓的开放解决方案为用户提供了多种技术选择，从而在理论上降低了费用。但是，IT管理人员可能需要忙于在开放环境中集成各种东西、开发各种标准。
　　尽管大多数机构需要多样性，但一些用户至少在它们的部分IT基础设施上更喜欢单厂商方式。例如，加州San Jose市最近受到人们批评，原因
4000
就是它选择本地网络厂商Cisco作为其正在建设的新市政厅的网络设备供应商。
　　IT神话之四：与精通技术专业知识相比，CIO和CTO更需要精通业务
　　真相：技术资质比以往更重要
　　对于大约20年前出现在企业中的首批CIO来说，他们的首要工作是确保IT部门部署的技术为偏远办事处的业务目标提供服务。他们那时必须成为两种差异很大的文化之间的桥梁。
　　但是在过去的20年中，当技术变得与公司的核心业务战略密不可分时，许多CIO以及大型公司中的CTO却被迫将过多的时间用在业务方面。
　　而且随着技术项目数量的增加，许多CIO和CTO将单个技术采购和部署方式的更多决定权交给下级。那些做出产品购买决定的人常常单纯关注技术，因此在做出战术决定时，没有充分考虑这些决定如何使整体业务目标受益。一家大型银行的LAN管理员说：“我认为一些IT项目在技术上偏离方向或超出预算的主要原因之一是，缺少来自高级管理层在技术方面做出的指导。”事实上，一些业界观察人士似乎担心CIO和CTO必须花更多的时间来深入了解技术和产品，尤其是新出现的产品和技术。
　　CIO和CTO被迫将更多的精力放在业务而非技术决定上的主要原因之一是“.com”泡沫的破裂。由于90年代中后期盲目花在技术上的大量资金带来很少的ROI，许多CEO要求任何有一定规模的技术设备都取得即使不是立即的也是短期的回报。
　　然而，仅仅关注短期的财务收益，迫使大多数CIO和CTO将长期的技术部署推迟到经济复苏之后进行。与那些在ROI与高科技投资之间取得更合理的平衡的人相比，这种延期只会让保守的CIO和CTO处于竞争劣势。
　　一位业内人士说，那些只希望得到短期ROI的CEO和CIO在IT技术发展方向这个问题上是近视的。他说，真正了解IT技术，知道采取什么措施使这些技术变化有利于加强竞争优势的企业，才能够占据非常有利的位置。
　　IT神话之五：大多数IT项目遭受失败
　　真相：取决于你如何定义失败
　　大多数IT项目失败了吗？在回答这个问题时，一些人会引用IBM Global Services、Capgemini和Sapient等大型咨询公司提供的数字，而这些公司正是靠企业遭遇的可悲经历而生存的。
　　另一些人则反驳说失败是相对的。的确，许多项目都存在系统问题或预算超支，但它们没有达到严重损害用户业务的“失败”状态。
　　AMR Research副总裁Shepherd说：“如果某一项目晚了3个月，或预算超支5%，这可能令人失望，但这不是失败。大多数IT项目都属于这种情况。”Shepherd认为，虽然项目遇到五花八门的问题，但实际的部署通常都是成功的。
　　专业从事跟踪IT成功或失败的Standish Group规定了非常严格的成功标准。Standish Group去年调查了13,522个项目，证明绝对成功项目大大低于50%，仅为34%。彻底失败的项目，即中途夭折的项目，为15%。介于两者之间是完成了的、但“受到质疑的”项目。Standish说，受到质疑的项目占所有IT项目的51%，这些项目被定义为存在费用超支、超出工期的项目。 Standish说，成功的水平依次与用户参与、管理层支持的程度和拥有有经验的项目经理相关。
　　对于IT项目咨询机构Sapient来说，成功或失败的关键因素取决于公司采取的控制风险的流程。换句话说，必须在故障点影响到整个项目前确定它。Sapient公司CTO Gaucherin说：“项目越大，失败的可能就越大，因此你需要在控制风险上下更大的力气。”他补充说，潜在的问题可以通过“暴露风险”法来控制。暴露风险法是一种在事情失控之前就确定它们的方法。
　　Standish Group官员说，也许对于IT项目最具破坏性含意的消息，不是被放弃的IT项目的数量，而是那些完成但没有提供最初规定的特性和功能的项目。她说：“内容缺少50%以上最有可能被认为是一次失败。”
　　不过，AMR的Shepherd则持另一种观点，他说：“失败是这样一种情况：订单被停止接收，或者账目不能完成，或者项目本身被放弃。而这种情况很少发生。”
　　IT神话之六：IT不能伸缩
　　真相：几乎任何技术都是可伸缩的，只要你混合正确的成分，并有效地实现它们。
　　几乎每种信息技术曾经都被判断为不符合要求。失败常常用最恶毒的话来总结：“它不能伸缩。”理由当然是曾经由于这样或那样的原因，每种信息技术都不能伸缩。
　　不幸的是，对于这方面的牺牲者来说，可伸缩性是一个非常不准确的术语。人们可能希望应用扩展到大型服务器或缩小到手持机上。然而，尺寸只是可伸缩性的一个方面。其它方面包括带宽、交易密度、服务可用性、查询性能以及源代码的可理解性或最终用户的信息显示，等等。
　　不存在包治所有这些病症的灵丹妙药，但这并不妨碍我们努力去寻找它。举个例子：当社区网络服务公司Friendster由J2EE切换到PHP，并大大改进了响应时间时，一场骚乱因此而起。作为对长期以来“脚本语言不能伸缩”的论断的反应，PHP支持者现在可以开心地声称：“Java不能伸缩。”
　　这场争论不仅制造了激情，而且还让人们注意到了PHP发明者Rasmus Lerdorf是如何称呼PHP“什么都不共享”架构的。他解释说，由于PHP是无状态的，潜在的瓶颈被从Web层排挤到数据库层中。Lerdorf说，如果你使用Oracle产品，可伸缩性的大小取决“你每年给Oracle开出多大的支票”；如果你使用MySQL或PostgreSQL，“可伸缩性取决于你是否正确配置复制，是否有一颗精心设计的数据库机器树。”
　　当然，Java可以以类似方式使用。当eBay进行引起广泛关注的J2EE迁移时，新架构的无状态性被列为一个关键的成功因素。
　　可伸缩性不是程序语言、应用服务器或数据库的固有属性。它源于巧妙地将各种成分组合到一个有效的解决方案中。这里没有单一的配方。例如，无论你的数据库功能多么强大，在使用不恰当时，它都可能变为瓶颈。许多“.com”时代的Web出版商在付出惨痛的代价后学到了这一教训，他们的数据库驱动的网站在黑客的攻击下而崩溃。
　　当前的网志革命代表着两种协作方法之间的更好平衡：从数据库和服务器缓存提供动态内容服务，从文件系统提供静态内容。
　　得出分散的、松散联系的Web架构本质上可伸缩的结论十分诱人。但事实上并不是这样。我们学习了(并仍在学习)如何正确地混合这些成分。人们可以读写的格式和协议加强了人类一方的可伸缩性。缓存和负载平衡技术在带宽和可用性上给予我们帮助。
　　然而一些问题将始终需要各种成分的不同混合。例如，Microsoft已经将内部业务应用整合到SAP的单一实例上。在这个例子中，成功的架构是集中的和紧密联系的架构。
　　对于任何技术来说，“X不能伸缩”的论断都是荒诞之说。真实情况是总有办法让X可以伸缩。了解这些可能性并避免隐藏的危险，需要书本上没有的经验。(本文以8月30日出版的《计算机世界》新闻版A20为准)