?

?

你在演講中曾提及AWS CloudWatch會有5分鐘的時延。

Kevin: 誠然，AWS為監(jiān)控提供了很多基礎(chǔ)技術(shù)。CloudWatch十分出眾，它提供了一些基本的警告和通知，并幫你監(jiān)測一些基礎(chǔ)屬性，像CPU和網(wǎng)絡(luò)流入/流出。CPU是我很關(guān)注的一點。

CloudWatch的問題在于, 借助Amazon提供的基礎(chǔ)監(jiān)控技術(shù)，你無從獲取應(yīng)用相關(guān)的更深入細(xì)節(jié)。它只能讓你查看諸如服務(wù)器狀態(tài)、網(wǎng)絡(luò)流入/流出等基礎(chǔ)屬性。

這是一個好的開端，但實用價值不大。試問，CPU0%代表什么？一切運(yùn)轉(zhuǎn)正常，還是應(yīng)用服務(wù)器崩潰？可能為較好情況，也可能是最壞結(jié)果，而你，對實際情形一無所知。

CloudWatch本身存在不足。試著對其中的部分加以完善，你確實很想監(jiān)測特定服務(wù)及其運(yùn)轉(zhuǎn)性能，對么？Yammer Metrics是我力薦的一種工具。它可以為你提供定時器，表和直方圖，更重要的是，它能讓你注釋代碼，讓你監(jiān)測任何API的運(yùn)轉(zhuǎn)性能及調(diào)用頻率（每分或 每秒的調(diào)用次數(shù)），這些信息唾手可得。

這在一定程度上邁出了提供服務(wù)相關(guān)信息的第一步。但問題在于，你真正想了解的是運(yùn)行趨勢。知道服務(wù)運(yùn)行了400毫秒意義并不大。昨天是僅僅用了20毫秒，還是800毫秒？是服務(wù)已步入困境，還是性能有了飛躍？誠然，你無從知曉。

因此，我在just.me借助Graphite獲得所有執(zhí)行信息相關(guān)的圖表，并與昨天、上月的情況進(jìn)行比對，進(jìn)而分析其運(yùn)行趨勢。這樣，在軟件版本 大更新時，我就能從商業(yè)運(yùn)作和系統(tǒng)運(yùn)維兩個維度出發(fā)，分析更新是否會影響性能和訪問人數(shù)。Graphite帶有一項十分便捷的設(shè)置服務(wù)，用于幫你迅速上手 并熟悉Graphite。我們對這項服務(wù)非常滿意。

其后的挑戰(zhàn)在于監(jiān)測各服務(wù)性能，并在故障發(fā)生時推送電子郵件或SMS以示提醒、通知。我用一款名為Nagios的工具，它非常出眾，你可以通過對配置文件的簡單修改來定義什么情況下你愿意得到“嘿，問題將至”的警告，什么情況下真正遇到了問題。

挑戰(zhàn)的關(guān)鍵在于，你想在問題發(fā)生前未卜先知。先知往往會讓分析變得簡單。但毫無疑問，對顧客而言，故障永不發(fā)生更值得期待。

關(guān)于just.me的預(yù)測分析和全面監(jiān)測，我所做的最后一件事是，Graphite向你提供了每次監(jiān)測一項服務(wù)的一系列工具。也許你能一次觀測五個服務(wù)，或是一次觀測所有服務(wù)，但我更希望看到行為和趨勢展望。

Square團(tuán)隊開發(fā)了開源軟件Cubism。它能在屏幕上實時顯示大量數(shù)據(jù)并推斷出運(yùn)行性能。它最吸引我的地方在于，很多情況下單個服務(wù)帶來的問 題會蔓延至整個應(yīng)用?？赡苣銜仁盏侥稠椃?wù)持續(xù)10分鐘低效運(yùn)轉(zhuǎn)的警告，再一段時間后，整個系統(tǒng)非正常運(yùn)轉(zhuǎn)。警告能幫你剝離出問題根源，關(guān)注最初發(fā)現(xiàn)問 題的服務(wù)并在某種程度上引導(dǎo)你更快地接近問題根源。而盡快找到根源才能盡快恢復(fù)運(yùn)轉(zhuǎn)。

?

在那么多的監(jiān)測量度中，你如何選定適合你的量度？

Kevin: 的確有很多重要量度值得關(guān)注。你想監(jiān)測CPU，若要同時關(guān)注成千上萬事件，可以考慮創(chuàng)建儀表盤，有了它，各類狀態(tài)一目了然。有CPU運(yùn)轉(zhuǎn)狀態(tài)，也有實例運(yùn)行情況。

