作者：美國福祿克網絡公司

    組織內的企業應用系統的重要性正在普遍地以幾何級的速度增長。企業網絡上運行的要害應用系統種類，會按業務的取向，采用從SAP、Oracle等CRM應用系統到ip電話（VoIP）到自身開發的應用系統。

    無論你的組織認為哪些應用系統更為重要，有一件事始終是不變的：假如這些系統運行不暢，無論是因為網絡原因還是因為與應用系統服務器有關的問題，企業的效率將被嚴重地降低。

    比如，一家零售企業可能會因為其面向客戶的網站上的應用系統性能不佳而失去很多著急的用戶，明顯地降低營業收入。一家制造業公司可能會因為ERP系統不良，引起生產線缺貨停頓造成不能按期交貨，需要承擔巨額賠償金。一家醫院因為病歷傳輸慢，不能為其病人提供重要的醫療服務。造成這些應用系統性能不佳的原因可能與應用系統、服務器或者網絡有關。

    由于企業內對應用系統越來越多的依靠性，應用系統性能不佳造成的潛在影響，諸如營業額降低、成本和賠償金或者對客戶的不充分服務等問題，都增加了企業的風險。這些不斷增加的潛在風險正是改善網絡應用系統的集成性的要害動力。

    理解網絡應用系統的集成性

    要理解網絡應用系統的集成性前，需要對應用系統性的歷史有一點了解。為了優化網絡應用系統集成性，重要的不僅僅是理解個別的最終用戶、網絡、服務器以及應用系統，還要理解這些元素是如何彼此配合的－這些可能超越了一般網管員以往關注的領域。很明顯，網管員不能再只負責連通性和帶寬問題了。實際上，網管員也需要密切地參與對應用的監控和故障排除等工作，而這些工作過去都是應用系統治理團隊的責任。

    假如企業重要的應用系統是跨網絡運行的，分區來監測和治理應用性能問題，是非常低效的。用分區治理方法時，不同的小組將負責企業和網絡的不同區域，各自為政－服務的提供商負責廣域網的接入網絡和端口，網絡治理小組只治理CPE和其使用，而應用系統小組則負責應用系統和服務器。即使有這樣的局限性，多數企業使用的都是這個結構。

    保證網絡應用系統集成性需要在應用系統和網絡資源的交叉點處提高業務、安全和故障排除的工作效能。一般，人們都能了解網絡應用系統集成性的價值。然而，多數企業都不太能夠具體了解個別應用系統和基礎結構之間錯綜復雜的關系。隨著遠程用戶的增加和不斷出現的基于網站的應用系統，如客戶關系治理（CRM）系統和企業資源治理（ERP）系統等，網絡的壓力增加了，網管員的壓力也增加了。不斷的網絡技術發展，從結構替換到MPLS和以太網，還增加了網絡經理的責任。

    工作地點分散化

    隨著商業應用系統變得越來越分散，它們也使得勞動力得以越來越分散。多年以來，商業機構已經借助了信息技術使其走出單一的設施來控制房地產成本，將資源安置于勞動力密集且接近客戶的地方。根據Nemertes研究院的研究，這些變化已經發展到相當的程度，只有13%的雇員在總部大樓或場地內工作。

    雖然勞動力分散從整體上為企業帶來了成本的降低，但他往往會給IT部門帶來負擔。每個新的工作地點，無論是只有一個雇員還是有一百個，都必須有一個可以供企業應用系統運行的新環境。為了治理這個過程，高度分散化的行業，如銀行，已經開發出了可以嚴格應用于不同地方的“參考設計”，以將可變性降低到最小。

    不過，即使是在最統一的環境中，因為不同的應用系統使用模式、再利用的陳舊資產以及不可避免的WAN/MAN連接的不同，因工作現場不同的差異總是會出現。更糟糕的是，家庭辦公令IT部門保持完全統一的環境的努力變得幾乎完全不可能，因為家庭辦公涉及的連接可能涉及多個ISP和雇員自己的家庭網絡。

    應用系統的挑戰也在增長

    除了要解決越來越沉重的裝置結構和組織性問題，網管和IT經理門還得面對數量不斷增加的企業應用系統所帶來的復雜問題。處理新的應用系統、安全漏洞、帶寬攫取以及分布式應用系統，所有這些都帶來了挑戰。使這樣的挑戰更為嚴重的是網管和IT經理正在試圖以少管多（以較少的人力和財務資源治理更多的地點、設備、應用系統等）。

    無論是傳統的應用性能工具還是網絡治理工具都不能提供網管員為了滿足這些新的、不斷增加的責任所要求的功能范圍。現在，更輕易看到一個“鴻溝”挑戰著網絡應用系統集成性。

    網絡系統集成性的鴻溝

    今天，不論是哪個行業，不論企業大小，在大多數企業中都存在著應用系統和網絡性能之間集成性的鴻溝。這個鴻溝引致在理解、關聯及分隔企業網絡基礎結構和應用系統性能之間的問題方面時的困難。更為重要的是，這個鴻溝強迫網管和IT部門只能被動地解決性能問題，或者采取“救火”式的行動，而不能主動地優化基礎結構和應用系統性能。彌合集成性鴻溝要求將每個地點的網絡性能數據和應用系統信息關聯起來。

    有幾種組織性和結構性的趨勢使得這一集成性鴻溝變得更寬更深：豎井式（siloedorganizations）結構的影響、分散式工作地點以及開放式網絡結構。

    豎井式企業（SiloedOrganizations）的影響

    當今的大多數企業都有這樣的結構：一個團隊專注于網絡基礎結構，包括通訊和網絡CPE；而另一個團隊則負責應用系統和應用服務器。在典型情況向，每個團隊都有截然不同的職責及其自有的工具來監督其組件－1-3層屬于網絡團隊，4-7層屬于應用系統團隊（見圖1）。這種“豎井式”治理方式，加上網絡上越來越多的VoIP和基于互聯網等分布式應用這樣的新趨勢，使得對應用和網絡性能的優化變得尤為困難。

    圖1：“豎井”式企業的影響。

    通常，假如最終用戶覺得應用系統“不好用”、“速度慢”或者“性能不好”，他們就會投訴，從而觸發一連串的排除故障的流程。典型情況下，網絡總是“在被證實無辜以前被看成是有罪的”。所以，負責網絡的團隊開始測試網絡組件，從ping路由器到聯系服務提供商來測試核心廣域網（WAN）環路。即使網絡總是最先受到責備，通常情況下，網絡基礎結構是健康的。

    多數企業采取的第二個步驟是將問題“轉”給應用系統團隊。該團隊則從個別服務器應用到應用系統性能開始進行測試。多數情況下，因為缺乏端對端（end-to-end）網絡連接造的可視度，這些測試往往不能了解最終用戶的問題。結果，分隔和解決問題變得非常困難。許多豎井式企業都是用“我們對他們”的心理來對待應用系統和基礎結構的治理。不同的團隊不是團結一致解決性能低下的問題，而是把問題都推到別的部門，讓另一個團隊來解決。這往往導致彼此之間的指責。因為大家都孤立地工作，缺乏大家可用的性能數據，健全性鴻溝擴大了。不同的團隊在基礎結構和應用系統方面只有局部的視野，并且不能了解應用系統、服務器和網絡基礎結構性能對相互間的影響。

    未知或不曾預料的網絡應用在理想狀態下，網絡團隊應在新的網絡應用出現前至少三個月就接到通知。有了這么長的預備時間讓他們可以測試與性能有關的問題，包括應用、可接受的延遲標準以及對現有的應用的影響。

    不過，在現實的世界里，網絡團隊對網絡上即將運行的新的應用系統的了解很少，甚至毫無了解。網管員經常被迫在應付日常繁忙的工作外，后知后覺地試圖了解新應用的影響。除此之外，在對網絡組件的了解有限的情況下，要想了解應用從最終用戶通過網絡到應用服務器再返回到最終用戶的過程和狀態可以說是千頭萬緒。這就強化了很多企業只能被動應付問題的特性，等待問題發生，然后再尋找措施解決問題。

    案例：

    未知或不曾預料的應用系統一家大型企業正要將其客戶支持部門的一部分搬到一個新的地方，以減少費用。網絡團隊接到搬遷通知，并預備了一個網絡來處理新辦公場地未來可能有的以及傳統的應用。該客戶支持團隊使用有一個CRM系統，所以應用系統團隊在新的辦公場地測試了CRM系統，其性能遠遠超過需求。

    然而，在網絡割接之后，CRM應用系統的性能非常差，麻煩開始了。網絡團隊測試了網絡和CPE，所有東西都很正常。應用系統團隊測試了所有服務器，發現也是全部正常。經過大范圍的測試，花費了大量的時間，人們發行，CRM應用系統過度使用了網絡，這導致了應用系統運行的低性能，并嚴重影響了客戶支持團隊的工作效率。

    即便網絡團隊收到了搬遷辦公地點的通知，他們并不了解CRM系統要消耗大量的帶寬。在搬遷之前，客戶支持團隊在總部辦公，CRM服務器也是安置在總部辦公地點內。這一高度消耗帶寬的應用系統原來只是在本地千兆以太局域網（LAN）上運行，而現在則使用的是較小的WAN網絡的有限資源。網絡團隊預留了傳統遠程場地應用所需的網絡資源，卻不知道新辦公地點的實際情況。

    帶寬攫取

    找到并隔離帶寬攫取源可以幫助企業節省許多寶貴的時間和資源。帶寬攫取可能產生于授權或非授權用戶，用戶可能使用授權或非授權應用系統攫取帶寬（見圖2）。

    圖2：授權和非授權用戶及應用例子。

    當資源有限，網絡和應用系統性能收到負面影響時，迅速找到帶寬攫取以減少企業風險是非常必要的。

    然而，在出現帶寬攫取時，大多數情況都是間歇性的。這意味著使用峰值出現在一段時間，接著就間歇性地回到普通狀態。

    對于間歇性問題，隔離和排除問題變得更為困難，耗時也更多，因為你可能總是落在問題的后面。

    使情況更為糟糕的是，多數間隙性問題的影響隨著時間的推移會擴大－這意味著問題不及早解決將會變得越嚴重。

    安全漏洞-服務中斷/病毒攻擊

    在過去幾年里，病毒或服務中斷攻擊幾乎給每個企業都帶來了負面影響。有些企業受到的影響可能只有一個小時，而有些企業受到的影響則可能長達幾天或幾個星期。影響的時間越長，企業的風險就越大。即使有了最強大的防火墻和抗病毒軟件，企業的基礎設施也可能會面臨危險。

    病毒和服務中斷攻擊的性質造成企業在解決問題方面被動應付，因為你不知道下一個問題什么時候會在什么地方發生。即使在這樣的案例中，辨別和排除問題總是被動的，攻擊發現的越快，受到影響的最終用戶被清理的越快，企業蒙受的風險就越小。

    案例

    帶寬攫取

    帶寬攫取的間歇性性質使得它更為難以跟蹤和隔離。肯塔基一家中型企業曾經經歷過其ERP系統性能低下的情況。網絡團隊和應用系統團隊分別試圖隔離原因。但是，在問題解決之前，性能低下的情況就消失了。兩個團隊不能找到原因，問題不了了之。

    第二天，同樣的系統問題又出現了，而且更明顯了。

    這一次，兩個團隊試圖再次解決問題。他們在現場找來探測器。兩個小時后，就在探測器啟動時，問題又消失了。探測器在現場被保留了幾天，問題沒有再次出現。

    六天之后，問題又出現了，情況變得更為嚴重。

    肯塔基辦公室的效率受到負面影響，網絡團隊和應用系統團隊對找出問題都沒有進展，因為他們不能定位這個間歇性的問題。后來，人們發現問題的真正原因不是單一個帶寬攫取者攫取了全部帶寬，而是大量的用戶在籃球比賽期間通過網絡收聽本地籃球隊的比賽轉播。

    他們都是授權用戶，使用認可的語音流應用，但是對比賽感愛好的人太多了，這成了出現問題的罪魁禍首。正是聯賽中當紅的本地籃球隊影響了企業的效率！

    分布式應用系統

    以前，多數企業都會建立核心數據中心，星型向外輻射到分支的網絡結構。基于這種類型的結構，企業會用一個集中的治理平臺來監測性能。

    隨著IP虛擬個人網絡（VPN）和基于多協議標識交換（MPLS）的網絡的引入，一些企業啟用了部分和全面協調的網絡，意味著分支機關可以彼此直接通訊而無需先將應用業務通過數據中心轉發。與新結構緊密接軌的是VoIP和基于互聯網應用廣泛啟用的趨勢。比如，兩個分支辦公室之間的VoIP通訊，因為無需繞到核心數據中心，會更高質量和更少受時延所困擾。

    案例

    安全漏洞-服務中斷/病毒攻擊

    一家制造業公司最近受到一次服務中斷的影響。最終用戶慢慢也受到影響，不良通訊也開始在網絡上傳播。總部辦公地點有一個高速的網絡鏈路，所以，這次病毒的影響在經過一段時間以后才表現出來對網絡的過度應用。一旦網絡應用達到了帶寬的最高值，用戶受到了影響。現在，企業必須作出反應來解決問題。起初，他們要終止病毒通過路由器設置進行傳播，接著要努力一個一個地清除受到影響的工作站。

    通常，高速網絡鏈路對應用的性能來說是寶貴的資源。然而，在這種情況下，它反而成了障礙。因為需要很多的用戶受到影響，才能把整個鏈路的帶寬占滿。這樣，問題有足夠的時間擴大，造成大量的通訊擁堵和大量用戶的感染。最后，解決問題并清除受感染的用戶所需要的時間和資源則暴漲起來。

    分布式應用系統的好處在于可以提高效率，降低帶寬強度，且減少延遲感。不過，因為不再有通過總部的單一傳輸點，對分布式應用系統的監控和故障排除就變得越來越困難了。在每一個遠程地點保持專有網絡和IT員工的可行性非常低。這種視野的限制從而增加了企業的集成性的鴻溝。

    彌合網絡應用集成性鴻溝

    即使挑戰越來越大，網絡應用集成性的鴻溝也越來越寬，我們還是有希望的。有三個重要的步驟可以幫助你彌合這集成性的鴻溝：理解應用系統和網絡組件，對最終用戶的經驗的進行深入了解，隔離和解決性能問題。一旦你把握了這三個概念，你將能實踐健全的網絡應用。

    第一步：理解應用系統和網絡組件

    在最近對網管經理們的一次研究發現，很多企業中都存在這一個令人困擾的趨勢：四分之三的被調查者說，他們缺乏對網絡上的應用系統的足夠知識2。一直以來網管員都很了解網絡，而應用系統經理了解應用系統。多數網管員了解與路由器、DSU/CSU以及網絡相關的問題，當對應用系統實際上是如何運行的卻不了解或了解甚少。更重要的是，傳統上的兩個團隊對應用系統和網絡之間是如何互動的都沒有具體的了解。

    要治理應用系統使用網絡的方式，要求對“實際”應用系統以及商業政策有清楚的了解。只有有了這樣的知識，IT部門才能作出最好的決定，使應用得到控制。如圖3所示，應用系統的“實際”狀態和商業的政策的要求是保證健全網絡應用的兩個共存的方面。

    圖3:應用系統“現實”和商業政策問題之間的差別。

    有關應用系統現狀的問題就像是報紙記者的筆記本上的問題一樣：使用網絡資源的應用系統都有哪些？傳輸負載來自哪里，又去向哪里？誰在使用信息？應用系統需要多少帶寬？什么時候需要？

    這些問題的答案構成的改善的基線。

    選擇要進行哪些改善？怎樣最好地應用這些改善？要回答這些問題，便須要政策。政策問題所詢問的事情是怎樣才能達到需要的網絡狀態。

    同時得到這兩種問題的答案一直是困難的，因為應用系統團隊和基礎結構團隊都沒有信息搜集工具來提供有用的分析。

    第二步：洞察最終用戶的經驗

    為了實現經濟效應，IT、網絡和應用系統的各個團隊傾向于被集中于總部、數據中心或大的辦公地點。雖然這些地方往往有更多的雇員和員工，遠程地點對企業來說也非常重要，無論是銷售部門、配送中心、零售點還是制造工廠。假如這些地方受到應用系統或網絡性能低下的嚴重影響，企業的財務和生產力也將受到影響而造成損失。

    應用系統的用戶通常是糟糕的網絡應用的首要原因。當網絡應用集成性的鴻溝存在的時候，重要應用系統的意外中斷或不可接受的性能低落非常難以理解和治理。為了恰當理解對最終用戶的影響，企業必須能夠監控和治理網絡、CPE、服務器和應用系統。當應用流通過WAN核心或其他地方的本地網絡，流經本地網絡，最終流到應用系統服務器再返回的時候，應用流視圖對了解性能是非常重要的。

    假如沒有完整的應用流視圖，企業只能回到同時治理幾個個別組件上，而沒有全盤的熟悉來了解性能低落的原因和影響。

    第三步：隔離和解決性能問題

    對當今的企業來說，另外一個重要的挑戰是如何隔離造成性能低落的原因。在治理個別組件的時候，非常輕易對性能產生狹窄的熟悉，這可能會導致部門間的互相指責。這些策略只是減慢了發現和隔離問題的過程，而更重要的是減緩了問題的解決速度。

    通過在第一步驟和第二步驟中了解應用系統和網絡組件以及最終用戶體驗，隔離問題就變得更加輕易了。通過治理整個應用系統流，查明在1-3層和4-7層之間的問題也就更加輕易了。一旦問題被隔離，解決一個特定的問題就更為簡單，而不需要在對造成性能低落的原因了解甚少的情況下去同時排除多個領域的問題。

    理解應用系統問題的困難

    過去，網管員對應用系統性能了解很少甚至沒有了解。然而，在這件事上存在著一個基本的兩分法，解決應用系統性能問題的第一步取決于網管員的能力。

    因此，了解應用系統可用性的重要性顯然是非常要害的。應用系統可用性是在完成與應用系統有關的任務時用戶保持有效工作的時間，如向CRM系統中輸入數據時，從下載網頁到下好訂單的時間，或者通過ATM跨行提款所需要的時間。

    令網管員感到挑戰的是有很多組件會影響應用系統的可用性，而這些組件都必須配合應用系統的工作。比如，不僅每個用戶都必須訪問具備合理性能的應用系統服務器，而且應用系統服務器還必須能夠訪問應用系統所依靠的所有組件。例如，一位在線零售商在服務器上有一個單獨的主頁，而該主頁分別從不同地點的不同服務器上的過往訂單、曾經變化的非凡要求以及個人推薦中提取信息，這些組件中的每一個都必須正確而高效地工作，以使最終用戶的體驗令人滿足。

    測量應用系統響應時間是非常有價值的。

    應用系統響應時間是用戶的客戶要花多久才能從應用系統服務器得到其所要求返回的信息。該響應時間是兩種傳輸延遲影響的結果，即在一個網頁上發生許多分別的傳輸要求下載對象，以及在每個傳輸完成的過程中發生的不同組件的延遲。有些延遲是網絡設計和預先選擇的結果，比如帶寬、距離以及跳躍數（hop－count），而有些延遲則是可糾正的異常造成的，如擁塞、掉包以及中繼問題。另外，還有一些延遲與網絡協議有關，或者與應用系統選擇使用網絡的方法有關。最后，性能問題還可能是應用系統及其服務器的問題造成的。

    由于缺少工具搜集測量數據并將數據分解到各延遲組成部分，對應用系統響應時間的測量一直都是問題。在很多排除故障的案例中，要想得出有效的結論，長時間地以響應時間為基線并進行跟蹤是非常重要的。同樣重要的是，能夠分析延遲組件來找到性能問題的根本原因。

    制定集成性網絡應用系統解決方案

    當傳統的網絡治理與商業應用系統成功交付的所有權相結合的時候，一門新的IT學科就被定義了：集成性網絡應用系統。它采用全面的方法反應商業應用系統和用戶的遠景。該方法要求同時關注應用系統和網絡基礎結構，以及這兩個要素如何協同工作增加應用系統價值，而不是僅關注其中一個要素。

    集成性網絡應用系統不僅是一學科，而且還是一個過程。它是一個工程設計過程，通過這個過程，商業應用系統的需要和用戶的需要得以與適當的網絡資源相匹配。它還是一個質量過程，該過程根據需要測量性能。

    為治理應用系統所運行的基礎結構而成功實施一個過程并不是一個意外。行業論文“應用系統性能治理”的作者LynnNye說：“對應用系統性能治理的堅實理解和交付必須基于一個事實，那就是網絡和應用系統共同構成體系。體系的結構設計和配置是為了給用戶提供反應迅速的性能和業務上的成本效率。”

    集成性網絡應用系統基礎結構本身必須為治理而設計，這是很要害的一點。雖然它不需要在一夜之間完成，但它的確需要在一段時間內有目的地得以實現。升級基礎結構的決定也應該總是兼顧到改善治理能力。

    集成性網絡應用系統的組件

    IT組織依靠只依靠在網絡要素的任意方面，如CPE、網絡、應用系統、服務器等，治理網絡和應用系統的工具上是不夠的。新的工具需要跨過簡單的網絡和設備治理范例，來使網絡應用系統集成性的過程得以實施并自動化。

    1.支持集中的方法

    作為基礎設施的一部分而部署的方案將使基礎結構治理的集中方法得以實現。只有在該方案包括了后端服務器和數據庫以將治理數據放在一起的時候，對整個基礎結構的全盤了解才有可能。然而，同樣重要的是，集中系統不要變成“治理信息島”。

    最佳的解決方案使得治理信息能夠在治理系統的不同組件中迅速交換，以實現從警報治理到集中化報告的各種功能。另外，同樣重要的是該系統要能夠隨著基礎結構的成長而成長－要能存儲足夠數量的數據，要有足夠的方法從基礎結構中采集數據，要有足夠的案例以供分析。

    2.提供完整的應用系統可視性

    IT經理們需要具體、準確的信息，這樣他們才能在給重要應用系統分配適量網絡資源的同時，確保其他應用得到控制。這意味著對部署于整個企業內部的應用系統獲得完整的熟悉－不只要了解有哪些應用系統（現實），而且還要了解它們從哪里得到服務，它們對誰服務，服務的頻率如何。

    3.實現信息控制策略

    控制帶寬是集成性治理網絡應用系統的一個最基本的工具。在不同場合和不同時間里，幾乎所有的業務都曾嘗試過通過分配帶寬來解決應用系統問題。問題是帶寬并不總是按照你的愿望到達你想讓它去的地方。

    IT經理們必須回答一個緊迫的問題-是否需要增加帶寬？他們還必須算出要增加多少帶寬。有了正確的信息，就能夠調整應用系統使用網絡的方法，或在路由器中采用基本的傳輸隊列方法來使網絡應用更加順暢。集成性治理網絡應用系統的工具必須提供足夠的細節來引導經理們就帶寬問題作出正確的決定。

    4.經驗質量測量

    集成性網絡應用系統的要害整體指標是最終用戶的質量體驗（QoE）。應用系統可用性和應用系統響應時間決定了QoE。一個有價值的治理工具可以測量這兩個要素，并將這兩個要素分解到相關組件。將這些要素跨過物理和邏輯結構進行劃分可以提供改善性能的線索。

    5.將應用系統問題和基礎結構根本原因聯系起來

    假如不能迅速地解決問題，再好的應用系統性能分析都是沒有用的。只提供給用系統分析的工具在揭示基礎結構問題方面的能力是有限的。集成性治理網絡應用系統要求能夠直接將最終用戶QoE的不良體驗與根本原因相關聯，無論問題是IP層上的服務等級，還是在物理層上的錯誤。同樣重要的是，該工具還必須將應用系統的帶寬要求和第二層所提供的帶寬相對比。

    6.量化業務影響

    即使是最有說明性的應用層分析，也只有能夠清楚表示業務之間的關系時才是有用的。對了解受響的用戶,對了解性能問題的變化，對分配資源的優先性來說，其價值是無法衡量的。這對防止性能降低也是非常重要的。

    圖4：網絡應用系統集成性解決方案。

    集成性網絡應用系統的前景

    今天，已經有了無數種治理方法供企業選擇。但是，大多數解決方案都不能滿足全面網絡應用系統解決方案的要求。報表系統解決方案是靜態的，不能提供足夠豐富的、用于排除故障的數據，而單一地點的解決方案不能治理較大的系統或復雜的分布式結構應用系統。大型的治理框架為大量設備和地點提供了“自上而下”的狀態，但充其量只能起到一個‘儀表盤’式的簡單指示作用，而不能為隔離和解決問題提供具體信息。

    報表系統-在需要迅速解決的問題方面反應遲緩

    在提供基礎結構整體情況方面，或者，在生成用于面向高級治理層的報告中的圖表方面，報表系統是非常理想的工具。報表系統通常從各種SNMP設備以及其他治理系統中收集數據。它們還可以總結信息，將數據以圖表的形式表現出來，甚至可以在線發布這些數據。

    不過，這些系統往往在豐富性、質量以及所提供的信息的表現形式方面有缺陷。由于受到來自各種設備的定期數據的限制，大多列出SNMPMIB，這些報表系統往往不能提供辨別性能問題產生的根本原因所需的深度信息。在排除重要的性能問題方面，報表系統的效率也不夠，就像用一桶水試圖澆滅整棟房子里的大火一樣。

    單一現場治理工具－缺乏可擴展性

    單一現場治理工具對一個較小的環境來說非常理想，它可以對應用系統通訊提供全面的信息，以便深入了解網絡使用情況。由于沒有后端系統，工具自身使用WebGUI，這樣的工具非常易于部署和維護。

    不過，單一現場治理工具不能提供最好的分析，非凡是對正在增長或更為復雜的網絡來說。在需要增加工具來治理更多的現場的時候，成本會很高。當需求增加的時候，單一現場治理工具在同步增長方面也有嚴重的問題。

    即使增加現場治理工具仍然不是最佳解決方案，因為IT部門仍然缺乏對所有層面的傳輸量的了解，而這往往正是性能問題的根本原因所在。部署多個治理工具的公司很快就會發現，它們沒有一個集中化的治理系統來將所有的信息歸納到一起。所以它們經常需要構建數據庫，以便對網絡情況有全面的了解，并將這些信息與其他治理工具共享。

    大型治理框架-在所有任務方面不夠理想

    有些大型公司使用一個治理框架產品，將IT環境中的大多數因素的治理能力都囊括進來，其中包括路由器、CSU/DSU、網絡線路和服務器。這樣的治理框架在監控一個網絡內跨多個組件的基本狀態（如“紅燈/綠燈”）方面表現良好。不過，這一方法的問題在于多數這樣的系統僅僅善于基本監控，而其他方面的能力則平淡無奇甚至相當糟糕。比如，一個單一治理框架可以通知網管員在某一地點出現宕機情況，但往往它不會提供強大的隔離和排除故障的工具，來判定問題的原因是電源中斷，CPE故障，帶寬被不正常流量占據還是網絡中斷。

    企業往往將采購單一治理系統作為其將治理部門標準化，降低其控制成本的方法之一。最初，它們可能受益與這些系統的質量特點。不過，經過一段時間，它們可能就會發現這些系統缺乏能力承擔所有重要的治理任務。擁有長期使用這類系統的經驗的企業往往經歷著在這些系統上的低投資回報率，而且需要采購補充治理工具。

    UpTime®SelectTM產品：優化集成性網絡應用系統

    通過UpTime®SelectTM產品,Visual網絡公司將性能治理工具提升到了一個新的高度。這一全面的解決方案是集成性網絡應用系統的理想產品，有助于企業彌合集成性鴻溝。該系統為IT經理們提供了一個在整個基礎結構中分析應用系統和網絡組件所需要的工具。

    彌合集成性鴻溝

    VisualUpTime®SelectTM產品是為企業提供的一個全面的、單一資源的解決方案。該方案可以有效地治理網絡應用系統集成性中的七個要害部分：

    1.支持集中的方法

    無論如何部署VisualUpTime®SelectTM產品，其工具都為流經它們的所有數據提供深度數據包檢查，以收集具體的應用系統性能即使用信息。這些工具將數據上載給用于存儲、分析這些數據的VisualUpTime®SelectTM服務器，并且從每個分析點出發，展現完整的有關集成性網絡應用系統信息。VisualUpTime®SelectTM服務器具備若干其他流行治理系統的接口，以將其對治理生態系統的價值最大化。該解決方案的設計滿足了服務提供商的要求，在處理最大的企業環境方面游刃有余。

    2.提供完整的應用系統熟悉

    VisualUpTime®SelectTM服務器可以提供全網絡的總結性信息，對整個網絡上幾乎每一個應用系統都能做到全面的監控，包括哪些IT團隊以前毫不知情的應用系統。網管員可以深入分析個別的應用系統，找到服務器的地點，看哪些客戶在使用這些服務器，在什么時候使用，使用的程度如何。這些可視性提供了對應用系統資源要求的具體了解，以便IT經理們可以微調其性能，而不需再不斷地求助于增加帶寬這樣的權宜之計。

    歷史分析和趨勢研究有助于找出業務對基礎結構的需求在哪里增長，以便IT經理們可以在性能受到威脅之前就做出調整。這些特點還有助于發現未經批準的、像KaZaA這樣的應用系統對基礎結構的濫用，也能發現為了適當運行業務應用系統，哪里需要更多的基礎結構資源。

    3.實現信息控制策略

    實施控制戰略需要對基礎設施使用情況的深入了解。正因為如此，VisualUpTime®SelectTM產品能夠找出客戶機和服務器之間最活躍的應用系統流，同時提供回溯的能力。分組控制提供了在基礎結構任意點上分析數據流信息矩陣的靈活性－按應用系統、服務器或者客戶工作站。發現傳輸模式和應用系統表現，從而作出使用控制的決定，數據流信息是非常重要的。這些能力還會在病毒或蠕蟲入侵網絡時起到作用。VisualUpTime® SelectTM產品可以表現出攻擊在基礎結構中是如何擴散的，并且能夠迅速標識出受到感染并正在傳播攻擊的機器，以便IT經理們迅速排除故障，解決問題。

    4.經驗質量的測量

    為了實際了解最終用戶對應用系統性能的看法，VisualUpTime®SelectTM產品提供對服務器響應時間、吞吐量以及各階段具體應用系統傳輸矩陣的回溯分析功能。這一層次的數據和系統測量網絡潛力的能力、吞吐量以及數據包損失一起，在應用系統軟件團隊和基礎結構運行團隊之間避免互相指責的同時，幫助隔離出造成性能低下的原因。這些能力還可以形成IT部門及其業務單元客戶之間應用系統SLA的基礎。

    5.將原因和系統問題關聯在一起

    無論性能問題發生在哪里，VisualUpTime®SelectTM產品獨特的挖掘功能都有助于發現性能問題的潛在原因。與那些關注應用系統層的解決方案不同，VisualUpTime®SelectTM產品分析所有的層面和所有的時間，并將分析結果存儲于一個數據庫中。這樣，當系統問題出現時，IT經理們就能馬上一層一層地在歷史數據庫中挖掘，以揭示問題的原因。VisualUpTime®SelectTM產品已經存儲了這樣的分析，而其用戶界面也很輕易找到。

    6.量化業務影響

    IT經理們可以依靠VisualUpTime®SelectTM產品對應用系統、現場測試以及受現有問題困擾的用戶來話可以獲得更好的熟悉。通過迅速找到、隔離和排除在第1-7層的性能低下的問題，通過改善集成性網絡應用系統，會大大降低負面影響。

    最后，VisualUpTime®SelectTM產品是一個易于部署的解決方案。通過彌合集成性鴻溝、優化集成性網絡應用系統，它能夠為IT機構和企業從整體上提供結果。

    VisualUpTime®SelectTM產品在現實世界的案例

    在本白皮書的較前部分，若干發生在真實世界中的案例說明了優化集成性網絡應用系統的困難：未知或不曾預料的應用系統，帶寬攫取，安全漏洞。當我們突出介紹VisualUpTime®SelectTM產品在發現、隔離和排除這些問題時所表現出的能力時，每個情景都得以重新評估。

    未知或不曾預料的應用系統案例

    一家大型企業將要將其客戶服務部門搬遷到一個新的地點。客戶支持團隊現在通過WAN應用一個CRM應用系統。當割接的時候，企業的整個客戶支持機構受到了負面的影響，直到幾個星期后對網絡進行了升級。并沒有災難性的原因導致了這樣的問題，而是因為在網絡團隊和應用系統團隊之間缺乏溝通造成的集成性鴻溝導致了這樣的問題。在這個案例中，該企業沒有足夠快地找出問題－甚至在問題被重視之前，最終用戶已經受到了嚴重的影響。現在，讓我們看看在同樣的案例中，VisualUpTime®SelectTM產品是如何提前偵測到問題的。

    VisualUpTime®SelectTM產品案例

    網絡團隊提前預備了網絡，測試了CRM應用系統一切正常。然而，一旦所有的最終用戶訪問CRM服務器的時候，網絡出現了超負載現象。網絡團隊按照傳統的應用做了預備，而不知道過去在LAN上運行的CRM用戶和服務器現在要在WAN上使用。企業不得不等待幾個月的時間來重新部署新的網絡。

    VisualUpTime®SelectTM產品自動發現整個網絡中的應用系統。在測試的前一天，CRM應用系統并沒有在WAN上（見圖5）。

    圖5:測試CRM前一天整個基礎結構中的應用系統。

    所以，在測試中，當CRM應用系統第一次接觸WAN時，最終用戶可以很輕易地看到一個新的應用系統出現在基礎結構中。因此，就沒有必要去尋找新的應用系統了，因為VisualUpTime®SelectTM產品可以自動發現它們（見圖6）。

    通過挖掘，網管員可以確定這是兩星期來第一次發生。另外，通過觀察個別的應用系統流和最終用戶，第一次CRM測試可以很輕易被發現（見圖7）。帶寬攫取案例

    圖6:自動發現CRM應用系統第一次通過WAN。

    有了測試方面的知識,這些知識在六個星期前就已經獲得了，網管員早就聯絡了應用系統團隊，看為什么CRM應用會在WAN上。也許，繼續向客戶支持是業務上的需要。然而，企業可以進行更密集的測試，在新場地啟用前就確定需要多少帶寬是的足夠的。在最終用戶受到影響前，企業可以恰當地設計基礎結構的大小，而無需讓他們在受到負面影響后再等待四到八個星期。

    圖7：輕松地找出客戶于CRM服務器之間的通訊。

    帶寬攫取案例

    在第五頁所列舉的帶寬攫取案例中，企業花了一個多星期去排除故障－而從頭到尾也沒有解決！間歇性問題往往給解決問題帶來最大的痛苦和困難，因為它很難知道什么時候在哪里去觀察。在這個案例中，授權用戶訪問了合法的應用系統（籃球錦標賽的語音轉播），因此造成了嚴重的網絡衰落。要想找到這些影響其他重要應用系統的用戶和應用系統幾乎是不可能的。現在，讓我們看看同樣的情況下，有了VisualUpTime®SelectTM產品，要想找到他們，要想進行前攝性治理可以是多么輕易。

    安全漏洞案例

    即使有了最強大的防火墻或入侵偵測攻擊，企業也很輕易會在安全漏洞出現時受到攻擊，無論是病毒、蠕蟲還是服務中斷的攻擊。防止攻擊是第一線的防御，但是，假如出現了安全漏洞，發現和清除受到影響/感染的用戶所需要的時間對降低風險就顯得非常重要。讓我們看看VisualUpTime®SelectTM產品是如何能夠幫助提前發現潛在的問題，并首先將注重力集中于受影響的用戶身上的。

    圖10:當ICMP應用超過定制門檻時，用戶被找出來。

    正如前面討論的那樣，這個案例中說明了一個服務中斷攻擊是如何在一段時間內增長的，是如何在高速WAN網絡被過度應用,而且更多用戶可能會受到影響。有了VisualUpTime®SelectTM產品，用戶可以設置按端口或按應用系統設置使用門限，以便在問題發展到不可收拾之前就找出潛在的問題。比如，ICMP是一個可能被用來傳播一個攻擊（或許它并不具有威脅性）的協議。有了ICMP應用的門檻設置，網管員就可以得到一個警報，以便其可以向下挖掘來確定原因（見圖10）。

    有了對ICMP應用堵塞的通知，用戶可以挖掘出個別應用系統流來確定原因。IT治理人員可以迅速看到這是否是一個正常的ICMP應用。不過，每個使用ICMP的用戶都會走向同一個服務器，看起來疑似一個安全漏洞。只需點擊幾下鼠標，就能判定是否是一次服務中斷攻擊了。（見圖11）。

    圖11：挖掘個別應用系統流以看到客戶與服務器之間的關系。

    有了VisualUpTime®SelectTM產品，企業可以更為迅速地偵測到病毒傳播的模式。IT經理們不需要等待到網絡被完全占用，那樣會影響更多的用戶。另外，IT員工還可以挖掘出客戶和服務器之間的關系，并很輕易地看到最終用戶是否已經被影響，并開始為那些確定已經受到影響的用戶執行清除工作。由于更為前攝性而迅速地隔離受到影響的最終用戶，VisualUpTime®SelectTM產品降低了企業暴露于安全漏洞之下的風險。

    結論

    一直以來，企業依靠重要的應用系統的性能。因此，IT經理們要求高效、靈活的工具，以提供有關整個基礎設施的最高程度的可視性。把網絡當成鐵板一塊來治理已經讓人不能忍受。網管員們必須考慮網絡如何影響應用系統和用戶。IT經理們則必須通過營造一個文化，并且在應用系統和網絡之間建立組織性結構來彌合集成性鴻溝。

    VisualUpTime®SelectTM產品集成性了應用系統性能分析和網絡性能分析功能－所以IT部門可以采取一個全面的方法來進行集成性網絡應用系統。Visual網絡公司的目標是使IT部門可以以業務的形式，基于重要的應用系統來保障高性能。

    通過使用VisualUpTime®SelectTM產品彌合集成性鴻溝，IT經理們可以改善集成性網絡應用系統，并且:

    □通過用對應用系統和網絡域的具體了解改善業務性能，提高應用系統可用性。

    □通過開發更有效的應用系統選擇解決方案來降低運營成本，不再總是增加帶寬。

    □通過訪問整個基礎結構的性能數據來發現未授權的應用系統、帶寬攫取、擁塞區域和趨勢以及跟蹤病毒，前攝性地控制潛在問題。

    □通過在預算內分配正確數量的帶寬來維持應用系統性能來優化帶寬。

    關于Visual網絡公司

    Visual網絡公司（Nasdaq:VNWK）是網絡和應用系統性能治理解決方案的領先供給商。該公司的技術可以使企業可靠、安全地治理重要應用系統在其基礎結構上的交付。Visual網絡公司的產品可以提高應用系統和網絡的可用性，優化帶寬使用，降低傳統的和基于IP的基礎設施的運營成本。

    美國福祿克網絡公司已于2006年2月成功收購Visual網絡公司，該公司旗下強大的IP語音（VoIP）生命周期治理方案和應用性能監測方案，將并入福祿克網絡公司中。

    欲了解更多信息，請訪問以下網站：http://www.visualnetworks.com.

    參考資料

    1“最大化你的WAN，帶寬趨勢和基準點”，Nemertes研究院，2004年2月。

    2網絡世界應用系統性能研究，2003年6月。