修復問題的第一步是認識到自己遇到了問題。
有時候，一個新IT技術出現會需要一些特殊的工具;但是，有時候是因為我們長期依賴的重要工具無法滿足我們的要求。隨著我們越來越多地將業務遷移到云、軟件即服務(SaaS)和混合IT環境上，一些像traceroute等重要的工具已經不能用了。在一個越來越不透明的環境中，管理權限變得越來越小，管理員應該如何開始修復網絡問題呢?
奔向不透明環境
云與SaaS最吸引人的一個特點是它從一開始就出自工程師之手，但是卻深深地刺激著IT管理人員：“因為不需要管理”。將一些關鍵服務遷移到一個帶有服務水平協議（SLA）的方法本身并沒有問題，因為我們信任SLA。提供商的承諾是很好的，他們通常都會盡一切努力去服務他們的用戶。
然而，問題在于，網絡工程師仍然必須負責保證良好的用戶體驗。他們同意推翻多年積累的豐富的監控技術，而這種轉變是必然的。IT愿意將決定業務成功的系統遷移到一個新環境上，即使他們無法像以前那樣修復故障，也很難跟蹤和報告整體性能。大家可能都知道，雖然亞馬遜、谷歌、Salesforce和Azure已經很好，而且正變得越來越好，但是它們肯定不是完全沒有故障的，也不是無上限的基礎架構。它們仍然符合數據中心既定的物理原理，它們的服務臺仍然會不斷地收到問題單。
API取代SNMP有很多很好的理由決定了云提供商不會開放防火墻或允許用戶監控他們的軟件定義基礎架構。相反，我們被迫依靠他們所提供的管理API和私有工具，用它們來檢查和分析所遇到的網絡問題。但是，這些接口所提供的信息完全無法和我們在自己數據中心內所積累的信息相比；它們有一定的使用難度，而且沒有跨平臺和廣泛支持ICMP、SNMP及其他協議。但是，他們能做的就是給應用程序流量開放一些特殊的訪問路徑。
即使在我們的內部網絡，traceroute和ping也會受到路由多樣性的影響，從而限制它們修復用戶與服務器之間網絡問題的能力。traceroute假定觀察者與服務之間的路徑是線性的，因此會返回該測試的近似路由路徑。在混合IT網絡中，互聯網路由的互連多宿主會成倍地放大這個問題，而且會在UDP或ICMP流量上進一步增加難度。那么問題來了，在4條各自分擔25%應用流量的鏈接中出現了延遲，我們該如何從中分辨出影響Salesforce性能的根源問題呢？
答案是要忘掉我們曾經精心設計的內部網絡，而要認真思考互聯網。在內部網絡中，我們在設計時盡量考慮了各種不確定性；而互聯網則依靠限制路由不確定性來保證健壯性。如果不去考慮和想象應用程序特有的數據包，那么從用戶到云服務器的全部流量路徑可以在多個維度上觀察到多個可能出現的路由，其中包括時間維度。這種方法不會馬上產生像traceroute一樣的效果——它需要一定時間去檢測和傳播，但是它的結果會很全面且可視化。
雖然在本地設備上執行基于請求的監控會繼續給運營人員返回重要信息，但是可視化路徑監控能夠幫助我們重新獲得因為混合IT網絡而丟失的監控能力。它不僅能夠幫助我們簡化內部網絡問題中誤操作和錯誤配置的檢測，還能夠將網絡問題的修復通過互聯網擴展到服務提供商的網絡上。
這種方法之所以有效，是因為現代網絡路徑監控工具能夠模擬應用程序特有的流量，它們會像用戶流量一樣通過防火墻。在出現不對稱的多宿主鏈路延遲問題時，它們能夠通過負載均衡解決特定協議或端口的路由問題，而且它們會發現所有影響服務性能的節點。我們不再需要依靠路由器CPU的警報，而只需要處理網絡節點的警報，將警報信息告知提供商服務臺，他們就能得到解決問題所需要的信息，大大縮短了他們分析問題的時間。
如果我們能夠重新獲得混合IT環境下的可見性，并且還能讓用戶開心，那么在修復網絡問題方面，“不需要管理”可能就不是一件壞事了。
京公網安備 11010502049343號