如今，IT世界里的發(fā)布已經(jīng)變成幾小時(shí)內(nèi)的事情，甚至幾分鐘就能完成。所有的內(nèi)容都要垂直伸縮、水平擴(kuò)展。因此，有一個(gè)良好的監(jiān)控系統(tǒng)是必需的。在很多IT組織里，應(yīng)用是業(yè)務(wù)的核心。但監(jiān)控卻由不寫應(yīng)用的OPS（運(yùn)維）團(tuán)隊(duì)單獨(dú)去做。為什么會(huì)這樣？如果是這樣的話，為什么需要改變？又該如何去改變？怎樣才能得到更好的結(jié)果呢？在這篇
文章里，我將分享我的想法和來自于我和DEV（開發(fā)）團(tuán)隊(duì)一起
工作的經(jīng)驗(yàn)——讓度量變得有意義。
本文描述的觀點(diǎn)來自我在Adform公司任職IT架構(gòu)師（聯(lián)系開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)）的工作經(jīng)驗(yàn)。Adform是一家數(shù)字廣告公司，有自己的開發(fā)團(tuán)隊(duì)（65人）和運(yùn)維團(tuán)隊(duì)（8人）。運(yùn)維團(tuán)隊(duì)負(fù)責(zé)發(fā)布流程和開發(fā)環(huán)境，并負(fù)責(zé)準(zhǔn)備和維護(hù)生產(chǎn)環(huán)境里的網(wǎng)絡(luò)和服務(wù)器。開發(fā)團(tuán)隊(duì)則負(fù)責(zé)維護(hù)他們編寫的應(yīng)用，其中包括發(fā)布到生產(chǎn)環(huán)境里的應(yīng)用。下面的內(nèi)容基于我們的實(shí)際經(jīng)驗(yàn)，這些經(jīng)驗(yàn)有助于開發(fā)人員挖掘度量信息和監(jiān)控信息，但在原來，大家都認(rèn)為度量和監(jiān)控應(yīng)該是完全由運(yùn)維團(tuán)隊(duì)關(guān)心的。
你可能聽說過廣為人知的TDD實(shí)踐——
測試驅(qū)動(dòng)開發(fā)，也可能聽說過鮮為人知的BDD——行為驅(qū)動(dòng)開發(fā)，或者可能聽說過最不為人知的ADD——混蛋驅(qū)動(dòng)開發(fā)（在Scott Berkunn的博文里可以看到一個(gè)不錯(cuò)的開發(fā)實(shí)踐名稱列表）。但度量驅(qū)動(dòng)開發(fā)（MDD）是本文才提出的。
那什么是MDD呢？我認(rèn)為MDD是用度量驅(qū)動(dòng)整個(gè)應(yīng)用開發(fā)的實(shí)踐。在使用MDD的公司里，所有東西都是可以度量的，無論是性能和使用模式，還是收益。此外，開發(fā)人員、運(yùn)維人員、甚至業(yè)務(wù)人員所做的每個(gè)決定都是基于度量結(jié)果的。度量用來監(jiān)控團(tuán)隊(duì)的績效、解決性能瓶頸、估計(jì)硬件需求，或者在開發(fā)生命周期的任意階段達(dá)成其他目的。
度量驅(qū)動(dòng)開發(fā)的主要原則有：
給度量擁有者分配度量項(xiàng)
創(chuàng)建分層的指標(biāo)，相互關(guān)聯(lián)、發(fā)現(xiàn)趨勢
利用度量做決定
每個(gè)度量項(xiàng)都應(yīng)該有一個(gè)擁有者，他/她要掌握一定的知識(shí)和方法來推行、維護(hù)確定的度量結(jié)果。度量擁有者負(fù)責(zé)應(yīng)用、服務(wù)，設(shè)置運(yùn)行應(yīng)用和服務(wù)的服務(wù)器，確保能正常監(jiān)控、收集結(jié)果。度量擁有者要獲取現(xiàn)有度量項(xiàng)的最新結(jié)果，還要為新應(yīng)用或功能設(shè)立新的度量項(xiàng)。
對(duì)度量進(jìn)行結(jié)構(gòu)化也很重要。按照一定標(biāo)準(zhǔn)分組或分層的指標(biāo)能確保所有人（從業(yè)務(wù)人員到開發(fā)人員）更好地理解它們。而且指標(biāo)分層后，能更容易相互關(guān)聯(lián)、發(fā)現(xiàn)趨勢，也能更快地找到、解決問題。
MDD讓整個(gè)開發(fā)過程具備了可見性，所以大家能迅速而又準(zhǔn)確地做出決定，錯(cuò)誤也能被立即發(fā)現(xiàn)、修復(fù)。此外，可以度量的內(nèi)容都能進(jìn)行優(yōu)化。換句話說，MDD能讓你為應(yīng)用“把脈”，并給你提供了一個(gè)持續(xù)改進(jìn)的機(jī)會(huì)。
最后，利用度量給Sprint設(shè)置目標(biāo)，MDD也能借此很好地和其他慣常實(shí)踐結(jié)合起來使用，比如TDD、BDD或Scrum。度量也能發(fā)現(xiàn)問題和生產(chǎn)環(huán)境中的使用模式，這在驗(yàn)收測試過程中很難被注意到。一個(gè)例子是Lance Armstrong
Bug：代碼在測試時(shí)永遠(yuǎn)不會(huì)出錯(cuò)，但還是有證據(jù)表明它和預(yù)期結(jié)果不一致。另一個(gè)例子是從不會(huì)被使用的功能的業(yè)務(wù)Bug。這些Bug相關(guān)的證據(jù)可以用度量來收集。MDD確實(shí)能實(shí)現(xiàn)集中、高效的開發(fā)過程，過程回顧可以提高應(yīng)用使用率。
誰創(chuàng)建指標(biāo)？
當(dāng)我們從無到有開始做一件事情的時(shí)候，你會(huì)有機(jī)會(huì)重新思考一些概念，給流程加入一些創(chuàng)新，甚至完全修改流程。我們?cè)贏dform就做了類似的事情。我們寫完需求、構(gòu)想好完善的監(jiān)控解決方案后，發(fā)現(xiàn)期望和現(xiàn)實(shí)很不匹配。我們本想收集更多應(yīng)用和服務(wù)相關(guān)的信息，因?yàn)樗鼈儙硎杖牒透偁巸?yōu)勢。但監(jiān)控完全由運(yùn)維團(tuán)隊(duì)去做，他們對(duì)基礎(chǔ)設(shè)施有深入的了解，卻不怎么了解應(yīng)用和服務(wù)的內(nèi)部工作原理。
公司不會(huì)因?yàn)樗麄兊姆?wù)器運(yùn)行穩(wěn)定（盡管這很重要）和有10G互聯(lián)網(wǎng)連接而賺錢。公司賺錢是因?yàn)樗麄兊膽?yīng)用和服務(wù)提供的功能，以及功能運(yùn)行穩(wěn)定（這和“服務(wù)器運(yùn)行穩(wěn)定”是不一樣的）。因此要快速發(fā)現(xiàn)問題，把真正編寫應(yīng)用的人引入監(jiān)控流程是必不可少的。事實(shí)上，當(dāng)應(yīng)用和期望不一樣的時(shí)候，開發(fā)人員能很容易看出來，因?yàn)楫a(chǎn)品就是他們開發(fā)的，他們掌握著產(chǎn)品相關(guān)的所有知識(shí)。
最重要的是，開發(fā)人員去監(jiān)控還有更多好處：
開發(fā)團(tuán)隊(duì)能在開發(fā)過程中把監(jiān)控點(diǎn)嵌入到應(yīng)用里去
開發(fā)團(tuán)隊(duì)能從生產(chǎn)環(huán)境里快速獲得應(yīng)用相關(guān)的反饋（性能、Bug、使用模式）
開發(fā)團(tuán)隊(duì)能在開發(fā)過程中
學(xué)習(xí)基礎(chǔ)知識(shí)，可以預(yù)見一些瓶頸
運(yùn)維團(tuán)隊(duì)長久以來一直在做監(jiān)控——CPU、內(nèi)存和IO已經(jīng)溶入到他們的血液里去了，至于應(yīng)用和服務(wù)的指標(biāo)，擁有者應(yīng)該是開發(fā)團(tuán)隊(duì)。開發(fā)團(tuán)隊(duì)掌握著應(yīng)用相關(guān)的所有知識(shí)，還有改進(jìn)所需的所有技能。這就是運(yùn)維團(tuán)隊(duì)為什么不能單獨(dú)做監(jiān)控的原因。開發(fā)團(tuán)隊(duì)?wèi)?yīng)該和運(yùn)維團(tuán)隊(duì)一起設(shè)立、維護(hù)指標(biāo)。在接下來的部分里，我將介紹我們公司是怎么開始改變、如何把開發(fā)人員引入監(jiān)控和度量里的。
在RTB（實(shí)時(shí)競拍）項(xiàng)目中應(yīng)用MDD
經(jīng)過一個(gè)理解、學(xué)習(xí)、失敗、最終成功的過程，我們才幫開發(fā)人員掌握了度量。情況并不簡單，開發(fā)團(tuán)隊(duì)從來沒用過度量，而且突然要依靠度量結(jié)果去做決策。這個(gè)是漫長而艱難的過程，很多因素都會(huì)影響最終結(jié)果，比如公司文化、員工態(tài)度、管理層、甚至工作習(xí)慣。為了讓管理層和開發(fā)團(tuán)隊(duì)“買賬”，先把度量的價(jià)值展示出來就很重要。我們偶然在一個(gè)名為實(shí)時(shí)競拍（Real Time Bidding）的項(xiàng)目里完成了這件事情。
RTB是一種相對(duì)較新的買賣方法，會(huì)實(shí)時(shí)在線顯示廣告，每次顯示一個(gè)廣告。簡而言之，為了在特定網(wǎng)站向特定用戶顯示橫幅廣告，我們通過一個(gè)叫“Ad Exchanges”的結(jié)構(gòu)接收請(qǐng)求，了解客戶愿意支付多少錢。我們收到、處理請(qǐng)求的時(shí)候，會(huì)給發(fā)送端的服務(wù)返回響應(yīng)。這個(gè)項(xiàng)目的運(yùn)營需求是每秒處理四萬個(gè)查詢（QPS），單個(gè)交易的往返處理時(shí)間不超過一百毫秒。
應(yīng)用發(fā)布到生產(chǎn)環(huán)境之后，情況果然非常糟糕，因?yàn)槲覀兠棵胫荒芴幚砦迩€(gè)查詢。而且近30%的交易都失敗了，因?yàn)槲覀儩M足不了一百毫秒的需求。更糟糕的是，性能如此之差卻沒什么明顯的原因。我們搞不清楚問題是源自網(wǎng)絡(luò)、服務(wù)器容量，還是應(yīng)用層。
最終是度量幫我們找出了問題的真正原因，并扭轉(zhuǎn)了局面。我們每秒能處理的查詢最終有七萬多個(gè)（比一開始多十四倍多），同時(shí)能保證失敗交易數(shù)低于0.5%（大概比原來低五十倍）。但為了實(shí)現(xiàn)這樣的結(jié)果，我們對(duì)數(shù)據(jù)進(jìn)行了更多分析和結(jié)構(gòu)化處理，在接下來的章節(jié)中我們繼續(xù)說明。
分層的指標(biāo)
由于在RTB項(xiàng)目開始的時(shí)候我們已經(jīng)有一個(gè)度量項(xiàng)目了，所以我們就在RTB應(yīng)用里嵌入了一些指標(biāo)。而且我們已經(jīng)有針對(duì)服務(wù)器和網(wǎng)絡(luò)方面的度量。但在數(shù)據(jù)的海洋里很難辨別出必要的數(shù)據(jù)、了解趨勢，并找出我們的性能遠(yuǎn)遠(yuǎn)低于要求閾值的原因。很顯然，僅僅有數(shù)據(jù)并不會(huì)帶來多大的價(jià)值。
所以我們決定在三個(gè)層面對(duì)數(shù)據(jù)進(jìn)行可視化：
業(yè)務(wù)指標(biāo)
應(yīng)用指標(biāo)
基礎(chǔ)設(shè)施指標(biāo)
分層的方法讓度量更加結(jié)構(gòu)化了，對(duì)所有人（從開發(fā)人員到業(yè)務(wù)人員）來說都變得可用、易于理解。Business Dashboard成為檢查應(yīng)用狀態(tài)的公共入口點(diǎn)。任何人都可以訪問它，檢查當(dāng)前的狀況是否符合要求的SLA、使用趨勢或收入。如果需要的話，大家還可以深入到Application Dashboard去檢查不同應(yīng)用組件的性能、不同服務(wù)器組的延遲及數(shù)據(jù)增長。事實(shí)上，Application Dashboard上的一些指標(biāo)在Business Dashboard上也有，只是更為詳細(xì)。舉例來說，我們?cè)贐usiness Dashboard上繪制了應(yīng)用性能，在Application Dashboard上則繪制了應(yīng)用不同部分的執(zhí)行情況（見圖1和圖2）。最后，我們?cè)贗nfrastructure Dashboard上檢查關(guān)于CPU、內(nèi)存和I/O使用率的相關(guān)信息。
圖1. Business Dashboard上的應(yīng)用性能
圖2. Application Dashboard上的應(yīng)用性能
要找出問題的根本原因（不僅僅是看結(jié)果），接下來要做的就是把不同的指標(biāo)關(guān)聯(lián)起來。我們把顯示關(guān)鍵指標(biāo)的圖形疊加了起來，從上到下依次是業(yè)務(wù)指標(biāo)、應(yīng)用指標(biāo)和基礎(chǔ)設(shè)施指標(biāo)。這種方法有兩種用途。我們從上往下看這些圖形的時(shí)候，可以清楚地看到QPS的變化是怎樣影響應(yīng)用性能和服務(wù)器CPU的（參見圖3）。相反，從下往上看的時(shí)候，則可以看出I/O的增加是如何影響SLA的。
圖3. 關(guān)聯(lián)的指標(biāo)示例（自上往下依次是：QPS、SLA、競拍服務(wù)的性能、CPU負(fù)荷）
分層和可用的指標(biāo)能讓開發(fā)人員了解項(xiàng)目業(yè)務(wù)方面的內(nèi)容。事實(shí)上他們能看到我們從哪里賺了多少錢。當(dāng)新特性或Bug修復(fù)發(fā)布到生產(chǎn)環(huán)境里后，開發(fā)人員立即就能在Business Dashboard的金錢圖標(biāo)里看到這些內(nèi)容對(duì)收益產(chǎn)生了怎樣的影響。反過來，業(yè)務(wù)人員也能理解項(xiàng)目技術(shù)方面的內(nèi)容，看到開發(fā)人員所面臨的問題和我們的負(fù)載局限。在現(xiàn)實(shí)中，我們還根據(jù)度量設(shè)置了目標(biāo)，借此把MDD嵌入到了Scrum里。最終，參與項(xiàng)目的所有人員都對(duì)項(xiàng)目的各個(gè)部分都有了認(rèn)識(shí)，結(jié)果很圓滿。
利用度量做決策
在任何活動(dòng)里，最重要的事情都是認(rèn)識(shí)和理解目標(biāo)及其背后的原因。你可以創(chuàng)建不同的Dashboard、收集大量度量數(shù)據(jù)，但如果不作為決策的輸入，度量就沒什么用處。我見過好幾個(gè)例子，都是團(tuán)隊(duì)創(chuàng)建了多個(gè)度量項(xiàng)，但大家卻不理解度量的含義和必須設(shè)置的原因。所以他們也沒利用度量指導(dǎo)決策。還有一個(gè)不好的例子，團(tuán)隊(duì)做決策時(shí)甚至不知道他們的應(yīng)用到底是怎么運(yùn)行的（我寧愿說這是我猜的）。他們有一些指標(biāo)，但還不足以從中獲取價(jià)值。
MDD的美妙之處在于，它還能最低限度地減少誤解。當(dāng)基于度量做決策的時(shí)候，幾乎不需要任何解釋。決定變得明確、有邏輯、易于闡述，因此也就不易被反駁。決定做得更快更準(zhǔn)確，團(tuán)隊(duì)的氣氛也好轉(zhuǎn)了很多。此外，這也能帶來跨團(tuán)隊(duì)邊界的級(jí)聯(lián)效應(yīng)。團(tuán)隊(duì)間的溝通更多由數(shù)據(jù)驅(qū)動(dòng)，不再那么情緒化了。換句話說，開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)之間、多個(gè)開發(fā)團(tuán)隊(duì)之間以前會(huì)相互指責(zé)，這種情況現(xiàn)在則很少發(fā)生，甚至完全消失了。
需要注意的是，在某些情況下我們可能從現(xiàn)有的度量里找不到證據(jù)，只會(huì)去猜問題的真正原因。解決辦法是再創(chuàng)建一些指標(biāo)，來支持或否定最初的假設(shè)。
在決策過程中使用度量對(duì)大家來說是一個(gè)雙贏的局面。MDD的主要目標(biāo)是提供基礎(chǔ)設(shè)施和應(yīng)用各個(gè)方面的信息，除此以外，MDD還有助于改進(jìn)團(tuán)隊(duì)內(nèi)部和團(tuán)隊(duì)間的關(guān)系。
我們學(xué)到了什么
我們走了很長的路才在整個(gè)組織里應(yīng)用了MDD實(shí)踐。這不僅僅是技術(shù)的變化，更重要的是文化上的改變。每個(gè)人都需要轉(zhuǎn)換觀念、態(tài)度、對(duì)開發(fā)過程的理解。在達(dá)成愿景的過程中，我們發(fā)現(xiàn)了不同的結(jié)果。因此，我想和大家分享兩個(gè)對(duì)你可能有益的經(jīng)驗(yàn)教訓(xùn)。
我們學(xué)到的第一個(gè)重要經(jīng)驗(yàn)是，你應(yīng)該盡全力為開發(fā)團(tuán)隊(duì)創(chuàng)造盡可能順利的體驗(yàn)，避免充當(dāng)中間人。我們最初嘗試的解決方案是讓運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)共用一個(gè)度量服務(wù)器。但效果并不理想，對(duì)我們來說主要原因有兩個(gè)。第一，開發(fā)團(tuán)隊(duì)受制于運(yùn)維團(tuán)隊(duì)，開發(fā)團(tuán)隊(duì)做的每個(gè)修改都需要運(yùn)維團(tuán)隊(duì)的授權(quán)。第二，運(yùn)維團(tuán)隊(duì)不喜歡開發(fā)團(tuán)隊(duì)頻繁修改內(nèi)容。所以我們決定給開發(fā)團(tuán)隊(duì)專門提供一臺(tái)服務(wù)器，讓他們從中獲取所有服務(wù)器相關(guān)的度量信息。開發(fā)人員在那臺(tái)服務(wù)器上修改內(nèi)容不需要按發(fā)布過程執(zhí)行，也不需要特殊的授權(quán)。事實(shí)上，他們可以在這臺(tái)服務(wù)器上做幾乎所有的事情——甚至從監(jiān)控里刪除其他服務(wù)器。盡管讓開發(fā)人員自由去決定、實(shí)施并負(fù)責(zé)變更看起來有些匪夷所思，但這確實(shí)是我們做過的最好的決定之一。
第二個(gè)非常實(shí)用的經(jīng)驗(yàn)是，我們花費(fèi)時(shí)間去寫“監(jiān)控愿景”或“監(jiān)控工具的需求”，但都是浪費(fèi)時(shí)間，因?yàn)槲覀兊钠谕蛯?shí)現(xiàn)在整個(gè)過程中變更了好幾次。而且它們會(huì)繼續(xù)變化。花費(fèi)過多的時(shí)間去選擇一個(gè)度量工具也是一種浪費(fèi)。沒有工具能滿足你所有的需求，所以挑一個(gè)你用著順手、適合你們?cè)妇昂凸镜木涂梢粤恕Ｎ覀冞x擇了Zabbix——一個(gè)開源工具。盡管它有一些局限，而且導(dǎo)航復(fù)雜（我們甚至稱它為“一點(diǎn)就死的工具”），但它能讓我們迅速開始。最后，別忘了給最常見的用例準(zhǔn)備幾個(gè)收集數(shù)據(jù)、圖形化展示數(shù)據(jù)的例子。
讓MDD變得有趣些，而且讓大家都能看到。把顯示重要指標(biāo)的電視放在門廳或工作空間里。如果可能，圖形化顯示不同項(xiàng)目的收益。給一定的成就設(shè)置獎(jiǎng)勵(lì)，比如連續(xù)成功發(fā)布的次數(shù)（參見圖4）。大家一起度量最好的成績，比如每天、每周、每月最高的訪問量或交易數(shù)，并一起為之慶祝。這種方法會(huì)引發(fā)大家的好奇心，讓大家提出問題，并參與到度量里來。通常情況下，你可以從添加一些簡單的圖形開始。同事們?cè)陂T廳看到后，會(huì)立即提出一些很棒的改進(jìn)意見。
圖4. 成功發(fā)布的獎(jiǎng)勵(lì)
對(duì)參與MDD的所有團(tuán)隊(duì)來說，尤其是對(duì)開發(fā)人員來說，MDD要求的文化變化還是很冒險(xiǎn)的。他們開始用自己的應(yīng)用來觀察問題，之前大家都不了解這種做法。Adform的思維模式完全發(fā)生了變化。原來的態(tài)度是，只要沒人抱怨，就認(rèn)為一切都正常。現(xiàn)在，所有人都知道這不是度量應(yīng)用性能的好辦法。開發(fā)人員現(xiàn)在都能很自如地處理度量了。出乎意料的是，開發(fā)團(tuán)隊(duì)原先看不到度量信息，對(duì)自己的應(yīng)用倒是感覺良好，而現(xiàn)在只要指標(biāo)不可用，他們就會(huì)覺得不舒服。
目前的工作重點(diǎn)和未來計(jì)劃
我們要在整個(gè)組織里推行MDD，新的挑戰(zhàn)會(huì)隨之不斷出現(xiàn)。當(dāng)多個(gè)團(tuán)隊(duì)有不同的需要、愿景、對(duì)度量的理解，卻在一起創(chuàng)建指標(biāo)的時(shí)候，事情就會(huì)變得很混亂。我們要定期刪除不用的指標(biāo)，并以類似的方式讓度量覆蓋到新項(xiàng)目。
目前，我們正試著為開發(fā)人員創(chuàng)建準(zhǔn)則，以確保所有開發(fā)人員達(dá)成共識(shí)。每個(gè)開發(fā)團(tuán)隊(duì)都要能回答下面三個(gè)問題：
你怎么知道你的應(yīng)用運(yùn)行正常？（Bug少并不夠，必須提供進(jìn)一步的證據(jù)，比如模擬）
應(yīng)用的性能隨著時(shí)間的推移會(huì)有怎樣的表現(xiàn)？（比如說，和上一個(gè)版本相比，它是越來越快還是越來越慢？在高負(fù)載情況下是否仍能良好運(yùn)行？）
你的應(yīng)用的使用頻率是多少？（比如有多少用戶會(huì)在同一時(shí)間去生成報(bào)告？系統(tǒng)在白天會(huì)發(fā)布多少橫幅廣告？我們收到多少筆交易？）
這些問題有助于確保所有的應(yīng)用在進(jìn)入生產(chǎn)環(huán)境前都能被度量，并達(dá)到相同的度量覆蓋水平。
至于以后的改進(jìn)，我們現(xiàn)在正在做一個(gè)交通信號(hào)燈監(jiān)控層（為了獲得更快的反饋，最終達(dá)到外包一級(jí)響應(yīng)等級(jí)——參見圖5），還有度量驅(qū)動(dòng)的硬件容量評(píng)估。
圖5. 應(yīng)用信號(hào)燈
總之，把度量加到開發(fā)過程里有很大的潛力。在整個(gè)組織內(nèi)推行這種實(shí)踐是很難的。但潛在的好處也很巨大：應(yīng)用和業(yè)務(wù)表現(xiàn)對(duì)開發(fā)團(tuán)隊(duì)和業(yè)務(wù)人員來說是可見的，大家可以基于真實(shí)的數(shù)據(jù)更快、更準(zhǔn)確地做決定，而且團(tuán)隊(duì)內(nèi)和團(tuán)隊(duì)間的溝通也能得到提升。