監(jiān)控中最難實現(xiàn)卻又必須完成的功能是主動請求。獲取哪些API發(fā)起主動請求和請求的確切數(shù)目的相關(guān)信息是最具挑戰(zhàn)性也最具價值的事之一。若是訪問量 很大，當(dāng)某項服務(wù)開始出現(xiàn)問題時，完成相關(guān)任務(wù)會更耗時，從而帶來主動請求數(shù)量的上升。總體看，這非常非常有趣，特別是使用Java時，線程池大小固定且 每項服務(wù)獨占線程，一次API調(diào)用掛起就能引起整個服務(wù)崩潰。避免單個線程帶來的服務(wù)崩潰十分重要。

很多服務(wù)并不關(guān)注性能。其中，主要區(qū)別在于信息取送時機(jī)。當(dāng)你向服務(wù)器傳送信息時，幾乎可以肯定，后臺進(jìn)程是異步的。如果用戶對究竟發(fā)生了什么一無所知，那么勢必?zé)o從得知服務(wù)時耗。獲取信息或是下載時，用戶等待幾乎是必然。下行量度中，用戶性能體驗更重要。

上傳，發(fā)布信息，就商業(yè)角度而言更重要。我們監(jiān)測各類社交行為，他們何時發(fā)布信息，發(fā)布多少信息，贊、評論和其他行為，關(guān)注人群。我們對這些事件的數(shù)目感興趣，而商家并不關(guān)心用戶刷過多少次屏。這就像一種博弈。你要了解獲取時性能，而商家更關(guān)注提交。

Cubism很有用。決定哪些量度應(yīng)一目了然時，它會是一個好的選擇。通過展示頂部緊緊相靠的三色標(biāo)注，Cubism在最小空間內(nèi)讓一切一目了然。我能以此在屏幕上監(jiān)測盡可能多的量度并使之在更遠(yuǎn)處可見。

這更多是從操控角度而非商業(yè)角度。從商業(yè)的角度講，你只需緊盯著你想要達(dá)成的核心目標(biāo)就好。

我的儀表盤比起登錄時約有30%的變動。我們將那些以往認(rèn)為會發(fā)生問題但實際并未發(fā)生的量度移除。而另一些預(yù)料之外的量度被排放在辦公儀表盤顯眼的位置。

?

儀表盤保留了哪些量度?

Kevin: 我會關(guān)注CPU。CPU信息與監(jiān)控密切相關(guān)，我把所有MySQL CPU，EC2 服務(wù)器CPU，Lucene CPU以及Neo4j CPU放在一起。它們都顯示一個0到100間的數(shù)值，超過75%到80%時，會發(fā)生災(zāi)難。當(dāng)我一眼看去，發(fā)現(xiàn)沒有超過50%的，就會很放心。我并不關(guān)心每 個CPU的具體數(shù)值，這種壓縮可以使屏幕容納更多信息。

我關(guān)注負(fù)載均衡器，確定順利運(yùn)轉(zhuǎn)的實例數(shù)量不為0。我也關(guān)注主動請求并確定沒有出現(xiàn)API峰值。

我關(guān)注DynamoDB，對于它，我想談兩點，我并不喜歡為DynamoDB讀單元設(shè)定的收費方式。在我看，這種方式是非云的。它不會自動調(diào)整。基 本上，你說，“我愿為100讀單元支付”。一旦這100讀單元用掉了，系統(tǒng)就開始拒絕返回結(jié)果，拋出異常。即便只需要10個，你也要為100單元支付。若 是有一個白天活躍但夜晚清靜的網(wǎng)站，你會面對不間斷的重新配置。我常會惴惴不安于是否有任何一個服務(wù)達(dá)到了讀單元的閾值，屆時它將停止顯示數(shù)據(jù)，而你將陷 入大麻煩。這真的非常糟糕。

他們?yōu)镈ynamo配置了CloudWatch，但使用不便。在just.me我們有很多很多量度，要立即打開瀏覽器監(jiān)測CloudWatch的所 有數(shù)據(jù)幾乎不現(xiàn)實。這也是為什么我要在Graphite的基礎(chǔ)上構(gòu)建自己的工具來集成信息——那些需要上百瀏覽器方能顯示的信息，我像對待CPU一樣把他 們整合在一張表中。監(jiān)測讀寫單元時，我會劃定一條基線作為閾值，超出閾值的就是有問題的。

