虛擬化，容器化，云計算，自動化為DevOps運動提供了底層技術(shù)支持，新的工具鏈和技術(shù)棧的采用進一步降低了DevOps的技術(shù)門檻，越來越多的企業(yè)紛紛開始自己的DevOps轉(zhuǎn)型之路，然而……
本次分享我們將會討論到：
DevOps以及企業(yè)DevOps轉(zhuǎn)型的現(xiàn)狀
為什么我們需要在DevOps轉(zhuǎn)型中強調(diào)度量
如何實現(xiàn)度量驅(qū)動的DevOps轉(zhuǎn)型
DevOps轉(zhuǎn)型中的其它實踐
Wiki上講：DevOps（Development和Operations的組合詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運維技術(shù)人員（Ops）”之間溝通合作的文化、運動或慣例 （這個是目標）透過自動化“軟件交付”和“架構(gòu)變更”的流程（這個是方法）來使得構(gòu)建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠（這是結(jié)果）。
所以對于企業(yè)來說的真正價值則在于通過團隊間協(xié)作關系的改善， 整個組織效率的提升的同時，可以有效降低伴隨頻繁變化而帶來的生產(chǎn)環(huán)境風險，從而提升企業(yè)應對市場變化響應力。
根據(jù)2016 DevOps調(diào)查報告顯示。成功實施DevOps組織可以更快的去適應整個市場環(huán)境的變化，同時能夠更快的做出調(diào)整。
擁有相比競爭對手擁有更加高的部署頻率，更快的故障恢復時間，更低的變更失敗率以及以及更短的需求交付周期。
然后當企業(yè)大量的采納并使用這些新的工具鏈之后，我們并沒有看到我們所交付的軟件真的如同DevOps的目標一樣，能夠真正的實現(xiàn)軟件快捷，頻繁并且可靠的交付。
DevOps不是盲目的使用新的工具鏈和技術(shù)棧，通過自動化部署流水線的方式，將低質(zhì)量的代碼頻繁的部署到運行環(huán)境。
目前實施DevOps轉(zhuǎn)型的傳統(tǒng)企業(yè)，通過引入自動化確實能提升在軟件交付的某些環(huán)節(jié)中的效率，但是卻很難去提升軟件的交付質(zhì)量，依然引入獨立的測試部門進行大量的系統(tǒng)測試來確保軟件的質(zhì)量，同時企業(yè)也很難度量持續(xù)交付和DevOps實施的效果。
所以目前大部分企業(yè)基本上是把自動化當做DevOps在做，把自動化部署當做持續(xù)交付在做，而很少去考慮軟件交付流程的整體性優(yōu)化。
自動化是實施DevOps的先決條件但是并不能真正的幫助企業(yè)跨越DevOps轉(zhuǎn)型的鴻溝的銀彈。
而對于DevOps的成功轉(zhuǎn)型而言，我們需要做的是持續(xù)的對我們的軟件交付過程進行優(yōu)化，發(fā)現(xiàn)軟件交付過程各個環(huán)節(jié)中存在的瓶頸并持續(xù)改進。
You Can’t Fixed What You Can’t.
而數(shù)據(jù)和度量則是幫助企業(yè)去發(fā)現(xiàn)DevOps轉(zhuǎn)型過程中的瓶頸并且做出改進的關鍵基礎。
在開始時我們說從Wiki上看，DevOps會主要設計到3個部分：目標，方法和結(jié)果。
所以從度量的交付上看我們需要從兩個方面去度量我們的DevOps轉(zhuǎn)型。哪些度量指標是能夠支撐企業(yè)判定DevOps轉(zhuǎn)型結(jié)果。而哪些是能夠去評判軟件的交付過程，并且用于發(fā)現(xiàn)交付瓶頸的。
根據(jù)2016DevOps報告顯示，目前度量企業(yè)DevOps轉(zhuǎn)型是否成功的最終結(jié)果性關鍵指標包括：
吞吐量指標：部署頻率，變更交付周期。
穩(wěn)定性指標：變更失敗率，問題平均恢復時長（mean time to recover）。
吞吐量即敏捷性，確保企業(yè)能夠適應市場的變化，并且快速做出反饋。穩(wěn)定性，即高質(zhì)量。
相比于傳統(tǒng)的IT服務流程績效指標ITIL而言，DevOps更加關注結(jié)果性指標， 即客戶價值。
就好比我們做軟件交付和外賣小哥其實很像，可以評價一個產(chǎn)品是否優(yōu)秀更多的是看交付效率如何，質(zhì)量如何，并且是不是能夠滿足我的預期的？
這兩種截然不同的度量方式本質(zhì)就是OKR和KPI的區(qū)別：
OKR基于目標和關鍵成果，促使我們思考，溝通，每個人都知道什么是最重要的；并且能讓團隊所有人共同的為某件事而努力。
所以對于基于OKR驅(qū)動的DevOps可以確保參與軟件交付過程中的所以角色圍繞具有通過的目標，并且為了這些共同目標去嘗試新的技術(shù)和方法。
而KPI理論則避免按照SMART標準制訂，有些事情值得去做，但在做出來一部分之前無法測量因此無法制訂目標。KPI 還有一個更嚴重的問題，那就是為了完成可測量的目標，有可能實際執(zhí)行手段與該目標要達到的愿景正好相反。
KPI使得團隊使勁往前走，而OKR則確保團隊能夠往正確的方向走。而在軟件交付過程中，開發(fā)，測試，運維都有著不同的考核標準。所以KPI能夠團隊各個成員使勁的按照各自的目標走，而OKR則確保團隊能夠一起往正確的方向走。
DevOps需要的是整體性的優(yōu)化，當你選擇自己企業(yè)內(nèi)部的度量標準時，請問自己兩個問題：
為什么需要度量這個指標？從這個指標中我們能學到什么？
根據(jù)DevOps 2016報告高效的IT組織與中等和低效的IT組織之間在DevOps最終結(jié)果性關鍵指標存在則顯著的差異。
DevOps的最終結(jié)果性指標能夠幫助企業(yè)去衡量和評判DevOps轉(zhuǎn)型的結(jié)果。
當然除了結(jié)果性的指標去驗證DevOps轉(zhuǎn)型所起到的作用以外，我們還需要持續(xù)的度量其他的數(shù)據(jù)去幫助我們發(fā)現(xiàn)在軟件交付各個階段的問題。
包括從需求管理，源碼管理，構(gòu)建過程，測試過程，部署過程，發(fā)布，配置管理，監(jiān)控等各個方面，這里我們列舉了在各個過程當中可能需要的一些度量數(shù)據(jù)。
其中比較典型的包括通過對需求管理進行度量，我們可以知道從需求到需求部署上線的變更交付時間。
在CI過程中我們持續(xù)的去獲取相關的過程數(shù)據(jù)，如構(gòu)建次數(shù)，構(gòu)建頻率，構(gòu)建時長，成功率，平均恢復時間等可以幫助團隊去判定研發(fā)團隊是否能夠做到小步提交，頻繁提交，并且當發(fā)現(xiàn)問題之后能夠快速的恢復。
除此之外，低質(zhì)量的，高復雜度的代碼也會使得軟件交付效率無法得到有效提升，所以我們需要持續(xù)的獲取代碼質(zhì)量相關的數(shù)據(jù)，持續(xù)改進代碼質(zhì)量等等。
所以對于度量驅(qū)動的DevOps轉(zhuǎn)型而言，我們需要持續(xù)的去獲取在軟件交付各個階段所產(chǎn)生的數(shù)據(jù)，以及軟件部署上線之后的監(jiān)控數(shù)據(jù)，用戶行為數(shù)據(jù)等，并且形成對團隊所有人可見的DevOps可視化看板。
而產(chǎn)品/需求管理人員，則可以根據(jù)DevOps結(jié)果性數(shù)據(jù)去評價在過去一段時間內(nèi)DevOps實施所產(chǎn)生的效果，從過程性數(shù)據(jù)中去發(fā)現(xiàn)交付過程中的瓶頸，根據(jù)用數(shù)據(jù)以及線上監(jiān)控數(shù)據(jù)去評價軟件產(chǎn)品是否如預期的一樣產(chǎn)生相應的價值，如果沒有，是否應該做出及時的調(diào)整。
除了通過自動化的方式去構(gòu)建軟件交付的端到端流程提升軟件交付，并且持續(xù)的獲取軟件交付的各個階段所產(chǎn)生的數(shù)據(jù)以外。
我們還應該在軟件交付流程中去設置相應的門禁機制，去讓不滿足質(zhì)量要求的構(gòu)建快速失敗。
在實踐當中，根據(jù)軟件產(chǎn)品的體量的不同完整運行端到端自動化的過程可能會非常長。
所以對于研發(fā)團隊而言，持續(xù)部署流程所產(chǎn)生的反饋周期過長，不利于研發(fā)團隊快速發(fā)現(xiàn)和解決問題。
基本CI流水線頻繁執(zhí)行，由代碼提交觸發(fā)，包含構(gòu)建，單元測試，集成測試，代碼靜態(tài)掃描，部分自動化驗收測試等（端到端運行周期短）。
FOR TEAM：全量流水線每日定時多次觸發(fā)，包含構(gòu)建，單元測試，集成測試，代碼掃描，全量的自動化驗收測試，部署，部署冒煙測試等等（端到端運行周期長）。
FOR QA：手動指定版本部署，手動觸發(fā)。
通過分層流水線，在滿足快速反饋的原則的同時，又能持續(xù)的對軟件進行集成和測試。
同時在流水線當中通過引入質(zhì)量門去控制代碼質(zhì)量，避免技術(shù)債務的積累。
當然對于歷史遺留系統(tǒng)而言，通常會存在大量的歷史債務，這時候我們可以將當前系統(tǒng)的代碼質(zhì)量作為基線標準，同時針對新增代碼設置質(zhì)量門控制，包括新增代碼的代碼風格，復雜度，測試覆蓋率等。
通過可視化流水線將將持續(xù)部署流水線的構(gòu)建過程向整個團隊進行展示，讓所有人都知道當前的項目構(gòu)建狀態(tài)以及進度，如果又構(gòu)建失敗了，成員之間也可以相互提醒盡快修復流水線的失敗。
持續(xù)的獲取過程有效性數(shù)據(jù)和質(zhì)量有效性數(shù)據(jù)為團隊提供可視化看板。
除了門禁機制以外，質(zhì)量內(nèi)建也是團隊成功實施DevOps的關鍵因素，通過在軟件交付的各個階段建立自動化的保障體系可以使團隊能夠盡早的發(fā)現(xiàn)和解決發(fā)現(xiàn)的缺陷。
對于度量驅(qū)動的DevOps轉(zhuǎn)型，通過自動化部署流水線有效提高軟件交付的效率，通過質(zhì)量內(nèi)建確保軟件交付的質(zhì)量，通過對過程性數(shù)據(jù)的持續(xù)收集和分析發(fā)現(xiàn)交付過程中存在的瓶頸，通過對軟件產(chǎn)品和用戶的線上數(shù)據(jù)獲取反饋并且及時作出調(diào)整，通過結(jié)果性數(shù)據(jù)去評價團隊的成效。
最后對于企業(yè)DevOps轉(zhuǎn)型而言：
Automation 自動化是實施DevOps轉(zhuǎn)型的先決條件，自動化一切可以自動化的，降低部署和發(fā)布的難度。
Measure 通過建立有效的監(jiān)控與度量手段來獲得反饋，推動產(chǎn)品和團隊的持續(xù)改進，支持業(yè)務決策。
Lean 協(xié)作文化，自動化，和有效的反饋，這些實施是個長期的過程，需要以精益的方式小步快跑，對過程與技術(shù)進行持續(xù)改善。
Culture OKR目標和關鍵成果驅(qū)動 建立具有跨職能協(xié)作文化和共同目標的一體化團隊；這是DevOps運動的根本！
Sharing 不同職能、不同產(chǎn)品之間分享開發(fā)和運維過程中的想法，知識，問題，以及失敗經(jīng)驗，共同提升能力。
Q&A
Q：基于Jenkins的CI/CD不同用戶是怎么管理的 ？權(quán)限怎么控制的？
A：在DevOps實施里面提倡充分授權(quán)團隊，所以在基礎設施自服務的基礎上讓團隊有自己獨占的Jenkins Master能夠有效的減少權(quán)限控制此類問題，同時可以避免不同團隊之間構(gòu)建任務的相互影響；如果是共用JenkinsMaster，Jenkins有權(quán)限控制的插件可以控制用戶的權(quán)限。
Q：剛才你介紹的CI整個交付流程，每個細節(jié)都需要花大量的時間和精力去開發(fā)和實施，如果公司團隊很多，如果分配自己團隊的時間，時間少了自然達不到效果。
A：在實施DevOps轉(zhuǎn)型過程里面，可以先嘗試試點團隊，通過試點團隊去完成DevOps工具鏈相關的技術(shù)選型，在工具鏈成熟的情況下向其它團隊推廣。
Q ：請問你們有DevOps的自動化運維平臺嗎？可能是一個Web頁面，把DevOps相關的流程和工具集成在上面，方便管理的同時也方便運維開發(fā)一體化操作。這個平臺可能還包括全鏈路檢測系統(tǒng)？
A：目前我們公司做的基于容器持續(xù)交付平臺主要就是解決此類問題，通過流水線來組織工具鏈，同時對相關的環(huán)節(jié)進行度量，為避免廣告嫌疑就不便多說。
Q： 你們在這個過程中怎么做溝通管理，以防止因為這造成的對需求理解的偏差等問題？
A：這塊更多是團隊的組織結(jié)構(gòu)的問題，有興趣可以嘗試通過看板方法，團隊的各個角色都會基于看板完成迭代的開發(fā)，通過看板可以幫助團隊成員之間的溝通和需求確認。
Q：因為很簡單，持續(xù)集成持續(xù)交付，快速迭代，小步快跑，穩(wěn)扎穩(wěn)打，這些都有所有的理論最后都回歸到代碼，所有的變更都回歸到本源代碼的變更，如何保障所有的變更無遺漏，如何保證每一次任務都在正確的代碼基準線上進行，如何出了問題快速反饋到研發(fā)第一線，及時終止問題的蔓延？
A：這塊其實主要的方式就是基于持續(xù)部署流水線的方式，上面分享的時候有提到。通過將流水線通過自動化流水線的方式進行控制，在任何階段出現(xiàn)問題都應該讓流水線失?。ㄩT禁），另外出問題不怕，快速解決問題是關鍵，對于流水線最好可以設置Webhook實時觸發(fā)，可以確保當問題出現(xiàn)后，問題代碼的域可以關聯(lián)到最近的一次提交。
Q：請問你們?nèi)萜靼l(fā)布是如何自動區(qū)分開發(fā)、測試、正式等不同環(huán)境的，是否需要人工介入修改應用訪問關系和啟動環(huán)境變量？
A：目前我們自己持續(xù)交付平臺對接不同的容器運行環(huán)境（目前主要是Rancher），團隊會對環(huán)境進行分類管理，流水線中進行容器部署的時候選擇相應的環(huán)境即可；另外由于主要是基于容器在做，所以也對容器鏡像的不同狀態(tài)也進行了劃分，并且在多個Registry實例之間進行了流轉(zhuǎn)，物理隔離了開發(fā)，測試以及發(fā)布狀態(tài)的容器鏡像。人工介入的部分主要是控制鏡像狀態(tài)的變化這塊。
Q：Jenkins的Pipeline和普通的Project都可以支持流水線 ，2者有區(qū)別嗎？
A：主要解決的問題就是當構(gòu)建出問題的時候如何快速定位問題，假如在流水線線中涉及8個階段，如果只是在一個Project中實現(xiàn)，需要開發(fā)者花很多時間定位；如果是Build Pipeline的話，則可以很直觀的知道問題是發(fā)生在什么階段。
