微信公眾號也要實(shí)現(xiàn)監(jiān)控的框架
- 編輯：admin -你有多少次在事后分析會議上發(fā)現(xiàn)，其實(shí)你的監(jiān)控系統(tǒng)早就標(biāo)識出了潛在的可擴(kuò)展性和可用性問題發(fā)生的跡象?也許監(jiān)控系統(tǒng)觸發(fā)了數(shù)據(jù)庫上的空間報(bào)警，但沒有得到響應(yīng)，也許是幾個服務(wù)的CPU使用率都超出閾值了。也許你啟用了監(jiān)控系統(tǒng)中對響應(yīng)時間的監(jiān)控功能，而且在過去幾個月中可以看到調(diào)用某個特定服務(wù)的時間在緩慢增加。你也許會問自己，“怎么這些居然都沒有得到注意”?
你有多少次在事后分析會議上發(fā)現(xiàn)，其實(shí)你的監(jiān)控系統(tǒng)早就標(biāo)識出了潛在的可擴(kuò)展性和可用性問題發(fā)生的跡象?也許監(jiān)控系統(tǒng)觸發(fā)了數(shù)據(jù)庫上的空間報(bào)警，但沒有得到響應(yīng)，也許是幾個服務(wù)的CPU使用率都超出閾值了。也許你啟用了監(jiān)控系統(tǒng)中對響應(yīng)時間的監(jiān)控功能，而且在過去幾個月中可以看到調(diào)用某個特定服務(wù)的時間在緩慢增加。你也許會問自己，“怎么這些居然都沒有得到注意”?也許你甚至把自己的擔(dān)心告訴了你的團(tuán)隊(duì)，但得到的答案可能是監(jiān)控系統(tǒng)給出的錯誤信息太多，或者系統(tǒng)中的噪音太多了。也許運(yùn)營團(tuán)隊(duì)的主管還可能會說，他已經(jīng)申請幾個月了，希望有資金來替換當(dāng)前的監(jiān)控系統(tǒng)，或者希望有時間和靈活度來重新實(shí)現(xiàn)當(dāng)前的系統(tǒng)。他可能會說，“如果我們能夠剔除-些噪音，那么我的團(tuán)隊(duì)會睡得好些，并且能夠解決我們面對的真正問題”。我們已經(jīng)聽到過無數(shù)要求新的更好的監(jiān)控系統(tǒng)的理由，雖然有時它們是正當(dāng)?shù)?，但我們相信通常它們的結(jié)果還是損害了股東價值。真正的問題通常不是監(jiān)控系統(tǒng)不能滿足公司的需求，而在于監(jiān)控的方法是錯誤的。運(yùn)營團(tuán)隊(duì)可能證實(shí)了對監(jiān)控的需求，但往往搞錯了方向。
雖然要解決“為什么我們沒能及早發(fā)現(xiàn)它”這個問題，必須采用設(shè)計(jì)為能夠監(jiān)控的這條架構(gòu)設(shè)計(jì)原則，但它并不足以解決我們所有的監(jiān)控問題或者所有的監(jiān)控需求。我們需要規(guī)劃我們的監(jiān)控方案，并且還會隨著時間的推移而改善它。敏捷軟件開發(fā)方法在開發(fā)一段軟件之前， 是不知道所有需求的。要解決這個問題，就要具有敏捷和漸進(jìn)的開發(fā)理念，這一點(diǎn)同樣適用于我們的監(jiān)控平臺和系統(tǒng)。我們提出的這種漸進(jìn)的方法可以回答三個問題，列出的故障和問題的描述。
在我們提出的監(jiān)控方案的漸進(jìn)模型中，我們要問的第一個問題是“有問題嗎”。具體說來，我們感興趣的是確定系統(tǒng)是否行為不正確，通常我們真正要問的是這里是否有客戶會經(jīng)歷或者將要經(jīng)歷的問題。根據(jù)我們的經(jīng)驗(yàn)，許多公司都會完全繞過這個非常重要的問題，迫不及待地投入到對下一個問題的毫無指導(dǎo)的探索中，即“哪里有問題”，或者更糟的，“什么問題”。
在監(jiān)控過程中，繞過“有問題嗎”或者更恰當(dāng)?shù)?ldquo;客戶在經(jīng)歷的是什么問題”，都假設(shè)了你知道什么系統(tǒng)會以什么方式引發(fā)什么問題。但遺憾的是，實(shí)際并非總是如此。事實(shí)上，我們有許多客戶都浪費(fèi)了大量的人力來查找問題的根源，卻不曾真正理解問題究竟是什么。你一定曾上過這樣的課程，它們只是把分析問題或者解決問題的方法-股腦地星現(xiàn)出來。但關(guān)鍵在于，在你確 切理解了要解決的是什么問題之前，不要試圖開始解決問題或者進(jìn)行任何分析。這一點(diǎn)同樣適用于舉行會議一通常 會議都需要有一個議題和目標(biāo)，或產(chǎn)品營銷一在嘗試為某 個市場需求開發(fā)效地判斷出問題的原因，我們必須知道這里存在一一個問題以及問題表現(xiàn)為什么樣子。產(chǎn)品或服務(wù)之前，我們首先要確認(rèn)目標(biāo)人群。這一一點(diǎn)對監(jiān)控系統(tǒng)和應(yīng)用也是如此一如果 要想有
如果構(gòu)建的系統(tǒng)不能回答第.個問題 “有問題嗎”，這就會導(dǎo)致兩個新的問題。第一個問題是，我們的團(tuán)隊(duì)總是在追蹤假警報(bào)，然后就會過早地把總是出現(xiàn)的警報(bào)作為噪音處理掉。這樣久而久之，對于那些看來不是大問題的警報(bào)，我們就會停止調(diào)查，這就使得我們的系統(tǒng)不那么有用了。最終，我們會習(xí)慣性地忽略-些警報(bào)，無論它們重要與否。
這種習(xí)慣性忽略警報(bào)會引發(fā)第二個問題，也是更加惡劣的問題，即由客戶通知我們發(fā)生問題了?？蛻粢欢ú幌Ｍ约菏悄莻€告訴你你的系統(tǒng)或產(chǎn)品有問題的人，尤其當(dāng)你是像應(yīng)用服務(wù)提供商(ASP)或軟件即服務(wù)(SaaS) 提供商這樣的托管方案提供者時?？蛻羝谕氖?，他們告訴你的東西，你都已經(jīng)知道了，并且你正在修復(fù)他們所經(jīng)歷的問題。但遺憾的是，由于我們沒有花費(fèi)時間來構(gòu)建一個告訴我們這里有問題的系統(tǒng)，所有通常怒不可遏的客戶是我們得到我們有問題的第一指示。能夠回答第一個問題“有問題嗎”的系統(tǒng)，通常是關(guān)注客戶的系統(tǒng)，它們會像客戶那樣與我們的平臺進(jìn)行交互。它們還可以是內(nèi)置在我們平臺上的診斷服務(wù)，與前面提到的統(tǒng)計(jì)過程控制示例相似。
在漸進(jìn)模式中，要回答的下一個問題是“哪里有問題”?，F(xiàn)在我們已經(jīng)構(gòu)建了一個系統(tǒng)，能夠確切地告訴我們，在我們的系統(tǒng)中出現(xiàn)了問題，在理想狀況下，還能告訴我們這個問題與哪個或哪些業(yè)務(wù)指標(biāo)相關(guān)。現(xiàn)在我們需要做的是隔離問題。這種類型的系統(tǒng)通常廣泛收集各種類型的信息，能夠給我們提供一段時間內(nèi)資源的使用情況。在理想狀況下，它們是圖形化的，甚至還可能利用了我們前面提到的統(tǒng)計(jì)過程控制圖。也許它們還能提供個友好的用戶 界面，給我們一一副熱圖，說明我們的系統(tǒng)中有哪些區(qū)域或部分的行為與我們的預(yù)期不符。這種類型的系統(tǒng)能夠真正幫助我們迅速找出應(yīng)該把力氣花在哪里來隔離問題，或者造成故障的根本原因是什么。
在繼續(xù)我們的介紹之前，我們要暫停一下， 說明如果一個系統(tǒng)繞過了“有問題嗎”這個問題而直接問“哪里有問題”，會發(fā)生什么情況。如前所述，這種狀況太常見了。也許你有一個運(yùn)營中心，其中有無數(shù)的顯示器、刻度表和圖表，甚至你還可能實(shí)現(xiàn)了我們前面提到的熱圖系統(tǒng)。如果沒有首先知道這里發(fā)生了一個客戶問題，那么你的團(tuán)隊(duì)可能就會執(zhí)行一個日常的完整檢查流程，查看每個在某一時間段稍微 呈現(xiàn)紅色的子系統(tǒng)。也許只需幾分鐘就能確認(rèn)這只不過是個異常的硬盤使用事件，于是運(yùn)營團(tuán)隊(duì)可能會放松使這個子系統(tǒng)變紅的運(yùn)營定義的閾值。當(dāng)客戶支持中心總是收到用戶不能登錄系統(tǒng)的電話時，他們首先會假設(shè)這只是屬于日常的登錄失敗，但在連續(xù)10分鐘都接到這樣的電話后，客戶支持中心就會聯(lián)系運(yùn)營中心，讓他們關(guān)注這個問題了。
事實(shí)上，在我們處理硬盤使用報(bào)告時，在熱圖系統(tǒng)中，CPU的使用情況和登錄服務(wù)的用戶連接都變紅了?，F(xiàn)在，與客戶有關(guān)的事件幾乎已經(jīng)發(fā)生15分鐘了，而我們還沒開始診斷操作。如果我們的監(jiān)控系統(tǒng)能夠報(bào)告與客戶交易相關(guān)的問題，那么我們就能在解決其他不直接影響客戶體驗(yàn)的問題之前，先解決登錄失敗的故障。在這個例子中，一個能夠顯示出某種類型的交易隨著時間而減少的監(jiān)控方案會告訴我們可能發(fā)生了問題(登錄失敗)，那么運(yùn)營團(tuán)隊(duì)就會查看系統(tǒng)中的監(jiān)控警報(bào)，從而找出發(fā)生問題的地方，如登錄服務(wù)的CPU使用警報(bào)。
在我們的漸進(jìn)監(jiān)控模型中，最后一個要回答的問題是“什么問題”。注意，我們已經(jīng)從確認(rèn)這里有一個故障，前進(jìn)到了隔離發(fā)生故障的區(qū)域，現(xiàn)在要進(jìn)人識別問題的階段了，即我們要迅速找出引發(fā)系統(tǒng)中問題的根本原因。從我們確認(rèn)有事情發(fā)生了，到確定引發(fā)故障的根本原因，中間會發(fā)生兩件事情。一件事情是， 當(dāng)我們從第-一個問題深人到第三個問題的過程中，我們需要收集的數(shù)據(jù)量增長了。要確認(rèn)是否有事情或者有地方出問題了，我們只需少量的數(shù)據(jù)即可。但要從我們可能遇到的各種問題中找出“什么問題”的答案，我們就需要收集大量時間段內(nèi)的所有數(shù)據(jù)。另一一件事情是，我們會自然地把我們關(guān)注的范圍從“有事情發(fā)生了”縮小到“我已經(jīng)發(fā)現(xiàn)發(fā)生了什么”。這兩件事情的規(guī)模會互相影響要想使這個問題的答案越具體，我們確定這個答案需要收集的數(shù)據(jù)就越多。
要想能夠確切地回答所有問題，我們需要很多數(shù)據(jù)。問題本身，可能只需非常少部分的數(shù)據(jù)就能回答，但為了得到這個答案，我們必須收集所有可能發(fā)生的問題的數(shù)據(jù)。你發(fā)現(xiàn)這會造成的問題了嗎?如果我們沒有一個足夠智能的系統(tǒng)可以確定是否有問題，那么我們就要為提示潛在問題的數(shù)條警報(bào)信息都分配人手，漸漸地，組織就會忽略這些警報(bào)。較好的方法是構(gòu)建一個系統(tǒng)，對有影響的事件或即將發(fā)生的事件發(fā)出警報(bào)，然后以此作為觸發(fā)器，指導(dǎo)我們找出根本原因。“什么問題”通常是比“哪里有問題”更深一層的問題。這里甚至可以更加細(xì)致地使用統(tǒng)計(jì)過程控制來幫助我們找出根本原因。假設(shè)我們有足夠的空間和資源，那么也許我們可以繪制一段時間內(nèi)我們應(yīng)用的每個功能的運(yùn)行曲線。我們可以拿最近24小時的數(shù)據(jù)與上-一周的數(shù)據(jù)進(jìn)行對比，也可以拿上一周的數(shù)據(jù)與上個月的數(shù)據(jù)進(jìn)行對比。我們可以不必保留每個調(diào)用的所有交易記錄，而只需匯總段時間內(nèi)的交易數(shù)據(jù)，以便進(jìn)行對比即可。我們可以按照錯誤類型對比一天之中某個時間或者周之中某一 天的每個服務(wù)的錯誤率。這里，我們看的是構(gòu)成服務(wù)的函數(shù)、 方法和對象，而不是服務(wù)本身的操作。如前所述，這需要很多數(shù)據(jù)，但對于我們所遇到的幾乎任何問題，由此我們都能確切地回答出問題是什么。
通常，我們可以把這三個問題簡單地劃分為三種監(jiān)控類型或者監(jiān)控方法。監(jiān)控少量的用戶體驗(yàn)或?qū)崟r業(yè)務(wù)指標(biāo)，通常就可以回答“有問題嗎”。利用系統(tǒng)級的監(jiān)控指標(biāo)通常就可以回答“哪里有問題”。而利用我們專有的系統(tǒng)記錄和收集數(shù)據(jù)就可以解決“什么問題”。
上述方法是種系統(tǒng)化的方法，因?yàn)樗偈刮覀冊趪L試微信網(wǎng)站制作監(jiān)控平臺或產(chǎn)品中的一切之前，先構(gòu)建一.此系統(tǒng)來識別問題。我們并不是說在回答了“有問題嗎”這個問題之前，絕對不能做任何與回答“哪里有問題”和“什么問題”有關(guān)的工作，而是說要把我們的主要精力首先集中在回答第-個問題上。由于“哪里有問題”在許多平臺上都很容易實(shí)現(xiàn)，所以把你的初始工作的20%投人到這個問題上就能得到很大的回報(bào)，而至少要把50%的工作都用來確保你知道并且能夠回答“有問題嗎”這個問題。通常“什么問題”這個比較難回答，你需要認(rèn)真思考你的專有系統(tǒng)的設(shè)計(jì)和部署。