儀表盤中還有什么？我曾排放過很多安全層相關(guān)的東西。每次請求都需要通過JAAS安全機(jī)制并確認(rèn)是否授權(quán)，而早期的授權(quán)機(jī)制有過一些問題，那些曾被 排放在儀表盤的頂部、前部還有中心，若通過安全驗證耗費了10s，那其余部分的網(wǎng)站性能將不再重要，你必須先修正這一部分，不過現(xiàn)在這些都已解決。那些量 度已經(jīng)過時，并從儀表盤中銷聲匿跡。

我還把公開的工單數(shù)目加入報告中，如果被公開的工單數(shù)目很大，也許意味著你在這方面的監(jiān)控是有漏洞的，所以我在儀表盤中安排了監(jiān)測公開的工單數(shù)目的地方。

為了激發(fā)職員的士氣，我也放入了一些市場量度。我能監(jiān)測到系統(tǒng)新注冊了多少設(shè)備以及這些設(shè)備發(fā)送了多少消息又收到了多少回復(fù)。這些信息主要是出于激 勵團(tuán)隊的目的。我希望儀表盤能吸引他們的目光，讓他們對此好奇進(jìn)而注意到更多其他方面。我們將儀表盤安置在辦公室，放在一塊很大的屏幕上，所有開發(fā)者都能 看到。休息時，人們站在監(jiān)視器下方，好奇而興奮地談?wù)撨@些信息。

?

就iOS和Android應(yīng)用的性能而言，你會重點監(jiān)測哪些量度？

Kevin: 當(dāng)開發(fā)者同時開發(fā)維護(hù)Android, iOS或是移動HTML5三個版本時。作為一款響應(yīng)式應(yīng)用，移動HTML5常常是我們的選擇，HTML版在最初向用戶介紹應(yīng)用時可以避免安裝。也許有人會 和他們分享信息，而他們會得到一種很棒的本地化體驗，并宣布“哇，我想安裝完全版并繼續(xù)使用”。

得到高度關(guān)注的三種客戶端后，你會希望找出其間的差別，從商業(yè)維度觀測其運(yùn)行，并確定哪一版本帶來更多的流量。較大的挑戰(zhàn)之一是找到安裝來源。那些 來到應(yīng)用商店并開始安裝的用戶，是從哪來？又如何得知？也許我們做過大范圍的廣告推動，為廣告投入了很多資金，但這真的有效？投資回報又如何？或許是我們 博客上的文章帶來了很多訪問量，又或許我們應(yīng)該更貼近那些潛在商機(jī)者，以期達(dá)成目標(biāo)。

在just.me，我們并不直接將引導(dǎo)用戶去應(yīng)用商店，我們會向用戶展示HTML5繪制的網(wǎng)頁，即just.me/gettheapp。讓他們?nèi)?gettheapp，那兒Google Analytics會告訴我們用戶如何得知該產(chǎn)品。我們常在尾部添加查詢字 段，just.me/gettheapp?src=TechCrunchArticle或是just.me /gettheapp?src=emailcampaign。從而根據(jù)量度確定最成功的推廣途徑。HTTP頭部中的URL引用也非常管用。我們試圖盡量平 衡應(yīng)用商店和gettheapp間的訪問。毫無疑問這很有效。

至于其他移動監(jiān)控的用具，最初我們選了Flurry。這種工具天生適合移動領(lǐng)域。我們把它用于iPhone和Android。它能告訴我們?nèi)藗兊氖?持設(shè)備型號。如果馬上關(guān)注Android版just.me，你會發(fā)現(xiàn)，我們支持1500多種設(shè)備。我不可能命令QA，“去測試1500種設(shè)備”或是“隨機(jī) 挑選一種進(jìn)行測試”。我們希望發(fā)現(xiàn)并購置用戶真正用到的那種設(shè)備。

我們支持1500種設(shè)備，但公司里只有10到15種獨立設(shè)備。我確實對開發(fā)者施加過不少壓力來讓他們購置和市場使用者接軌的個人手機(jī)。是否流行對我們而言很重要，因為，只有這樣QA才能側(cè)重關(guān)注人們真正在用的設(shè)備。

