本文根據歐陽辰老師在〖2016 Gdevops全球敏捷運維峰會北京站〗現場演講內容整理而成。

講師介紹

大家好，我是來自小米公司的歐陽辰。早先我有幸進入微軟公司，在那工作了10年，做了兩個專案，一個是搜尋，一個是廣告平臺。去年我又加入了本土的小米公司，做一些大資料平臺的工作。此次大會的主題是“Gdevops”，其中的“G”代表了Global，而我正好在微軟、小米積累了一些全球化的經驗，今天就自身所得給大家分享一下。

 本次演講包括以下內容：

一、什麼是DevOps

• 第一，所有競爭性軟體公司終將採用DevOps。
• 第二，DevOps不是銀彈，從本質來看，它是一個工作效率的問題，哪種工作效率好就採用哪種方式，不管是叫DevOps、OpenStack，還是敏捷開發、敏捷測試都無所謂。
• 第三，大量專職運維和測試職位可能慢慢會減少，轉化成一種DevOps的模式。（這塊後面我會解釋為什麼）
• 第四，“靡不有初，鮮克有終”。可能很多人會有轉型的觀點和想法，但執行起來有很多的困難。

2011年在印度召開的谷歌測試大會上，作為谷歌工程非常重要的一個人物——Alberto Savoia在會上發表了一個開題演講，這個演講的題目就叫“Test is Dead”（測試已死）。他的觀點很明確，在網際網路世界，如果你釋出一個產品沒有任何質量問題，這樣的產品是失敗的，而且也釋出得太晚了。他認為，很多測試的質量問題實際上在測試實驗室裡是發現不了的。Alberto Savoia還有很多有趣的觀點，有空大家可以找來看看。

但是，我今天不是來宣佈“測試已死”或者“運維已死”，我主要想和大家分享一個觀點。

這個觀點其實也不是很新鮮了，畢竟最近有很多這樣的熱門討論，包括 “DBA已死”、“Ops已死”等類似的觀點。在我看來，這些角色可能會慢慢地減少，但不意味著他們的任務就消失了，代表的職責就消失了，他們只是變成另外一種工具和形式。

先來談談什麼是質量，有很多定義。以前我們的定義是怎麼找Bug，後來軟體大了，我們會定義怎麼去找matches，怎麼去度量每千行軟體程式碼的Bug數，或者說滿足這些需求輸出的規範程度。這是早先的定義，但在最近幾年，很多定義在慢慢淡化，我們更加強調軟體的質量就是它滿足客戶需求、提供使用者體驗的一種感覺。質量相當於一種經濟競爭性，如果你做得快，迭代得快，很多時候會佔優勢。

其實做DevOps的核心問題就是提高工作效率，提高工作效率算是個老生常談的話題了。大家可以讀一下德魯克寫的這本《21世紀的管理挑戰》，俗話說“文無第一，武無第二”，簡單來說就是無論哪個領域，你很難找到一個大師級的人物是排名世界第一的，但是在管理領域中有個例外，就是德魯克，他的排名永遠是第一的。他的這本著作中寫了很多關於IT資訊科技公司應該怎麼去管理的思考。

他講到，在一個好的公司或者以生產效率為初衷的公司，其實他們更多的是在營造一種氣氛，讓大家提高運維效率、工作效率，而不是去做各種角色，把角色做得細，把人變得像流水線上的一個工人。他更多地強調一種跨界的角色，要不斷學習和教導，強調質量優於數量。

因此，我所理解的DevOps很簡單，就是一種產品的責任心，提升生產力，碰到問題、解決問題的一個過程。

二、微軟是如何做DevOps的

接下來講一下我在微軟的研發過程，以及微軟DevOps是怎麼轉型的。

以前，微軟可以說是一個非常強大的測試公司。在微軟裡，測試工程師的招聘跟開發工程師是完全一樣的，需要寫程式碼，寫很多的測試，待遇也是一樣的。當時比爾·蓋茨說，微軟是世界上最大的測試公司，這是毫無疑問的。因為它當年有12000名的測試工程師，覆蓋了各種產品的測試，有大概7、8個vp for test，就是測試可以直接做到vpm。這是2009年之前的情況。

比爾·蓋茨也說，微軟不光是個軟體公司，更多的是個測試公司，因為微軟早年的軟體就是靠質量支撐的。在2009年以前，微軟有三個非常重要的角色，我們稱之為鐵三角，一個叫產品經理PM，另外兩個是開發和測試。當時這三個角色都非常強大，而且每個角色都有自己的行為目標。

