避免19个IT错误
■ 文/Chad Dickerson
人们常说：吃一堑、长一智，为了避免重蹈覆辙，《InfoWorld》特别邀请了众多IT经理和厂商，讲述曾犯过的错误。这些错误导致项目超支、业务受损甚至CIO失业，但却是可以可避免的。
1、胡乱制订外包策略
人们最容易犯的就是与外包有关的错误，这分两种：第一种是“委托罪”——把重要的IT职能外包出去，免得为之操心。但是，外包会导致简单的任务也难以完成。
而另一种错误就是对外包出去的IT职能不肯放手，譬如，一位CTO接过设在曼哈顿的一家网上服务公司的业务后发现，面向所有关键任务和创收应用的主机托管基础设施全放在公司内部，因为IT人员不放心将其交给第三方。2003年8月，曼哈顿部分地区遭遇大规模停电，长达28小时，结果该公司的UPS系统只维持了较短时间，而外包给主机托管公司的竞争对手则没有出现停运。
2、轻视或迷信开放源代码
不论好坏，许多IT公司容易出现“宗教”行为，即盲目地崇拜某项技术或者某个平台。在开放源代码方面更是如此。
一方面，极为保守的IT公司对开放源代码不屑一顾，认为它只是厂商的策略问题。这是天大的错误：对开放源代码持无限期观望态度意味着放弃被证实、稳定、可伸缩的低成本方案，如Linux、Apache、MySQL和PHP。另一方面，坚持IT运作一律采用开放源代码会减慢前进步伐，因为明明已经有更合适的商业软件，开发人员却被迫要把质量差或者难使用的开放源代码方案拼凑起来。
切记: 开放源代码软件不是天生优于商业软件，它完全取决于要解决的问题以及所考虑方案的成熟性。
3、漠视内部安全威胁
关注外部威胁的IT经理容易产生一种虚假的安全感。Gartner称，造成实际损失的安全事件中有70%是内部员工所为，所以内部威胁恐怕是企业面临的最严重问题。
2004年9月，英国最大的银行之一HFC Bank给2600个客户发去电子邮件，结果由于内部操作人员失误，凡是邮件列表上的人，都能看到其他收件人的邮件地址。更糟糕的是，客户的私人信息也泄露了出去。
恶意行为往往只要运用一点技术就能得逞。CERT和美国特工处今年发布的一项联合调查表明，得手的内部安全破坏中有87%采用了简单、合法的用户命令，这表明IT人员要保持警惕，只把必要的权限授给最终用户。
切记: 具有特定许可权的身份管理对此有所帮助。
4、没有保护流动边界
如今IT人员的职责范围延伸到了星巴克及其他地方。员工的移动性日益增强，加上公共无线热点和家庭宽带迅速普及，这意味着如今IT人员要负责保护不由自己控制的网络系统。在这种环境下，稳固安全意味着部署基于主机的防火墙，以便为家里不安全的宽带连接或者提供公共Wi-Fi接入的场所给予保护。
如果你是位经验丰富的IT经理，3年前购买的一款顶级防火墙可能会让你放心。你可以进行配置，阻挡所有入站流量，除了用于入站邮件的端口25。员工一般通过端口80和端口443实现出站WAN与Web的连接，这是通常方法。不过在比较分散的IT环境中，网络安全采用集中方法再也不够了。
切记: 对内部LAN上的流量进行加密，可以更有效地保护网络远离内部威胁以及可能通过非法无线接入点闯入网络的入侵者。
5、忽视手持设备的安全
虽然连缺乏经验的IT经理也认识到需要给网络资源、桌面电脑和便携电脑实行用户名/口令验证，不过说到手持设备安全，大多数IT公司似乎仍处于“拓荒时期”。
一家无线软件公司的CTO给我们讲了一位风险投资家的经历：该投资家马上要达成一笔非常敏感且机密的交易，偏偏在出差时丢失了BlackBerry。BlackBerry没有采用口令保护，所以即便那位恐慌的风险投资家联系上IT部门，不要再发邮件到该设备，捡到那台BlackBerry的人还是能读取已经收到的邮件。这件事表明，不要求用口令的小小便利却会带来严重后果。
切记: 忽视容易丢失的设备的安全，尤其是重要主管所携的内含机密信息的设备，只会招致灾祸。
6、人员提拔不当
身为CTO或者CIO，提拔优秀技术人员担任管理职位似乎没什么不对。但如果技术人员不愿意放弃技术工作，被迫选择了与人打交道的管理工作，可能会犯下与下面情况类似的错误。
一位IT副总裁描述了这个决定造成的糟糕局面：一名员工被提拔后遭到了昔日同事的不满，自己也不喜欢新的管理工作，结果导致表现欠佳。更糟的是，这名新经理觉得呆在不适宜的岗位有被迫的感觉，因为旧岗位可能再也没有了。这种情况把这位副总裁逼入困境：必须解决新经理的工作表现问题。这无异于双重打击：公司不但失去了一名优秀的技术人员，还不得不解雇这位新经理。
切记: 管理技能培训有助于避免这类灾祸。不过CTO或者CIO应当判断被提拔对象是否具有管理才能。
7、变更管理处理不当
一家计算机设备生产商的前CTO讲述了一件事：在日常维护期间，一位颇有才华但野心过大的系统管理员决定对一套重要服务器进行看似很小的变更。虽然变更工作事先得到了一致同意，并做了规划，但他自行决定升级为关键任务型本地DNS提供服务的采用开放源代码的服务器软件伯克利因特网名字域系统（BIND）。几小时后，整个公司陷入停顿，因为所有DSN功能都失灵了。恢复“一次小变更”用了几小时，但可能造成上百万美元的损失。该事件的教训是：如果不遵守变更管理程序，连能干的员工也会导致重大问题。
切记: 变更管理是一种文化。它完全始于公司上层：如果IT管理人员想图省事，IT操作人员也会同样偷懒。
8、软件开发管理不当
Frederick Brooks在影响深远的《人月神话》一书中指出，按单位人月（即一个人一个月完成的工作量）进行软件开发规划行不通，因为软件开发有其独特性。
即使软件开发可分成易管理、可互换的时间单位，优秀与平庸的编程人员在工作效率上的巨大差异意味着，人数较少但更有才华的编程人员可以在较短时间内为IT经理创造最大成果。
BizRate公司的CTO Henri Asseily说，一位优秀的人总是能够比一群人更快地开发出更好的软件。每个行业都说:“我们投资在人身上”或者“人是我们的最大资产，”但在IT行业中这最为重要。简而言之，优秀的编程人员与平庸之辈相差不止百倍。
自30年前Brooks的著作问世以来，许多IT经理仍按照人月这种不正确的方法规划项目和调配人员。如果毫无经验的IT经理坚持这种方法，只会给项目调配相应数量的人来完成指定的工作量，而Asseily等CTO坚持认为，找到优秀人员最重要。
切记: IT经理应当把闲余时间主要用来物色佼佼者，其他的都不重要。
9、让工程师自己保证质量
不允许工程师自己进行质量保证是软件开发的一条格言，但对小的软件开发队伍来说，总是忍不住想走捷径。其实，有时管理人员会与开发人员一起犯这个错误。有位CTO讲述了一个故事:有个软件开发项目的进展远远落后于预定期，首席开发员就开始自己进行质量保证，试图加快软件发布过程。糟糕的是，这位首席开发人员的假期眼看就到了。放假前一天，这位开发员宣布所有主要的错误都已解决，随后系统投入使用。等他抵达度假目的地，系统因崩溃而无法使用。许多现有的错误没有得到改正，因为那位开发员的测试既不全面又不正规。
切记: 让工程师自行进行质量保证，好比让被告充当法官和陪审员来审判案子。
10、只开发IE版的Web应用
尽管关键任务的应用继续使用Web浏览器，Windows也继续主导企业桌面，但Web开发人员应当避免只为“臭虫为患”的IE开发应用。坚持为IE开发Web应用的IT公司应准备好处理JS.Scob等恶意代码攻击。
最早在2004年6月被发现的JS.Scob通过被破坏的IIS Web服务器来传播。代码本身会偷偷把访问被破坏站点的顾客引到由俄罗斯黑客组织控制的站点。随后，不明就里的IE用户会下载特洛伊木马程序，而该程序能够记录击键内容和个人数据。虽然这听上去对企业IT人员不会构成威胁，但要牢记：员工往往使用同样的口令来访问企业和个人资产。
切记: 企业如果能确保自己的关键Web应用不单单依靠IE的功能，一旦层出不穷的IE安全漏洞使IT环境不堪重负、风险过高的时候，改用Mozilla Firefox等替代浏览器也比较容易。
11、依赖单一网络性能
说到网络性能，没有哪一个标准可以衡量网络运行状况。网络分析厂商Network Instruments LLC的总裁Douglas Smith指出，以为网络利用率可以用一种方法来测量是个错误。如果管理人员要求提供一份网络利用量报告，IT人员通常会匆忙用单一标准来衡量网络运行状况，这最终是不能确定的。
CIO应当衡量网络的某些方面，譬如端口利用率、链路利用率和客户端利用率。无论怎样，成功的网络分析意味着后退一步，分析一下企业环境中的数据。
网络利用率需要根据具体情况通盘考虑。如果某交换机上的两个端口其利用率为90%，但其他端口没在使用，就不能认为交换机利用率是90%。了解哪种应用导致这些端口的利用率达到90%也许更合适。
切记: 明白整体情况，结合实际环境分析利用率，这才是了解网络运行状况的关键。
12、乱用带宽解决网络问题
IT人员最常要处理的投诉之一是网络速度不如往常，对此，操作员的本能反应就是增加容量。在某些情况下，这是正确的方法，不过在某些情况下却是大错特错的。如果不经合理分析，扩增容量是个不明智又费钱的决定。
除了容量外，导致网速减慢的常见原因包括：老的系统或应用在网上发送不必要的流量，如IPX流量；应用软件配置不当或者效率低下;在不合适的时候往网络上发送大量数据包。
据Smith介绍，Network Instruments的一个银行客户接到反映系统运行速度缓慢的投诉后，考虑升级WAN链路。IT小组用网络分析仪来查明问题，结果发现流量增加是由于有个安全软件每天下午3点进行更新引起的。IT小组重新配置、改为凌晨3点更新后，流量很快得到了改善，用不着花钱升级WAN。
13、允许弱口令机制
在网络时代，蠕虫和网络钓鱼等新威胁往往吸引了所有人的注意力，但SANS Institute在10月发布的《前20大漏洞》公告着重提到了一种基本的IT错误：验证或者口令机制薄弱。口令方面最常见的漏洞包括：弱口令或者不设口令；用户账户采用广为人知或者实际上显眼的口令；管理员账户采用薄弱或者广为人知的口令；采用薄弱或者广人为知的口令散列算法，又不妥善保护，或者谁都能见到。
切记: 要避免弱验证错误，归根结蒂是采用简单的围追堵截:实施明确、详细、一贯执行的口令政策，积极主动地处理SAN报告中详述的最容易被人利用的验证漏洞。
14、从不操心细小问题
CTO和CIO们喜欢谈论技术的战略性应用，但忽视基本战术问题却会犯下后果极为严重的错误。没有为注册域名交30美元足以让公司陷入停顿。有这样一个例子：由于今年2月《华盛顿邮报》没有交费，结果好几小时员工都无法使用邮件，直到续费后才恢复正常。
由于数据中心环境变得更密集，连低级设施问题也需要密切关注。Sun总裁Jonathan Schwartz在其网络日志上引用了某位CIO的话：被问及“什么事情害得你熬夜？”时，那人回答：“再也不能为我们的数据中心提供足够电力，或者为数据中心散热时，我觉得我就像在用电热锅，而不是计算机。”如果某位CIO忽视这类紧迫但未必明显的问题，可能很快就得另找饭碗了。
15、照搬照套老方法
到新公司就任新职位的IT经理常犯一个错误：把老方法照搬照套到需要考虑不同业务和技术等因素的新环境中。
一位业务副总裁讲述了他的经历：离开依赖高档的Sun硬件和Oracle与Veritas软件的一家传统公司后，他在新公司负责管理新的低成本开放源代码环境。这家新兴公司付不起利用商业软件构建稳固环境所需的先期费，于是采用了LAMP（Linux、Apache、MySQL和PHP）架构。更为大胆的是，把Linux系统部署在AMD公司的64位Opteron机器上。那位副总裁渐渐认识到：从技术或者成本角度来看，老方法不适合新环境。于是他改变了方案，以适应新情况。
16、跟不上新技术
时时关注新技术可以防止灾祸。譬如说，过去几年出现了大量价格低廉的无线接入点，这意味着谁都可以构建无线网络——这对合理组建的企业IT环境来说是个重大问题。譬如，Network Instruments的一个零售客户安装WLAN以满足员工测定仓库库存量的需要。没多久，管理人员可以不经过批准访问WLAN，一些员工也擅自在桌下安装无线接入点。
幸好，IT队伍实施了检查非法接入点的几种方法。用网络分析仪扫描WLAN信道后很快发现：网上接入点超出了管理员原先知道部署的数量。
切记: 员工可能偷偷引入一项新技术，IT队伍应当制订相应程序来清查威胁、控制威胁。
17、低估PHP
开发可伸缩性的Web应用时只关注J2EE和.Net的IT经理会犯这个错误：不重新考虑编程语言，尤其是PHP。这门编程语言存在已有10年，每天用PHP编制的雅虎页面成千上万。
有关PHP可伸缩性的讨论在6月达到了高潮，当时流行的社交网络站点Friendster从J2EE迁移到PHP后，终于摆脱了烦人的网站性能问题。在针对Friendster改用PHP的评语中，PHP发明者Rasmus Lerdorf道出了PHP可伸缩功能在架构上的秘密：“可伸缩性的获得借助于采用可以水平无限伸缩的无共享架构（shared-nothing architecture）。”
PHP的无状态无共享架构意味着每个请求的处理独立于其他所有请求。而简单的水平伸缩意味着只要添加更多设备，所有的瓶颈都会局限于后端数据库的伸缩问题上。
切记: PHP等语言也许不是谁都适合的方案，但既然已有可伸缩性的成功方案，却把这些编程语言搁置一边无疑是个错误。
18、违反简化原则
Datavantage的技术设计师Doug Pierce说，违反KISS（keep it simple, stupid）原则是IT界的通病。Pierce说，他曾目睹“上亿美元的钱”浪费在实施或者支持对所处理问题而言过于复杂的解决方案上。Pierce声称，虽然CORBA和EJB等复杂技术适用于某些组织，但使用这类技术的组织有不少是自找麻烦。
违反KISS原则直接导致项目失败、IT成本高昂、系统无法维持、软件臃肿不堪、质量低劣或者缺乏安全。
切记: 力求IT系统简洁的指导思想是：“只有在没什么可以摈弃，而不是没什么可以添加的情况下，才能获得完美的设计”。
19、听信厂商的营销策略
说到网络设备、数据库、服务器及其他诸多IT产品，CIO或者CTO们经常会听到区别产品的“企业级”和“工作组级”等词语，但说到性能特点，这些词语意义不大。
以“工作组级”打头的产品其功能往往超出企业的实际应用。与购买较昂贵的企业级服务器相比，低价位的商用硬件、尤其是基于Intel芯片的服务器意味着：把大批廉价的工作组级硬件合并成企业级系统后，其冗余度和可伸缩性往往更高，说到Web应用更是如此。(来源：InfoWorld)
■ 文/Chad Dickerson
人们常说：吃一堑、长一智，为了避免重蹈覆辙，《InfoWorld》特别邀请了众多IT经理和厂商，讲述曾犯过的错误。这些错误导致项目超支、业务受损甚至CIO失业，但却是可以可避免的。
1、胡乱制订外包策略
人们最容易犯的就是与外包有关的错误，这分两种：第一种是“委托罪”——把重要的IT职能外包出去，免得为之操心。但是，外包会导致简单的任务也难以完成。
而另一种错误就是对外包出去的IT职能不肯放手，譬如，一位CTO接过设在曼哈顿的一家网上服务公司的业务后发现，面向所有关键任务和创收应用的主机托管基础设施全放在公司内部，因为IT人员不放心将其交给第三方。2003年8月，曼哈顿部分地区遭遇大规模停电，长达28小时，结果该公司的UPS系统只维持了较短时间，而外包给主机托管公司的竞争对手则没有出现停运。
2、轻视或迷信开放源代码
不论好坏，许多IT公司容易出现“宗教”行为，即盲目地崇拜某项技术或者某个平台。在开放源代码方面更是如此。
一方面，极为保守的IT公司对开放源代码不屑一顾，认为它只是厂商的策略问题。这是天大的错误：对开放源代码持无限期观望态度意味着放弃被证实、稳定、可伸缩的低成本方案，如Linux、Apache、MySQL和PHP。另一方面，坚持IT运作一律采用开放源代码会减慢前进步伐，因为明明已经有更合适的商业软件，开发人员却被迫要把质量差或者难使用的开放源代码方案拼凑起来。
切记: 开放源代码软件不是天生优于商业软件，它完全取决于要解决的问题以及所考虑方案的成熟性。
3、漠视内部安全威胁
关注外部威胁的IT经理容易产生一种虚假的安全感。Gartner称，造成实际损失的安全事件中有70%是内部员工所为，所以内部威胁恐怕是企业面临的最严重问题。
2004年9月，英国最大的银行之一HFC Bank给2600个客户发去电子邮件，结果由于内部操作人员失误，凡是邮件列表上的人，都能看到其他收件人的邮件地址。更糟糕的是，客户的私人信息也泄露了出去。
恶意行为往往只要运用一点技术就能得逞。CERT和美国特工处今年发布的一项联合调查表明，得手的内部安全破坏中有87%采用了简单、合法的用户命令，这表明IT人员要保持警惕，只把必要的权限授给最终用户。
切记: 具有特定许可权的身份管理对此有所帮助。
4、没有保护流动边界
如今IT人员的职责范围延伸到了星巴克及其他地方。员工的移动性日益增强，加上公共无线热点和家庭宽带迅速普及，这意味着如今IT人员要负责保护不由自己控制的网络系统。在这种环境下，稳固安全意味着部署基于主机的防火墙，以便为家里不安全的宽带连接或者提供公共Wi-Fi接入的场所给予保护。
如果你是位经验丰富的IT经理，3年前购买的一款顶级防火墙可能会让你放心。你可以进行配置，阻挡所有入站流量，除了用于入站邮件的端口25。员工一般通过端口80和端口443实现出站WAN与Web的连接，这是通常方法。不过在比较分散的IT环境中，网络安全采用集中方法再也不够了。
切记: 对内部LAN上的流量进行加密，可以更有效地保护网络远离内部威胁以及可能通过非法无线接入点闯入网络的入侵者。
5、忽视手持设备的安全
虽然连缺乏经验的IT经理也认识到需要给网络资源、桌面电脑和便携电脑实行用户名/口令验证，不过说到手持设备安全，大多数IT公司似乎仍处于“拓荒时期”。
一家无线软件公司的CTO给我们讲了一位风险投资家的经历：该投资家马上要达成一笔非常敏感且机密的交易，偏偏在出差时丢失了BlackBerry。BlackBerry没有采用口令保护，所以即便那位恐慌的风险投资家联系上IT部门，不要再发邮件到该设备，捡到那台BlackBerry的人还是能读取已经收到的邮件。这件事表明，不要求用口令的小小便利却会带来严重后果。
切记: 忽视容易丢失的设备的安全，尤其是重要主管所携的内含机密信息的设备，只会招致灾祸。
6、人员提拔不当
身为CTO或者CIO，提拔优秀技术人员担任管理职位似乎没什么不对。但如果技术人员不愿意放弃技术工作，被迫选择了与人打交道的管理工作，可能会犯下与下面情况类似的错误。
一位IT副总裁描述了这个决定造成的糟糕局面：一名员工被提拔后遭到了昔日同事的不满，自己也不喜欢新的管理工作，结果导致表现欠佳。更糟的是，这名新经理觉得呆在不适宜的岗位有被迫的感觉，因为旧岗位可能再也没有了。这种情况把这位副总裁逼入困境：必须解决新经理的工作表现问题。这无异于双重打击：公司不但失去了一名优秀的技术人员，还不得不解雇这位新经理。
切记: 管理技能培训有助于避免这类灾祸。不过CTO或者CIO应当判断被提拔对象是否具有管理才能。
7、变更管理处理不当
一家计算机设备生产商的前CTO讲述了一件事：在日常维护期间，一位颇有才华但野心过大的系统管理员决定对一套重要服务器进行看似很小的变更。虽然变更工作事先得到了一致同意，并做了规划，但他自行决定升级为关键任务型本地DNS提供服务的采用开放源代码的服务器软件伯克利因特网名字域系统（BIND）。几小时后，整个公司陷入停顿，因为所有DSN功能都失灵了。恢复“一次小变更”用了几小时，但可能造成上百万美元的损失。该事件的教训是：如果不遵守变更管理程序，连能干的员工也会导致重大问题。
切记: 变更管理是一种文化。它完全始于公司上层：如果IT管理人员想图省事，IT操作人员也会同样偷懒。
8、软件开发管理不当
Frederick Brooks在影响深远的《人月神话》一书中指出，按单位人月（即一个人一个月完成的工作量）进行软件开发规划行不通，因为软件开发有其独特性。
即使软件开发可分成易管理、可互换的时间单位，优秀与平庸的编程人员在工作效率上的巨大差异意味着，人数较少但更有才华的编程人员可以在较短时间内为IT经理创造最大成果。
BizRate公司的CTO Henri Asseily说，一位优秀的人总是能够比一群人更快地开发出更好的软件。每个行业都说:“我们投资在人身上”或者“人是我们的最大资产，”但在IT行业中这最为重要。简而言之，优秀的编程人员与平庸之辈相差不止百倍。
自30年前Brooks的著作问世以来，许多IT经理仍按照人月这种不正确的方法规划项目和调配人员。如果毫无经验的IT经理坚持这种方法，只会给项目调配相应数量的人来完成指定的工作量，而Asseily等CTO坚持认为，找到优秀人员最重要。
切记: IT经理应当把闲余时间主要用来物色佼佼者，其他的都不重要。
9、让工程师自己保证质量
不允许工程师自己进行质量保证是软件开发的一条格言，但对小的软件开发队伍来说，总是忍不住想走捷径。其实，有时管理人员会与开发人员一起犯这个错误。有位CTO讲述了一个故事:有个软件开发项目的进展远远落后于预定期，首席开发员就开始自己进行质量保证，试图加快软件发布过程。糟糕的是，这位首席开发人员的假期眼看就到了。放假前一天，这位开发员宣布所有主要的错误都已解决，随后系统投入使用。等他抵达度假目的地，系统因崩溃而无法使用。许多现有的错误没有得到改正，因为那位开发员的测试既不全面又不正规。
切记: 让工程师自行进行质量保证，好比让被告充当法官和陪审员来审判案子。
10、只开发IE版的Web应用
尽管关键任务的应用继续使用Web浏览器，Windows也继续主导企业桌面，但Web开发人员应当避免只为“臭虫为患”的IE开发应用。坚持为IE开发Web应用的IT公司应准备好处理JS.Scob等恶意代码攻击。
最早在2004年6月被发现的JS.Scob通过被破坏的IIS Web服务器来传播。代码本身会偷偷把访问被破坏站点的顾客引到由俄罗斯黑客组织控制的站点。随后，不明就里的IE用户会下载特洛伊木马程序，而该程序能够记录击键内容和个人数据。虽然这听上去对企业IT人员不会构成威胁，但要牢记：员工往往使用同样的口令来访问企业和个人资产。
切记: 企业如果能确保自己的关键Web应用不单单依靠IE的功能，一旦层出不穷的IE安全漏洞使IT环境不堪重负、风险过高的时候，改用Mozilla Firefox等替代浏览器也比较容易。
11、依赖单一网络性能
说到网络性能，没有哪一个标准可以衡量网络运行状况。网络分析厂商Network Instruments LLC的总裁Douglas Smith指出，以为网络利用率可以用一种方法来测量是个错误。如果管理人员要求提供一份网络利用量报告，IT人员通常会匆忙用单一标准来衡量网络运行状况，这最终是不能确定的。
CIO应当衡量网络的某些方面，譬如端口利用率、链路利用率和客户端利用率。无论怎样，成功的网络分析意味着后退一步，分析一下企业环境中的数据。
网络利用率需要根据具体情况通盘考虑。如果某交换机上的两个端口其利用率为90%，但其他端口没在使用，就不能认为交换机利用率是90%。了解哪种应用导致这些端口的利用率达到90%也许更合适。
切记: 明白整体情况，结合实际环境分析利用率，这才是了解网络运行状况的关键。
12、乱用带宽解决网络问题
IT人员最常要处理的投诉之一是网络速度不如往常，对此，操作员的本能反应就是增加容量。在某些情况下，这是正确的方法，不过在某些情况下却是大错特错的。如果不经合理分析，扩增容量是个不明智又费钱的决定。
除了容量外，导致网速减慢的常见原因包括：老的系统或应用在网上发送不必要的流量，如IPX流量；应用软件配置不当或者效率低下;在不合适的时候往网络上发送大量数据包。
据Smith介绍，Network Instruments的一个银行客户接到反映系统运行速度缓慢的投诉后，考虑升级WAN链路。IT小组用网络分析仪来查明问题，结果发现流量增加是由于有个安全软件每天下午3点进行更新引起的。IT小组重新配置、改为凌晨3点更新后，流量很快得到了改善，用不着花钱升级WAN。
13、允许弱口令机制
在网络时代，蠕虫和网络钓鱼等新威胁往往吸引了所有人的注意力，但SANS Institute在10月发布的《前20大漏洞》公告着重提到了一种基本的IT错误：验证或者口令机制薄弱。口令方面最常见的漏洞包括：弱口令或者不设口令；用户账户采用广为人知或者实际上显眼的口令；管理员账户采用薄弱或者广为人知的口令；采用薄弱或者广人为知的口令散列算法，又不妥善保护，或者谁都能见到。
切记: 要避免弱验证错误，归根结蒂是采用简单的围追堵截:实施明确、详细、一贯执行的口令政策，积极主动地处理SAN报告中详述的最容易被人利用的验证漏洞。
14、从不操心细小问题
CTO和CIO们喜欢谈论技术的战略性应用，但忽视基本战术问题却会犯下后果极为严重的错误。没有为注册域名交30美元足以让公司陷入停顿。有这样一个例子：由于今年2月《华盛顿邮报》没有交费，结果好几小时员工都无法使用邮件，直到续费后才恢复正常。
由于数据中心环境变得更密集，连低级设施问题也需要密切关注。Sun总裁Jonathan Schwartz在其网络日志上引用了某位CIO的话：被问及“什么事情害得你熬夜？”时，那人回答：“再也不能为我们的数据中心提供足够电力，或者为数据中心散热时，我觉得我就像在用电热锅，而不是计算机。”如果某位CIO忽视这类紧迫但未必明显的问题，可能很快就得另找饭碗了。
15、照搬照套老方法
到新公司就任新职位的IT经理常犯一个错误：把老方法照搬照套到需要考虑不同业务和技术等因素的新环境中。
一位业务副总裁讲述了他的经历：离开依赖高档的Sun硬件和Oracle与Veritas软件的一家传统公司后，他在新公司负责管理新的低成本开放源代码环境。这家新兴公司付不起利用商业软件构建稳固环境所需的先期费，于是采用了LAMP（Linux、Apache、MySQL和PHP）架构。更为大胆的是，把Linux系统部署在AMD公司的64位Opteron机器上。那位副总裁渐渐认识到：从技术或者成本角度来看，老方法不适合新环境。于是他改变了方案，以适应新情况。
16、跟不上新技术
时时关注新技术可以防止灾祸。譬如说，过去几年出现了大量价格低廉的无线接入点，这意味着谁都可以构建无线网络——这对合理组建的企业IT环境来说是个重大问题。譬如，Network Instruments的一个零售客户安装WLAN以满足员工测定仓库库存量的需要。没多久，管理人员可以不经过批准访问WLAN，一些员工也擅自在桌下安装无线接入点。
幸好，IT队伍实施了检查非法接入点的几种方法。用网络分析仪扫描WLAN信道后很快发现：网上接入点超出了管理员原先知道部署的数量。
切记: 员工可能偷偷引入一项新技术，IT队伍应当制订相应程序来清查威胁、控制威胁。
17、低估PHP
开发可伸缩性的Web应用时只关注J2EE和.Net的IT经理会犯这个错误：不重新考虑编程语言，尤其是PHP。这门编程语言存在已有10年，每天用PHP编制的雅虎页面成千上万。
有关PHP可伸缩性的讨论在6月达到了高潮，当时流行的社交网络站点Friendster从J2EE迁移到PHP后，终于摆脱了烦人的网站性能问题。在针对Friendster改用PHP的评语中，PHP发明者Rasmus Lerdorf道出了PHP可伸缩功能在架构上的秘密：“可伸缩性的获得借助于采用可以水平无限伸缩的无共享架构（shared-nothing architecture）。”
PHP的无状态无共享架构意味着每个请求的处理独立于其他所有请求。而简单的水平伸缩意味着只要添加更多设备，所有的瓶颈都会局限于后端数据库的伸缩问题上。
切记: PHP等语言也许不是谁都适合的方案，但既然已有可伸缩性的成功方案，却把这些编程语言搁置一边无疑是个错误。
18、违反简化原则
Datavantage的技术设计师Doug Pierce说，违反KISS（keep it simple, stupid）原则是IT界的通病。Pierce说，他曾目睹“上亿美元的钱”浪费在实施或者支持对所处理问题而言过于复杂的解决方案上。Pierce声称，虽然CORBA和EJB等复杂技术适用于某些组织，但使用这类技术的组织有不少是自找麻烦。
违反KISS原则直接导致项目失败、IT成本高昂、系统无法维持、软件臃肿不堪、质量低劣或者缺乏安全。
切记: 力求IT系统简洁的指导思想是：“只有在没什么可以摈弃，而不是没什么可以添加的情况下，才能获得完美的设计”。
19、听信厂商的营销策略
说到网络设备、数据库、服务器及其他诸多IT产品，CIO或者CTO们经常会听到区别产品的“企业级”和“工作组级”等词语，但说到性能特点，这些词语意义不大。
以“工作组级”打头的产品其功能往往超出企业的实际应用。与购买较昂贵的企业级服务器相比，低价位的商用硬件、尤其是基于Intel芯片的服务器意味着：把大批廉价的工作组级硬件合并成企业级系统后，其冗余度和可伸缩性往往更高，说到Web应用更是如此。(来源：InfoWorld)
回复Comments
作者:
{commentrecontent}