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