不知道大家有沒有想過產品經理的核心價值是什麼，在我看來，他的核心價值就是釋出產品，不管用什麼手段什麼方法，只要搞定產品釋出就OK了。而開發的核心價值在於實現程式碼。那麼，測試的角色是什麼呢？很多時候在不同人眼中，會有不同的答案。但在當時，微軟把測試的核心價值定義為提供質量反饋，也就是Quality Feedback。意思就是測試團隊要不斷提供測試的反饋，包括程式碼、Bug、生產效率的低下、執行效率的提高、使用者體驗等等。

總的來說，當時微軟的模型就是這樣，但這種模式有很大問題：

• 第一，在產品方面，產品釋出節奏太慢了，測試發現很多問題之後踢給開發，開發又返給測試，整個週期非常長。
• 第二，在流程方面，很多時候我們有design、review，還要寫一些Spec，非常累。我記得當時測試和設計兩個文件，每個文件光模板就有77頁，想想就算只填滿7頁都已經要花多少時間了。
• 第三，在招聘方面，微軟雖然有一個很龐大的測試團隊，但是招測試人員也會遇到很大壓力。因為一些功底比較好的測試工程師更願意找一些開發的工作，而不是測試，雖然待遇是一樣的。

後來在2009年，微軟提出了一個思想：Combine the engineer，基本想法就是把開發和測試合成一個角色，而名稱還是沿用了“開發”這個名字。也就是說，在轉化後，測試和開發全部合在一塊了，測試工程師變成了開發工程師，而測試經理變成了開發經理。

微軟整個DevOps轉化過程分為三個階段，碰到過很多問題。比如說，轉化後整個團隊更扁平了，可能以前有些主管就不再帶人了，也可能以前有的人在測試領域是非常擅長的，可產品的部分他不太熟悉。還有包括運維，以前運維是個非常大的獨立團隊，但現在也全部轉化到Combine the engineer去。

微軟的第二階段大概花了四年的時間，這時總體來看，開發和測試合在一起了，而運維還相對獨立些。以前只有運維可以上線，但在第二階段開發和測試也能上線了，不過資料庫的一些部署主要還是由運維來上線。

到了第三階段，也就是2013年之後，微軟的運維角色已經非常少了，後來主要就集中在一些機房裡。因為機房裡有成千上萬臺機器，每天都有大量的硬碟壞掉，所以他門的工作就是換硬碟，每天推著一個手推車在機房裡竄來竄去。

所以微軟在融合的過程，把開發、測試、運維都變成一個角色。這樣簡化角色有一個好處，就是責任比較清楚，產品出問題了就是找你。以前產品出問題，經常要打電話給運維，但運維需要一個很長的路徑才能接到電話，所以後來就改成所有線上問題都打給開發。反正你做了開發、做了測試、做了部署，都是你的事，那你也把這個事情搞定就好了。而開發人員也可以在整個過程中體會到怎麼做產品，學到很多很重要的東西。

這是微軟以前一些角色和任務的轉移：

在工作方式上，也從以前的服從計劃變成一種主動的探索。

以前，微軟都是產品經理定好了工作方向，然後大家一起努力，加班加點，往這個方向去做。因為覺得方向肯定是對的，所以只要用最好的演算法、最努力的態度去搞定就好了。但後來發現，其實你做出來的東西在市面上不一定受歡迎，而且競爭壓力也很大。

在微軟改成DevOps模式以後，工作方式轉變成主動探索，我們會去嘗試不同的方向，也不會認為哪個方向就一定是對的，我們還會做一些取捨，找到最終需要用到的方向。這也顯示了一個極客文化，包括我們有很多黑客，大家找兩天一起程式設計，實現一些好的idea。同時，這也強調了微軟的一種程式碼文化，就是少說話，有什麼想法show me code。

微軟的Combined Engineering從效果上來看，使得產品釋出節奏明顯加快，以前我們討論“做和不做”，現在是討論“如何做得更快”。大家都會去交流生產力問題的焦點，體現了一種線上產品的主人翁精神。轉型之後，我們內部還做了一個調查，發現開發者的工作效率、工作熱情都有正面的上升。

微軟在實現整個轉型的過程中有幾個原則：

