不要让网络应用失控

影片《星期六夜生活》中 “费尔南多”说：“看起来好比感觉好更棒。”但是，网管应该知道网络应用的外表与其内在稳定性一样，都很关键。这就是他们在制定日益精细的性能管理策略的同时采用外部及内部监控机制的原因。
首先，深刻理解影响网络应用性能的因素是十分重要的。企业越来越多地使用网页来发送消息和提供服务给与它们有关的客户、供应商及其他商业伙伴。维护这些服务在什么样的水平线上将决定一个企业的兴衰。
有时网站显得有点慢，甚至暂时无法运行。有时糟糕的应用性能使你的客户放弃交易或无法查看订单。网络和网页技术必须更加注重维持在线服务质量。
另外在收益和所涉及到的关系问题上，网络应用的性能对于外部世界来说是可见的，这与传统的企业应用不同。性能问题会令大家都感到头疼，并引发操作上的争论。维护公司的信誉要求有效地维护页面服务的水平，这方面正面临前所未有的压力。
不幸的是，这些服务的水平取决于不同类型的移动部件。当前一个典型的网络应用的性能随许多元件的正常运行与否而变，诸如：运行在高端硬件上的后台数据库，由一系列复杂的Java元件构成的中间应用服务器程序，和一些前台的页面服务器及其操作系统。
其他影响性能的因素还包括各种各样的页面增强硬件，如：负载平衡器、安全接口层加速器以及连接所有这些元件并提供因特网访问的网络设备。
网络出问题时要查看和排除很多方面的东西。企业之外的很多因素也会影响网络应用的性能，包括宿主网络、服务器架构和第三方的因素，诸如：消息来源和本地映射。第三方服务，比如信用卡授权或航运信息，也会影响网络应用的性能。网站的操作者和用户使用的ISP以及公用因特网本身在网络性能中扮演着重要的角色。
在查找任何网络问题的根本原因时你应该考虑的其他问题有：点对点应用的结构。页面应用在用户端和网站的服务器之间要求大量的请求及回复的交换。这些“轮换”和它们的排列次序以及它们对该应用中每一步运行的影响都会影响网络的性能。
你不能把这些影响网络性能的因素归结为任何单一的构成网络的元件。相反，它们只导致了整个混乱的一部分而已－数据库、服务器的不同元件和页面服务器等。
在如此复杂的底层架构下，你仅靠服务器、连接和程序的正常运行还无法确定用户端正经历的服务的质量。这可以解释目前为什么有那么多公司使用一种外部应用－反映监视系统。
这些系统通常由外部厂商提供，并以签名服务的形式出现。首先，它们在服务失败或性能下降时发出警告。因为它们可以比人类用户探测出更多微妙的性能方面的变化，使技术部门能够防患于未然。
第二，你可使用外部监视统计数据来分析应用性能的发展趋势,这对于确定新的因素或增加的流量对站点服务的影响尤其重要。
第三，网站速度对于市场运作来讲是一个颇具竞争性的指标。
最后，一个有效的外部监视系统可协助排除故障。通过跟踪给定交易或过程中每一步的影响，这种监视服务可以指出网站问题是否由网络阻塞或数据库瓶颈抑或糟糕的第三方数据而起。
现在，你已经知道需要什么了－反应监视系统，你还可以看到外部厂商所提供的这些服务的不同之处。今天，各种监视服务的结构有质的差别。最常用的当属Keynote系统，自1997年开始用于客户服务及出版行业。Keynote使用遍布世界140个点的1400台机器进行监视活动，它提供报警服务和趋势报告，客户可通过一个安全的浏览器从任何地方访问其网站。
Keynote的一种可能的缺陷在于它总是监视以高速连接到1层ISP的网站，这可避免歪曲性能统计数据的历程和可比性，但是它同样也限制了其对用户端实际经历进行精确测量的功能，尤其在用户端是没有高速的接近主干网连接的小型企业时。
要获得更贴近真实的性能数据，你必须对典型的用户连接进行监视，包括拨号连接和宽带连接到本地和区域性的ISP。Porivo技术公司正是这样做的。
与在1层ISP主干线上建立专业监视站点的做法不同，Porivo的监视复查服务建立在实际因特网用户的个人计算机上。Porivo从典型用户中征求监视者，这样它的性能样板能够更好地反映一个站点的真实历程。  
实际上，Porivo能够在任何给定测试条件下调整其样板以反映总的在线人数和满足用户的特殊需要。如果你仅仅对于拨号连接到二级ISP的东海岸用户的经历感兴趣，你可以只得到关于这些连接的信息。
Porivo的架构不要求监视者亲自访问被测试的网站，它也不跟踪监视者自己访问的网站。驻留在监视者计算机上的基于Java的代理程序将执行测试脚本。监视者使用一个投票模板获取这些测试脚本，并定期登录到Porivo服务器上，报告他们获得的技术曲线，然后接受下一个需要他们参加的测试。
这些测试脚本覆盖的范围从简单的静态页面访问到整个购买或其它交易过程的每一步。每个单独监视者的工作负载取决于它在Porivo系统中所承担活动任务的多寡和对该监视者的特定要求以及在特定时间段内做相同测试的其它监视者的数目。监视者一但完成测试就返回结果给Porivo。
一些Porivo监视者待在公司的网络上，但企业的网管也许根本不知道。Porivo的代理人产生的浏览流量看起来与其它80％的网络流量没什么不同。监视者通过442口上加密的会话接受指令，所以本质上其活动从正常的SSL交易中很难辨别出来。
Porivo声称有大约15000台机器用于测试。在任何时刻，约有5000台机器能被接受参加一个测试，可提供一个比其它监视服务大得多的样本。这么大的样本往往使Porivo的后台系统在一天之内必须处理5亿条数据。
监视服务所能提供的监视点的数量十分重要,但并非唯一决定该服务效率的因素。该服务其他的属性还包括可以监视给定在线过程的每一步和处理重定向和其他站点的特殊性以及易于修改测试脚本哑以适应站点的变化。
BMC软件公司的服务解决方案副经理克雷.戴维斯说：“对因特网架构的监视和对应用程序架构的监视。前者会给你很多关于性能问题方面的信息，有这些信息你什么也做不了；而后者可以让你知道你能处理什么问题。”BMC于2000年5月并购了Evity及其SiteAngel服务，从此进入了防火墙外监视领域。SiteAngel服务可以按脚本进行静态、动态和个性化定制页面的监视，并对性能问题的管理者发出警告。
戴维斯认为SiteAngel只能从因特网上的两个点进行监视不是缺陷。第一，如果监视的目的是考察后台应用架构正常与否，增加更多监视点并无意义。重要的是监视脚本的健壮性，即有效跟踪给定会话中每一步的能力。第二，因为这些监视服务要求产生许多不同的综合交易，设成百上千个监视点也许会导致网络阻塞从而影响站点的性能。
两个监视点允许BMC使用一个简单的过程来防止用户得到误报警。如果一个监视点探测到了问题，它不会马上报警，而是用另一个监视点进行同样的交易以确认是否真的有错误发生。如果有，系统才发出警报。如果没有，-即使该事件已被记录下来-，BMC假定是因特网发生了短暂的波动。戴维斯人为典型的监视服务使用大量的监视点而不对事件进行过滤，这样一来会产生大量的琐碎的报警。
一些已经使用过BMC的Patrol企业应用管理解决方案来监视他们内部页面结构的IT经理现在开始使用SiteAngel。他们相信SiteAngel可以更加易于把他们的外部监视数据整合到其企业管理咨询中去。Patrol可自动执行的特点允许他们用SiteAngel的触发器补救过程捕捉到特殊类型的事件，诸如应用服务器的停止和重启。
水星公司的产品经理大卫.赖希曼认为用户不需要从同一家公司购买外部监视服务作为企业管理控制台的集成。如果你的防火墙外监视服务可通过XML给你数据，你就可以使用任何企业管理软件商的API将数据送给你的控制台。
水星公司的防火墙外监视服务是ActiveWatch，它可以从500个点登录和监视综合交易过程。水星公司也提供其他监视页面应用的方法。通过被动地监视用户在防火墙内部的会话，该公司的Prism工具无需安装任何代理程序就可以推断终端用户的经历。
Prism观察用户浏览器和站点之间的TCP/IP连接，从而得到点对点连接发生延迟的数量。EXPERIENCE COUNTS 更进一步采用了这种概念。水星公司还提供一种叫TwinLook的应用程序，可视化显示Prism收集的最终用户的站点经历。电子商务和网络经理可使用Prism来查看特殊用户的经历。
ETPrism 和 TwinLook 是Topaz suite的被动监视元件，Topaz suite还包括全面的后台诊断。这些诊断有助于电子商务技术人员找到问题的根本原因。水星公司给Topaz suite
增加了一个新的应用，叫做AutoRCA，可提供知识库和规则引擎用以分析和自动解决网络应用问题。
AutoRCA允许用户添加自己的知识条目和规则。考虑到Topaz仅从一个应用服务器本身就可以拖出约1500个不同的统计数据，这些辅助诊断措施应该是重要的。用户与专家经验的强大联合对于从噪声中发现真正的管理信号是必要的。如果你愿意，可以自己做；监视服务提供商没有必要从用户的角度理解页面应用和服务。
一些公司只是简单地在他们的数据中心或远处的办公室架设几台个人计算机作为监视站。采用几个不同的ISP帐号使这些机器连接到因特网，他们可以评价不同用户群的性能。这种方法的缺点是需要写大量的脚本、事件登录和报告软件。用他们自己的ISP连接，这些桌面操作系统也需要他们自己的防火墙和防病毒程序。对于连续内容，通常需要不同的方法，因为不可能监视离散的HTTP步。
Keynote专门编写了这种程序。对于采用DIY方式的公司，典型的监视结构涉及到通过公司网络为一些监视点设置第二条到数据流源头的连接。这种方法可使你把个人计算机实时看到的和服务器所传输的做一个比较，从而揭示任何不正常的延迟与失败。页面管理者应该超越技术属性，开发出能够校验整体性的系统。
这就是许多页面管理者将验证用户机制包含到他们的站点监视系统中的原因。这些机制包括时间戳对超时进行报警和测试特定数值是否低于给定值的脚本。当内容由第三方提供时，这些测试尤其重要，因为仅凭延迟和可用性监视并不能断定第三方是否正经历着某种类型的结构困境。
其他系统走得更远，他们跟踪站点导航、放弃的购买这样的统计数据。这些服务超越了技术性能的范畴，提供将整个站点在市场、销售或客户服务方面的报告。这些服务包括Webhancer和Gomez。
正如用户观点的解决方案颇具价值，没有什么能够替代对网络架构的有效监视。用户的观点可以警告页面管理者注意某个问题，甚至有助于分析问题的根本原因，但是它们并不能提供更传统的专业化工具所具有的诊断能力。精细的数据库监视对于保证今天复杂的页面应用尤为重要。最有效的监视提供关于所有系统请求的全面信息，包括等待时间、搜索范围、缓存使用效率以及数据库连接时段等。
传统的数据库快照仍然很关键。通常在周二的11:00 am不大可能发现上周五4:30 pm时发生的问题。传统的网络和系统管理工具在故障排除和优化性能方面也扮演着重要的角色。但是，考虑到用以支持网络服务的结构的复杂性，很明显技术工具本身不足以查出服务级的问题。在绝大多数情况下，故障排除本身还需要整理。
故障排除有三个阶段。首先是发现问题。此前提到的一种监视方法可以指出问题所在。下一步是筛选。它不是要找出问题的直接原因，而是采取一些措施减轻问题的影响。最后，一但紧急情况得到处理，专家将确定根本原因并做必要的修改以保证其不再发生，至少不以同样方式发生。
涉及到这个过程的技术专家的数量和专业是十分重要的，最好有一名DB2专家坐阵数据中心，一名LINUX专家负责网络开发，一名宿主服务提供方的系统管理员。这些人员之间用电话和电子邮件通信联络。少数组织使用自动工作软件来管理升级和解决方案，从来没有被证明过有什么方案能够把来自外部服务提供商的技术人员融入到这种软件管理过程中去的。
这种问题管理的缺陷不仅减缓了发现和解决的进程，而且使问题历程的再现更加困难，历程的再现对于创建可加速未来问题解决的知识库十分有益，对内部和外部技术人员提供技术支持的水平也可进行跟踪。
即使页面管理者评价了新的性能问题定位和解决技术，他们也不能重新评价他们应付应用管理挑战的过程，这是致命的。支持电子商务的架构变得日益复杂。跟踪电子商务性能的工具正较之从前可提供更多更丰富的信息。那些不能调整策略以以应付这种复杂局面的网络管理者不大可能继续生存下去。