“为什么计算出是什么导致网络性能的降低如此困难?”这是许多IT管理者在Peter Harrison研究并撰写《Linux Quick Fix Notebook》(http://www.phptr.com/title/0131861506)*书时向他提问的问题，这本书由Prentice Hall出版社于近期出版发行。而在这篇技巧性的文章中，我们有幸邀请到Harrison，他将回答上面的问题，并将提供*些诊断性能问题的建议。――编者

检测网络性能的瓶颈是非常棘手的事情，几个因素的叠加将使解决问题变得更加困难。许多应用都必须依赖中间的服务器通信才能够正常工作，因此慢速的应用程序反应时间，可能由通信路径中任何*个层面的问题所引起，也就是说，问题发生在开放式系统互联(Open Systems Interconnection，OSI)模型的任*水平的协议栈中。它可能是物理问题，如电缆或网卡(NIC)发生了问题，也可能是协议问题、通过网络的路由等待时间、实施了劣质的TCP/IP 协议堆栈造成的间歇性延迟、安全设备的包过滤、过载的系统，或者是过载的应用。

所有的这些事情都发生在你的应用的通信路径中，它们都需要加以检查。*个慢速的Web服务器响应可能跟Web浏览器和Web服务器之间、Web服务器和应用服务器之间、应用服务器和数据库服务器之间、数据库服务器和存储区域网络上的磁盘之间，或者应用服务器和信用卡处理柜台之间的某个问题有关。

下*个问题则来源于这类通信路径通常由许多不同的部门间接管理的事实，举*个例子来说，建筑物设施团队负责布线，而另外还有许多团队，如网络团队、安全团队、程序员、数据库管理员、存储专家、系统管理员和硬件/软件供应商。从*个团队到另*个团队的通信问题处理通常是*个巨大的挑战，特别是在某个部分可能被外包到国外的时候，问题将变得更加复杂和难缠。

*后，问题来自于人性上。没有人想承认它们进行过任何更改，如果有*个历史记录，他们也会不同意履行这种职责;即使问题初步显示是硬件故障或软件Bug，人们都会保持警惕，这就造成了不必要的双重检查，团队成员必须为**找到问题花费更多时间，这些浪费的时间会给问题的解决添加进入更多的延迟。

查找，通信瓶颈

每*个团队都需要使用*前提及的工具来鉴别可能的性能瓶颈。消除性能瓶颈需要按照OSI模型栈从底端到顶端的方式进行。

• 网络团队应该设法尽力消除底层的物理电缆、通信链路、路由和包过滤问题。
• 系统管理员应该尝试消除可能影响应用性能的服务器问题。
• 开发团队应该修正他们的程序代码，数据库管理员团队则应该评估数据库性能的问题。

而真正的难题通常位于寻求其它团队帮助消除可能的问题来源之中。

以我的经验，处理此类包括各种方面问题的*好方法是将解决问题的职责交给单*个个人去执行，这个人必须具有项目管理技巧，加上本身具备的多种技术能力，允许他能够掌握整个IT周边情况的概念，进而解决问题。

不过此中存在的问题是，项目经理类型的人通常受执行团队的尊敬，因为他们能够在管理层面解释技术状况，但通常他们不会得到拥有高超IT技术的技术团队的认同。鉴于这种原因，我建议为项目经理配备*个技术带头人，组成*个团队，此团队应该掌握IT部门正在使用的多种不同的IT技术，这将帮助他解决与技术部门的交流，并好找技术团队在问题发现时即将其解决。

这两种人在解决持久问题时都应该被分派。这听起来好像有些过分，但项目经理将将在管理团队和他们的团队之间提供连贯性，技术带头人则将有能力协同和跟踪每*个步骤面临的技术挑战。*旦问题得到解决，这两个人将召开*个事后剖析会议，以决定如何避免和检测再发生类似问题。

如果瓶颈非常严重，那么召开*个所有必要的团队参加的电话会议通常是非常明智的。在这种情况下，E-mail通信将受到很大限制，因为技术团队的成员经常在远离E-mail的情况下解决问题。这样的话，直接的电话呼叫通常具有*大的**权。在电话会议中，项目经理应该发起电话，技术带头人则应该在幕后操作，以监视系统工程的细节。

就像我早*提及的，*个事后剖析会议必须被安排，并且要将从中学习到的经验教训存档。这将帮助*快的检测和解决重现的问题，也有可能通过信息的分析，帮助消除潜在的问题。事后剖析文档应该被用来作为内部团队培训的基础，这些文档包含所有有效的改进，不管是正式的设置还是例会的*部分，并且要确保这些知识被正确的传播。