幾周前索尼設(shè)備上出過問題，應(yīng)用上架后我們發(fā)現(xiàn)索尼用戶無法發(fā)布信息。之前我們從未購置過索尼設(shè)備。我們曾在百余人中做過beta測試，有意思的 是，他們中沒有人用索尼。反正就是沒有人報告問題。不過，產(chǎn)品發(fā)布的第一天，我撥通了索尼熱線，讓他們盡快送來一臺Xperia。我們拿到了機(jī)器，并在 20分鐘內(nèi)做出了修正，然后上架應(yīng)用商店。

Android的碎片化問題著實煩心，但能在一個小時內(nèi)修正并上架，這很神奇。蘋果應(yīng)用商店上架前經(jīng)常需要近五天來審核新版本。

Android帶來的另一好處是風(fēng)險轉(zhuǎn)移。Google Play在今年的I/O大會上宣稱有alpha和beta版本面市。在just.me應(yīng)用發(fā)布經(jīng)歷三階段：alpha，beta和成品。Alpha版本面 向那些我很熟悉的人，比如我的酒友們，他們也能在手機(jī)上調(diào)試應(yīng)用。如果我想上市新產(chǎn)品，并覺得存在風(fēng)險，我會在alpha階段停留幾日。讓熟悉的人試用， 看看運(yùn)行狀況。這樣，即便發(fā)生了可怕的錯誤，也沒什么可擔(dān)心的。

接下來是beta。這一版本面向那些登錄過網(wǎng)址，并稱“嘿，我對你的產(chǎn)品很有興趣，我很期待上市的那天”的參與者，也許會有幾百人，我們通過 Google+小組進(jìn)行管理。我把應(yīng)用分發(fā)給他們，這一階段發(fā)生錯誤也許不太好，但并非災(zāi)難。由于產(chǎn)品尚處于beta階段，應(yīng)用商店中無法評分。你肯定不 想因為發(fā)布過早而獲得1星評論。這一階段Android已經(jīng)做出很多真正值得開發(fā)者關(guān)注的工作。

就前面提到的索尼案例而言，我們采取的措施是馬上登錄應(yīng)用商店使其不支持所有索尼設(shè)備。若是有手持索尼設(shè)備的人進(jìn)入商店，它會被告之“你的設(shè)備還未 被支持。稍后再來”。我們將索尼設(shè)備下線了四天來等官方承諾的送貨日期。然后，我們完成修復(fù)，并將索尼設(shè)備重設(shè)為支持態(tài)。應(yīng)用商店當(dāng)真帶給你很多便利。

在Apple平臺上進(jìn)行發(fā)布時很有意思的一件事在于如何進(jìn)入編輯推薦區(qū)。Apple希望推薦時能看到你為產(chǎn)品引入很多特色。他們并不提倡每星期提交代碼。不被推薦的較好方法是每周都向顧客推出新功能。而理想情況是一年發(fā)布三到四次。

當(dāng)你完成一項特性的開發(fā)，你會很想立刻將其發(fā)布出去，認(rèn)為這會挽救你的公司，帶來商機(jī)，閉合下行困境而使相關(guān)指數(shù)上揚(yáng)。但我們需要忍，因為要多攢點新特性一起發(fā)布才能上編輯推薦區(qū)。這很痛苦，卻無疑是移動領(lǐng)域成功的關(guān)鍵。

回到Flurry的使用。最近Google Analytics發(fā)布了新更新Universal Access。Universal Access回歸到Android和iPhone的本質(zhì), 讓你能做移動分析。此前，他們?yōu)镴avaScript提供API。

我們用Google Analytics替代Flurry來獲取量度, 但獲取數(shù)據(jù)前你必須真正理解Google Analytics。一般職員并不會去獲取Google Analytics的各類數(shù)據(jù)。市場上只有真正想找到數(shù)據(jù)的人才能得到這些，而普通開發(fā)者并不會閑逛并宣布“噢，我洞察到了”。這不會發(fā)生，沒有人會愿意 讓他們耗費那么久，因為標(biāo)簽，動作或是值集的獲取并不容易，甚至看上去設(shè)計得非常不人性化。

我們開始使用另一樣工具M(jìn)ixpanel。這是一家初創(chuàng)企業(yè)發(fā)布的付費工具，我在JavaOne講演中并未提到。它相當(dāng)友好。API有點像 Flurry，但更擅長同期群分析和路徑分析。你能觀察到是誰做了這些，是否還有其他人在做，你能找到那些使用產(chǎn)品一周以上的長期用戶?；旧?，它更關(guān)注 長期的客戶分層而非單純統(tǒng)計值。

