修復(fù)問(wèn)題的第一步是認(rèn)識(shí)到自己遇到了問(wèn)題。
有時(shí)候，一個(gè)新IT技術(shù)出現(xiàn)會(huì)需要一些特殊的工具;但是，有時(shí)候是因?yàn)槲覀冮L(zhǎng)期依賴的重要工具無(wú)法滿足我們的要求。隨著我們?cè)絹?lái)越多地將業(yè)務(wù)遷移到云、軟件即服務(wù)(SaaS)和混合IT環(huán)境上，一些像traceroute等重要的工具已經(jīng)不能用了。在一個(gè)越來(lái)越不透明的環(huán)境中，管理權(quán)限變得越來(lái)越小，管理員應(yīng)該如何開始修復(fù)網(wǎng)絡(luò)問(wèn)題呢?
奔向不透明環(huán)境
云與SaaS最吸引人的一個(gè)特點(diǎn)是它從一開始就出自工程師之手，但是卻深深地刺激著IT管理人員：“因?yàn)椴恍枰芾?rdquo;。將一些關(guān)鍵服務(wù)遷移到一個(gè)帶有服務(wù)水平協(xié)議(SLA)的方法本身并沒(méi)有問(wèn)題，因?yàn)槲覀冃湃蜸LA。提供商的承諾是很好的，他們通常都會(huì)盡一切努力去服務(wù)他們的用戶。
然而，問(wèn)題在于，網(wǎng)絡(luò)工程師仍然必須負(fù)責(zé)保證良好的用戶體驗(yàn)。他們同意推翻多年積累的豐富的監(jiān)控技術(shù)，而這種轉(zhuǎn)變是必然的。IT愿意將決定業(yè)務(wù)成功的系統(tǒng)遷移到一個(gè)新環(huán)境上，即使他們無(wú)法像以前那樣修復(fù)故障，也很難跟蹤和報(bào)告整體性能。大家可能都知道，雖然亞馬遜、谷歌、Salesforce和Azure已經(jīng)很好，而且正變得越來(lái)越好，但是它們肯定不是完全沒(méi)有故障的，也不是無(wú)上限的基礎(chǔ)架構(gòu)。它們?nèi)匀环蠑?shù)據(jù)中心既定的物理原理，它們的服務(wù)臺(tái)仍然會(huì)不斷地收到問(wèn)題單。
API取代SNMP
有很多很好的理由決定了云提供商不會(huì)開放防火墻或允許用戶監(jiān)控他們的軟件定義基礎(chǔ)架構(gòu)。相反，我們被迫依靠他們所提供的管理API和私有工具，用它們來(lái)檢查和分析所遇到的網(wǎng)絡(luò)問(wèn)題。但是，這些接口所提供的信息完全無(wú)法和我們?cè)谧约簲?shù)據(jù)中心內(nèi)所積累的信息相比;它們有一定的使用難度，而且沒(méi)有跨平臺(tái)和廣泛支持ICMP、SNMP及其他協(xié)議。但是，他們能做的就是給應(yīng)用程序流量開放一些特殊的訪問(wèn)路徑。
即使在我們的內(nèi)部網(wǎng)絡(luò)，traceroute和ping也會(huì)受到路由多樣性的影響，從而限制它們修復(fù)用戶與服務(wù)器之間網(wǎng)絡(luò)問(wèn)題的能力。traceroute假定觀察者與服務(wù)之間的路徑是線性的，因此會(huì)返回該測(cè)試的近似路由路徑。在混合IT網(wǎng)絡(luò)中，互聯(lián)網(wǎng)路由的互連多宿主會(huì)成倍地放大這個(gè)問(wèn)題，而且會(huì)在UDP或ICMP流量上進(jìn)一步增加難度。那么問(wèn)題來(lái)了，在4條各自分擔(dān)25%應(yīng)用流量的鏈接中出現(xiàn)了延遲，我們?cè)撊绾螐闹蟹直娉鲇绊慡alesforce性能的根源問(wèn)題呢?
答案是要忘掉我們?cè)?jīng)精心設(shè)計(jì)的內(nèi)部網(wǎng)絡(luò)，而要認(rèn)真思考互聯(lián)網(wǎng)。在內(nèi)部網(wǎng)絡(luò)中，我們?cè)谠O(shè)計(jì)時(shí)盡量考慮了各種不確定性;而互聯(lián)網(wǎng)則依靠限制路由不確定性來(lái)保證健壯性。如果不去考慮和想象應(yīng)用程序特有的數(shù)據(jù)包，那么從用戶到云服務(wù)器的全部流量路徑可以在多個(gè)維度上觀察到多個(gè)可能出現(xiàn)的路由，其中包括時(shí)間維度。這種方法不會(huì)馬上產(chǎn)生像traceroute一樣的效果——它需要一定時(shí)間去檢測(cè)和傳播，但是它的結(jié)果會(huì)很全面且可視化。
雖然在本地設(shè)備上執(zhí)行基于請(qǐng)求的監(jiān)控會(huì)繼續(xù)給運(yùn)營(yíng)人員返回重要信息，但是可視化路徑監(jiān)控能夠幫助我們重新獲得因?yàn)榛旌螴T網(wǎng)絡(luò)而丟失的監(jiān)控能力。它不僅能夠幫助我們簡(jiǎn)化內(nèi)部網(wǎng)絡(luò)問(wèn)題中誤操作和錯(cuò)誤配置的檢測(cè)，還能夠?qū)⒕W(wǎng)絡(luò)問(wèn)題的修復(fù)通過(guò)互聯(lián)網(wǎng)擴(kuò)展到服務(wù)提供商的網(wǎng)絡(luò)上。
這種方法之所以有效，是因?yàn)楝F(xiàn)代網(wǎng)絡(luò)路徑監(jiān)控工具能夠模擬應(yīng)用程序特有的流量，它們會(huì)像用戶流量一樣通過(guò)防火墻。在出現(xiàn)不對(duì)稱的多宿主鏈路延遲問(wèn)題時(shí)，它們能夠通過(guò)負(fù)載均衡解決特定協(xié)議或端口的路由問(wèn)題，而且它們會(huì)發(fā)現(xiàn)所有影響服務(wù)性能的節(jié)點(diǎn)。我們不再需要依靠路由器CPU的警報(bào)，而只需要處理網(wǎng)絡(luò)節(jié)點(diǎn)的警報(bào)，將警報(bào)信息告知提供商服務(wù)臺(tái)，他們就能得到解決問(wèn)題所需要的信息，大大縮短了他們分析問(wèn)題的時(shí)間。
如果我們能夠重新獲得混合IT環(huán)境下的可見(jiàn)性，并且還能讓用戶開心，那么在修復(fù)網(wǎng)絡(luò)問(wèn)題方面，“不需要管理”可能就不是一件壞事了。
