轉自：http://chuansong.me/n/1312889
原計劃是寫名字服務相關的一篇文章，但因爲週末出去培訓，實在沒法完成。公司組織大家出去討論關於協同效率問題，之前在騰訊也討論過部門牆的問題。隨着公司的日益增大，這類問題會一直存在，且一直在解決而不能徹底解決。此時，我從運維的角度來談DevOps還是比較應景的，它恰好給這個問題提出了一個全新的解決方案。結合之前自己總結的一個DevOps PPT，在這個文章中，我通過我的PPT逐步來談談我對DevOps的理解（部分來自於自己的總結，部分來自於之前的讀書筆記）：DevOps到底是什麼?給運維帶來了什麼樣的改變和影響？
一、DevOps是什麼？
1、DevOps的初印象
DevOps在很多人看來就是一個代號，先不管它的到底是什麼，但這個代號有一個很大的好處，統一了溝通交流術語，如同之前的敏捷。另外從字面上第一次把DevOps放在一起來看，拋棄了之前的一些概念，比如說運維，甚至更早期的D/O分離等等。
DevOps和Dev/Ops、Dev & Ops是有着一些區別。首先、Dev/Ops、Dev & Ops都強調兩個獨立的職能角色；其次Dev/Ops用分離的視角來看研發和運維，最典型的後果就是研發只看功能需求，不考慮可運維性，而Dev & Ops在一定程度上兩個團隊的合作能力是更強了(平行團隊)，但是還沒有做到真正的跨職能。把DevOps融入到各自的日常活動中，無論是研發、測試和運維都需要面向共同的目標、價值觀、思維模式等等。
2、DevOps是一種文化(Culture)
單純的說是一種文化，非常空洞。文化的表現必須是通過一種運動的形式來表達其內在的價值訴求，就如同文藝復興和五四新文化運動一樣。同樣在DevOps領域，也是因爲多種運動不斷催生的產物，比如說一天10次部署運動、平臺及服務運動、持續迭代運動等等，最終達到其文化價值的傳遞，比如說高質量、高效率的服務交付。從我的角度來說，持續集成、XX(架構、監控)及服務及運維數據化是DevOps的核心，可視化是其最終的呈現。
3、DevOps是一種價值觀（ValueSet）
價值觀是DevOps需要恪守的準則：
（1）持續優化。任何一個工作都不存在完美的狀態，應該持續的推動他，自動化平臺的建設如此，數據驅動DevOps更是如此，因時而變。
（2）合作共贏。把彼此的合作放在第一位，完成面向用戶的共同價值輸出，而非個人所在部門的利益達成。
（3）杜絕浪費。任何停滯都是一種浪費，不作爲更是一種浪費。
（4）關注用戶。用戶的價值爲最終的導向，並且讓用戶的價值反向傳導到內部工作流節點上。
4、DevOps是一種思維模式(MindSet)
在早前我寫過一篇文章探討過互聯網+和雲+之間的關係。我也特意對兩者的思維模式做了一個對比。
其實在思維角度來說，這兩種思維也有很大的相近之處。互聯網思維，雷軍的七字訣不做過多的解釋。在DevOps的思維層面上來說，我也做了一個總結，大致如下：
第一、精益
精益思想（Lean Thinking）源於20世紀80年代日本豐田發明的精益生產（Lean Manufacturing）方式。豐田的精益製造有14項基本原則，後面有人對其的管理思想進行提煉，總結出精益思想有五項基本原則:
（1）從客戶的角度來定義產品價值。價值由客戶定義，而非自己定義。
（2）識別價值流。精益思想識別價值流的含義是在價值流中找到那些是真正增值的活動、那些是可以立即去掉的不增值活動。精益思想將所有業務過程中消耗了資源而不增值活動叫做浪費。識別價值流就是發現浪費和消滅浪費。
（3）讓價值流流動起來。精益將所有的停滯作爲企業的浪費，因此要求創造價值的各個活動（步驟）流動起來，強調的是不間斷地“流動”。
（4）拉動式價值創造。按照客戶的需求進行生產，設置好對應的投入和產出。
（5）持續改進式到盡善盡美。“通過盡善盡美的價值創造過程爲用戶提供盡善盡美的價值”。
在很多管理思想上，原理是互通的，PDCA、全面質量管理、六西格瑪等等，甚至是所遵循的方法論，DevOps也是如此。
第二、價值
當互聯網思維在強調他的用戶口碑的時候，而我們的技術服務則強調他對用戶的價值輸出，從而爲產品贏得口碑。價值在上面也提到是用戶關注的價值，而不是我們認爲的價值。高可用、穩定的服務是質量的根本，質量則是價值的一部分，而不斷的滿足用戶需求的服務纔是重中之重，這就讓各自的團隊有了一個共性的衡量標準。
第三、跨界
其實互聯網思維的專注是讓你對事情有更深入的理解，才能做到極致。而在DevOps所倡導的思維模式，並不是讓你去失去專注，而是在此基礎上讓你更加跨界。在強調職能分工的企業中，過多的限制在某個崗位上行駛某個職能，不利於事務的整體推動。而運維是那個全局觀能力最強的人，恰恰需要這個時候從整個價值鏈的活動來全局觀察，並提出方案。同樣，研發和測試也需要不斷跨出自己的職責區，去和運維一起優化產品和技術方案。
第四、敏捷
業務要求快，技術則要求敏捷，無論是流程的敏捷，還是服務交付都需要非常敏捷。傳統的敏捷觀點是要技術如何更好服務業務部門的需求，是Dev和Biz的之間的合作模式，而現今的敏捷則從持續集成、持續交付、持續部署等多個層次對敏捷提出了新的要求，是Dev、Test、Ops甚至是產品部門一部協奏曲。
5、DevOps是一種工具觀（ToolSet）
DevOps首先倡導的原則是自動化一切，但數據化同樣重要，並且我提出要把他們都可視化呈現出來。自動化是可視化一切價值流的過程，數據化則可視化價值節點的狀態。這個在之前的文章【運維的本質---可視化】，有全面的闡述。
二、DevOps的最佳實踐
Damon列舉了一系列實踐與舉措，對於這些舉措，我也用幾個詞做了備註。這些實踐與舉措在那些成功應用了DevOps的組織中已經成爲它們日常工作的一部分，如下：
去除“完成”這個詞，服務是永不停止的，它們一直在運行並應該得到持續關注【持續優化】
將運維需求與功能需求一樣視爲一等公民，使運維方能夠及早發現需求影響【合作共贏】
將工作流程可視化，使所有人對全局有了解，瓶頸自然顯現【可視化】
協同匹配價值流，這樣才能理解系統全局並發現浪費【價值驅動】
將信息流變爲產品流，以降低信息傳遞中的歧義並澄清人員間必須的交流【拒絕浪費】
將相關數據組合起來形成有意義的指標，讓組織中不同利益相關者都能意識到【數據可視化】
通過將變更關聯到相應指標並將它們圖形化來提升對變更的認知【數據可視化】
有目的地妝點辦公室牆，使每個人都感覺到自己是整個系統的一分子【工作滿意度】
去中心化管控，讓產品的開發者和運維者就責任達成一致（例如：開發者負責代碼的正常運行，運維負責平臺的正常運行，諸如此類）【共享責任文化】
舉行內部小型會議，大家可以在會上就已經完成和可以完成的事項達成一致，會上也鼓勵大家就變更發表自己的意見。【共同參與】
強制在運維的幫助下對所有開發提交的服務進行部署驗證檢查，以避免在運維時纔出現問題【持續部署】
釋放你的猴子，這能使你對自己的服務承諾產生巨大的自信【信任】
在問題發生時不僅在管內（pipeline flow）流轉（要引入更多的變更和工作），而是關注在找到瓶頸發生的真正原因並加以修正【杜絕浪費】
保證對客戶透明，在出現問題時勇於擔當，在問題解決後保持警惕，客戶自然有理由心滿意足【關注用戶】
在團隊和日常工作流以外建立良好關係，例如通過“Guess the Admin”遊戲或與公司內不同的人一起共進午餐【合作與分享】
2013年puppetLabs做了一次DevOps調查，也談到了最佳實踐，彙總如下：
三、DevOps和ITIL對比
DevOps和ITIL有着明顯的不同，從這個不同的也也可以看出，DevOps代表着未來，ITIL已經不適用互聯網的業務運維模式（傳統企業還不敢說）。ITIL應該算是運維第一個階段的指導思想，但在日益快速變化的互聯網運維面前，它已經無法勝任。當然現在有些文章也在表達ITIL的思想和DevOps思想的相同之處，比如說也在強調服務生命週期的管理，最佳實踐也是在指導系統平臺的建設。但我覺得從本質上來講，ITIL完全沒法覆蓋運維的活動，其次沒有從價值鏈的傳導過程設計運維實踐，比如說持續集成，這些都是其致命的弱點。
四、DevOps的核心技術指標（吞吐率和延時）
從DevOps的最佳實踐及自動化要求來看，DevOps本質上就是爲了更好地解決組織的吞吐率（Throughout）和延時(Latency)問題！在前面也談到過，我們可以把所有的運維活動提煉成面向用戶的價值流（flow），這些流從技術層面上來說，真的有點類似於我們線上應用系統的一次請求。對於技術請求來說，對其性能的衡量就是吞吐率和延時，那麼對於運維服務性能(Ops performance)來說，也可以轉換成吞吐率和延時。那麼這兩個指標具體有代表什麼呢？
1、吞吐率
第一、持續集成性能，可以從不同的團隊角色出發提煉出不同的指標。
從研發團隊來說，每天觸發持續構建及單元測試的數量、....；
從測試團隊來說，每天迴歸測試的數量、每天自動化測試的數量、....；
從運維的角度來說，每天持續部署的數量、生成持續反饋報告的數量、....；
第二、其他的變更性能
一個運維人或者團隊，一定週期內的運維變更能力，比如說可以支持多少個業務多少個變更能力。不過這個變更能力取決於兩個方面能力，一個是工具的自動化能力；另外一個取決於線上服務公共化的能力。前者大家很好理解，後者大家就不好理解了。舉個例子，當一個被調用服務需要擴容的時候，此時這個服務被前端服務放在配置文件中還是DNS服務中，這個變更的複雜度完全是不一樣的。
所以對一個運維團隊來說，在構建自動化平臺的同時，也別忘了和研發一起做架構上的優化，提升運維的吞吐能力。
2、延時
第一、持續集成延時
之前提到過把能力不斷前置，其實是把服務的延時不斷降低，類似技術架構中的cache機制。我們都知道，爲了讓業務訪問數據庫更快，就不斷的把數據推到離應用程序更近的地方；爲了讓用戶下載更快，我們把文件通過CDN分佈到離用戶一公里。過往的實踐告訴我們，打破原有的思維定勢非常必要。在過去的觀點中，運維應該是應用環境的第一負責人和執行人，但在持續部署平臺完善的情況下，發佈工作可以不斷往前推置；DNS服務的管理也可以不斷的交給應用運維自己去管理，甚至直接開放API供應用程序直接調度修改使用。這些工作都需要相關團隊的彼此推進和結合，否則很難實現以上所說的角色轉換。前置的最極致表現，就是用戶的行爲對系統產生影響的時候(高容量)，變更即刻自動化完成。
集中式也必須不斷走向分散式，使用去中心化的管理模式。我們都知道中心化能帶來良好的管理和控制，但是最大的影響就是效率，多對一的情況下，那個一很容易成爲瓶頸。但在無平臺的情況下，我不建議這種能力直接往前端推置，不同的人的管理很容易不統一，這個會給後期的統一自動化平臺建設帶來更大的成本，而在有平臺的情況下，把相關的服務能力直接交付給前端。
第二、故障恢復延時
故障恢復越快越好，這就意味着對用戶影響更小。但爲了達到這個故障恢復延時很小，則需要監控平臺、數據平臺強大的支持。如果把故障分解成三階段：發現故障、定位故障、解決故障，則每個步驟依賴的能力是不同的，縮短每一個階段的延時，是我們日常運維在故障處理這塊的工作重點之一。
更高吞吐率、更低延時的運維就是更好的運維，我們須持續不斷的推動及優化！
五、DevOps，運維需要做的改變
1、組織的改變
按照以前職能分工的組織結構造成隔離的責任制文化，大家都只關注自己的崗位職責，而不去care其他。但在DevOps的要求之下，運維活動需要經常的跨職能進行，這也要求部門之間需要有一個共享責任的文化氛圍去更好的銜接部門之間的關係。當前在國外的一些調查報告中可以看出，已經出現了獨立的DevOps部門和DevOps工程師。從組織的角度來說，需要一些DevOps培訓，如同組織引入敏捷培訓一樣。
2、個人的改變
當前每個人要認識到，運維不再是簡單的參與維護職責，而是整體事務的推動者和解決者，此時需要利用運維人的全局觀去把控整體項目的影響等等。
運維人也需要不斷跳出舒適區，去跨界識別風險和提供優化方案；需要讓自己變成善於整合資源的人，集中各團隊的優勢能力，讓我們的運維交付更快、服務更穩定。面向問題和麪向事務的運維需要往面向用戶價值的運維轉變！
3、工具觀的改變
以前以ITIL爲中心的流程系統建設方法論，需要徹底的改變，把持續集成自動化當作第一要務。有了持續集成的平臺之後，不斷去解決底層（如：操作系統安裝）及上層應用調度的自動化，最終形成自底向上的自動化調度平臺方案。
其實DevOps不就是那個協同效率的解決方案麼？