• 第一個原則叫Live Site First，就是說線上事故永遠是第一位的，而且是需要寫程式碼的人第一時間負責處理，不能推託給別人。
• 第二個原則是計劃永遠會變，不要討價還價，要保持一種心態，主動去適應這個變化。所以後來，關於timeline這個東西，我們越做越簡單了，而且做計劃時基本上想到兩三個月的目標就可以了，很多時候不會想得太遠。因為想得太遠，中間就會出現更多變化。
• 第三個原則是持續優化工程效率，包括引入持續整合、持續部署，這些概念都很好，核心問題在於什麼時候引入這個概念，以怎樣的投資去做，是大家邊做邊試還是其他方式。
• 第四個原則是資料驅動的工程實踐，就是指後來我們不依賴測試了，那怎麼去保證它的質量呢？怎麼判斷這個工程能用？這涉及到後面的監測環節。

微軟大概是做了這麼一個DevOps轉型，而很多網際網路公司其實也是這麼做的。

比如說Facebook，Facebook是沒有測試的，強調“NO Testers”這種文化，也是做單元測試、灰度測試為主，都有開發人員來做，但沒有測試人員。

再比如谷歌，以前一個微軟同事去了谷歌，寫了一本介紹谷歌測試的書。書的內容其實很簡單，就是說谷歌測試團隊歸於開發效率團隊，職責是指導開發人員怎麼去寫測試用例之類的，他們開發和測試的比例大約是10:1，即10個開發對1個測試。

亞馬遜還有一些測試功能，主要是集中在一些業務場景。

大家可能都知道，Facebook每週有一個灰度釋出的過程。每週日晚上它會發佈一個完整的build，星期一早上可能會推大概1%-2%到線上，然後星期二下午看看效果，沒有問題的話星期三把它推到全線。每週都有這樣一個節奏，並通過反饋的指標來看效果好不好。

• Google Runtime Analysis and Testing

谷歌的測試也沒有什麼神祕的，就是有單元測試、整合測試、Staging測試等。

在網際網路公司中，可能有一個傳統，就是我們可能更願意把一些測試從釋出前挪到釋出後，換句話說，就是釋出後再測試。釋出前可以做一些單元測試、功能測試、探索性測試，釋出之後可以邊做整合測試邊做系統測試。

比如我在微軟時有一個專案就是做效能測試，很多時候我會利用微軟晚上機房裡一些流量比較低的機器。我會啟動這些機器，模擬一些流量，直接打到線上產品的伺服器上，再看它的效果。這時就可以充分利用線上的一些伺服器來幫助你做一些測試，看很多指標，你還可以邀請使用者去幫你做一些測試，比如β測試，可以邀請少量的使用者使用3%或5%的流量enable the feature，然後觀察這些使用者的關鍵指標有沒有變，比如使用者時長、返回的響應時間等。

三、小米是如何做DevOps的

大家應該知道小米手機的軟體是一個深度定製的Android系統，叫做MIUI。以前很難想象一個手機作業系統可以做到每個星期更新一次，甚至在列目板塊，作業系統每天都有新的版本，包括我的手機使用的就是MIUI的內部版本。每天都是最新的版本，但基本上沒有影響過我打電話、玩一些常用的軟體。所以小米MIUI也有幾個版本，體驗版是每天發行，開發版是每週五下午發行，穩定版是每一兩個月發行一次。能把作業系統做得這麼快，這是我們非常重要的一個目標。

包括應用也是。以前應用都是跟MIUI ROM作業系統一起釋出，但這樣太慢了，後來就改成單發，每個應用自己發版，不需要走系統ROM的發版。後來還是覺得慢，就開始用Hybrid的H5做了。大概就是主要頁面有一些用H5的，這樣調整更方便，可有些體驗相關頁面還是要用native code來寫。整個過程圍繞如何做得更快更好來寫，這就是DevOps的核心問題。

在部署方面，小米自己開發了一套自動部署系統。沒有什麼神祕的地方，基本上每臺機上有些後臺程序幫你去從程式碼拉伺服器，拉完程式碼幫你做build，build完之後一臺一臺機器上線，上完一臺會給你發一些訊息，做一些測試，沒問題繼續上。這個系統叫AESIR。

小米也有自己的監控系統，叫Open-Falco，是我們去年11月開源的一個系統。大概也是在每個機器上裝些agent，agent把performance counter收集起來，包括機器效能打到中間伺服器裡面，後面有HBase和MySQL，提供一些介面幫你去查詢這些圖表、趨勢，大家有空可以看一下。Opensource也有很多解決方案，例如OpenTSDB等類似的解決方案。Open-Falco是我們開源的內部使用得不錯的一款系統，它可以定義很多查詢條件，做些定義的圖片，報警了就發到你手機上。

四、如何成功向DevOps轉型