舉一個簡單的例子：如果有人以每周一次，每天五次的頻度注冊并登錄應(yīng)用，你能得到一個多少人仍在使用的大概估計。第一課，可能高達(dá)100%或 90%，第二課，也許80%，下周70%，你希望在50%或其他目標(biāo)上保持穩(wěn)定。若半數(shù)的人還在，你想知道最終是否會下降到0。是否有忠實用戶。一般而 言，新人進(jìn)入時，只關(guān)注統(tǒng)計器會讓你很難分辨這是新人還是老用戶；Mixpanel在這方面做得很好，它允許你關(guān)注關(guān)聯(lián)事件，如消息回復(fù)或類似事件。

?

好的，最后一個問題，在面臨很多工具（自己動手、參與開源項目、采用可信的第三方服務(wù)，如graphite, nagios, jmeter, yammer metrics, New Relic等等）可選時，你會如何抉擇？最主要的影響因素是什么？

Kevin: 我常關(guān)注是否已有現(xiàn)成的解決方案。我會先從開源工具中選取。開源工具的一大好處在于，若是存在痛點，將會是很多人共同的痛點，他們會嘗試修復(fù)，若尚未修 復(fù)，我會親手完成。曾發(fā)生過很多次我或同事修復(fù)痛點的情況，我們編碼回饋發(fā)起者。真的很像一塊踏腳石，你打下樁，其他人幫你完善。

Picasso是源于Square的一款我非常喜歡的程序庫。在just.me我用Picasso來載入圖像。我已經(jīng)向Square提交了一些功能 請求。我還擁有為功能或其他東西投票的權(quán)利。對just.me而言，這很實用。我真的不愿意為緩存和圖像載入編寫所有需要的代碼。

我常常關(guān)注開源，但開源并非次次有效。有時會沒有足夠的人對這一問題感興趣。有時會需要你啟動自己的開源項目。以我在E*TRADE工作時為例，我 想測試應(yīng)用如何在所有瀏覽器中運(yùn)行，我想用Jenkins做持續(xù)集成。沒有人那樣做。我發(fā)起并為Jenkins完成了具備相關(guān)功能的插件。很多人開始貢獻(xiàn) 補(bǔ)丁、修正和各種很棒的功能需求。

很多次，開源方案并不完全適合你的需求。就像我對Graphite所做的，我需要一個儀表盤，他們的儀表盤做得很用心，但很難做出契合需求的修改。 我并不認(rèn)為在他們的儀表盤上再進(jìn)行改進(jìn)來契合需求可行，所以我在他們所提供原始圖表基礎(chǔ)上創(chuàng)建了自己的儀表盤。Graphite圖表的自由度令我嘆為觀 止，但我發(fā)現(xiàn)儀表盤有不足。所以我用自己的工具開發(fā)出一個更靈活的儀表盤。

我也會關(guān)注一些商用軟件。商用產(chǎn)品在滿足需求又不需過多個性化定制的情形下能幫你節(jié)約時間和支出。涉及業(yè)務(wù)核心時從零開始構(gòu)建的確是正確的選擇。你 想和其他產(chǎn)品有足夠的區(qū)分度，你想完完全全控制。具備資本時，你可以力挺開源項目。然而，當(dāng)那些東西作為你的業(yè)務(wù)核心時，你不該總從開源入手。

如果你需要比較高級的功能，比如JVM調(diào)優(yōu)，這時候你會發(fā)現(xiàn)在整個開源界里找不到能夠同時做分析和調(diào)優(yōu)的項目。人們并沒有足夠的時間和精力將之投放到開源世界。我認(rèn)為New Relic已經(jīng)做得很好，所以我們選擇了跟New Relic合作。

?

Kevin Nilson 是一位Java Champion，曾三次獲得JavaOne Rock Star稱號。Kevin在JavaOne, Devoxx, JAX, O"Reilly Fluent, Silicon Valley Code Camp, JAX, HTML5DevConf, On Android, NFJS SpringOne and AjaxWorld等會議上做過講演。Kevin是Web 2.0 Fundamentals的作者之一。 他曾在San Mateo大學(xué)當(dāng)助教。 Kevin擁有Southern Illinois大學(xué)的計算機(jī)碩士和學(xué)士學(xué)位。Kevin是Silicon Valley Java User Group, Silicon Valley Google Developer Group和Silicon Valley JavaScript Meetup的領(lǐng)跑者。

• 上一篇：國內(nèi)公有云服務(wù)商業(yè)務(wù)現(xiàn)狀
• 下一篇：云計算和大數(shù)據(jù)：成功組合指南