傳統的質量評判，是在測試環節結束後，測試機體會跳出來說質量已經滿足了我的要求，OK，按綠燈，發出去。這感覺是一種好像沒有人阻止你上線，但是後果由你自己承擔責任的模式。出於這一考慮，開發人員就會有很大的動力去增加更多產品的指標，進而達到質量提升，這是一個比較健康的模式。

那麼，產品質量到底能不能度量呢？這是一個很有趣的問題。有本書叫《資料化決策》，裡面認為所有的事情都是可以度量的，可以用數字化去表示。比如他說可口可樂的口味是可以度量的，他通過邀請20萬人去做可口可樂新口味的調查，最終得出結論。再比如說，他設定一種方法，推斷出幸福的婚姻相當於你年收入增加2萬美元。總之，它運用了很多方法和指標。

小米在這裡會強調幾個事情：

• 第一個是Time to detect，也就是你什麼時候發現問題。
• 第二個概念叫Time to Engagement，發現問題以後你隔多久去處理這個問題，好比你在手機上看到這個問題，你要多久才能到網路去處理這樣一個問題。
• 第三個是Time to mitigate，即你花多少時間去減輕這個問題，比如你把這個資料庫變成備用資料庫，把問題減輕了，這是一個指標。
• 最後一個是Time to Resolve，就是什麼時候把這個問題徹底解決了。整個工程都是圍繞DevOps來解決線上的問題。

那麼，不同性質的應用程式，它們的釋出節奏分別是怎樣的呢？我們在這一塊有很多想法，也做了很多事情。

• 前段應用一個是前端應用的釋出會比較頻繁，基本會達到每天去釋出，然後測試會依賴一些手工測試。
• 業務邏輯業務邏輯也是會比較有節奏地去釋出，特別是Java的一些邏輯。這個時候就會去依賴一些自動化測試。
• 資料儲存資料庫方面的測試會更加謹慎一些，特別是一些schema的改變。會比較低頻率地釋出。
• 資料處理資料庫的測試很多時候會依賴於整合測試，在表的設計上會盡量減少線上影響的方式去改資料庫，包括我們只增加不減少，很多時候我們的質量不是通過測試來保證，而是在設計上進行保障。

五、DevOps的基礎架構和工具

DevOps有很多工具，然而我覺得在每個團隊裡，核心問題並不在於你比我用了更好的庫的工具，而是在於在適當的時候解決適當的問題，用簡單的方法解決團隊的大問題。不是用很重的工具去解決，而是把大問題分解成幾個小問題去突破。

整個自動化基本架構包括持續整合、持續部署、shell、Service等，持續整合和持續部署就不說了。Service非常重要，就是需要把一些好的服務變成一個共享的服務去使用，包括DNS、申請虛擬機器等。以前我們申請虛擬機器都要去找運維，後來我們就跟運維強調，所有申請的機器直接讓開發人員去做，不用找運維等運維再同意，讓整個過程的效益再快一點。

DevOps有很多開源工具，相信大家都比較熟悉了，這裡就不一一介紹。這些都可以在網上搜到，基本上一個工具可以解決一個小問題。主要還是要看自己的團隊具體需要解決什麼問題。

六、小結

• 競爭性軟體公司終將採用DevOps
• DevOps不是銀彈，是關於效率的文化，自動化的技術
• 大量專職運維和測試將消失和減少
• “靡不有初，鮮克有終”

 2、我理解的3大核心問題和2個非核心問題

三大核心問題：

• 自動化釋出：灰度釋出(Staged Deployment)
• 自動化監控：產品監控和報警
• 自助PaaS（基礎平臺服務）：儲存，容器，佇列，認證等

兩個非核心問題：

• 持續整合CI（Build->Test）
• 持續交付CD (Ready for deployment)

 3、DevOps和適應變化

DevOps實際上是一個關於適應的文化。動物學家達爾文曾說過：“世界上進化下來的動物，並不是最強大的動物，也不是最聰明的動物，而是那些最能適應變化(Responsive to change)的動物”，比如說老鼠、蚊子、螞蟻等等。軟體系統也一樣，能夠傳承發揚的軟體，必定能夠快速適應變化。所以很多時候公司需要有一個適應力非常強的工程師，才能幫助公司、團隊解決業務問題。

最後，DevOps轉型不是一蹴而就的，這個過程可能是漫長的、持久的，但也是必須的，與時俱進的！走在DevOps轉型路上的每一位前行者，唯有堅持不懈地去探索，才能不忘初心，方得始終。

文章出處：DBAplus社群