DockOne微信分享（一零五）：度量驅動的DevOps轉型

本文講的是DockOne微信分享（一零五）：度量驅動的DevOps轉型【編者的話】虛擬化，容器化，雲端計算，自動化為DevOps運動提供了底層技術支援，新的工具鏈和技術棧的採用進一步降低了DevOps的技術門檻，越來越多的企業紛紛開始自己的DevOps轉型之路，然而……

本次分享我們將會討論到：

• DevOps以及企業DevOps轉型的現狀
• 為什麼我們需要在DevOps轉型中強排程量
• 如何實現度量驅動的DevOps轉型
• DevOps轉型中的其它實踐

Wiki上講：DevOps（Development和Operations的組合詞）是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例 （這個是目標）透過自動化“軟體交付”和“架構變更”的流程（這個是方法）來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠（這是結果）。
​
所以對於企業來說的真正價值則在於通過團隊間協作關係的改善， 整個組織效率的提升的同時，可以有效降低伴隨頻繁變化而帶來的生產環境風險，從而提升企業應對市場變化響應力。

根據2016 DevOps調查報告顯示。成功實施DevOps組織可以更快的去適應整個市場環境的變化，同時能夠更快的做出調整。

擁有相比競爭對手擁有更加高的部署頻率，更快的故障恢復時間，更低的變更失敗率以及以及更短的需求交付週期。

然後當企業大量的採納並使用這些新的工具鏈之後，我們並沒有看到我們所交付的軟體真的如同DevOps的目標一樣，能夠真正的實現軟體快捷，頻繁並且可靠的交付。

DevOps不是盲目的使用新的工具鏈和技術棧，通過自動化部署流水線的方式，將低質量的程式碼頻繁的部署到執行環境。

目前實施DevOps轉型的傳統企業，通過引入自動化確實能提升在軟體交付的某些環節中的效率，但是卻很難去提升軟體的交付質量，依然引入獨立的測試部門進行大量的系統測試來確保軟體的質量，同時企業也很難度量持續交付和DevOps實施的效果。

所以目前大部分企業基本上是把自動化當做DevOps在做，把自動化部署當做持續交付在做，而很少去考慮軟體交付流程的整體性優化。

自動化是實施DevOps的先決條件但是並不能真正的幫助企業跨越DevOps轉型的鴻溝的銀彈。

而對於DevOps的成功轉型而言，我們需要做的是持續的對我們的軟體交付過程進行優化，發現軟體交付過程各個環節中存在的瓶頸並持續改進。

You Can’t Fixed What You Can’t.

而資料和度量則是幫助企業去發現DevOps轉型過程中的瓶頸並且做出改進的關鍵基礎。

在開始時我們說從Wiki上看，DevOps會主要設計到3個部分：目標，方法和結果。

所以從度量的交付上看我們需要從兩個方面去度量我們的DevOps轉型。哪些度量指標是能夠支撐企業判定DevOps轉型結果。而哪些是能夠去評判軟體的交付過程，並且用於發現交付瓶頸的。

根據2016DevOps報告顯示，目前度量企業DevOps轉型是否成功的最終結果性關鍵指標包括：

吞吐量指標：部署頻率，變更交付週期。

穩定性指標：變更失敗率，問題平均恢復時長（mean time to recover）。

吞吐量即敏捷性，確保企業能夠適應市場的變化，並且快速做出反饋。穩定性，即高質量。

相比於傳統的IT服務流程績效指標ITIL而言，DevOps更加關注結果性指標， 即客戶價值。

就好比我們做軟體交付和外賣小哥其實很像，可以評價一個產品是否優秀更多的是看交付效率如何，質量如何，並且是不是能夠滿足我的預期的？

這兩種截然不同的度量方式本質就是OKR和KPI的區別：

OKR基於目標和關鍵成果，促使我們思考，溝通，每個人都知道什麼是最重要的；並且能讓團隊所有人共同的為某件事而努力。

所以對於基於OKR驅動的DevOps可以確保參與軟體交付過程中的所以角色圍繞具有通過的目標，並且為了這些共同目標去嘗試新的技術和方法。

而KPI理論則避免按照SMART標準制訂，有些事情值得去做，但在做出來一部分之前無法測量因此無法制訂目標。KPI 還有一個更嚴重的問題，那就是為了完成可測量的目標，有可能實際執行手段與該目標要達到的願景正好相反。

KPI使得團隊使勁往前走，而OKR則確保團隊能夠往正確的方向走。而在軟體交付過程中，開發，測試，運維都有著不同的考核標準。所以KPI能夠團隊各個成員使勁的按照各自的目標走，而OKR則確保團隊能夠一起往正確的方向走。

DevOps需要的是整體性的優化，當你選擇自己企業內部的度量標準時，請問自己兩個問題：

為什麼需要度量這個指標？從這個指標中我們能學到什麼？

根據DevOps 2016報告高效的IT組織與中等和低效的IT組織之間在DevOps最終結果性關鍵指標存在則顯著的差異。

DevOps的最終結果性指標能夠幫助企業去衡量和評判DevOps轉型的結果。

當然除了結果性的指標去驗證DevOps轉型所起到的作用以外，我們還需要持續的度量其他的資料去幫助我們發現在軟體交付各個階段的問題。

包括從需求管理，原始碼管理，構建過程，測試過程，部署過程，釋出，配置管理，監控等各個方面，這裡我們列舉了在各個過程當中可能需要的一些度量資料。

其中比較典型的包括通過對需求管理進行度量，我們可以知道從需求到需求部署上線的變更交付時間。

在CI過程中我們持續的去獲取相關的過程資料，如構建次數，構建頻率，構建時長，成功率，平均恢復時間等可以幫助團隊去判定研發團隊是否能夠做到小步提交，頻繁提交，並且當發現問題之後能夠快速的恢復。

除此之外，低質量的，高複雜度的程式碼也會使得軟體交付效率無法得到有效提升，所以我們需要持續的獲取程式碼質量相關的資料，持續改進程式碼質量等等。

所以對於度量驅動的DevOps轉型而言，我們需要持續的去獲取在軟體交付各個階段所產生的資料，以及軟體部署上線之後的監控資料，使用者行為資料等，並且形成對團隊所有人可見的DevOps視覺化看板。

而產品/需求管理人員，則可以根據DevOps結果性資料去評價在過去一段時間內DevOps實施所產生的效果，從過程性資料中去發現交付過程中的瓶頸，根據用資料以及線上監控資料去評價軟體產品是否如預期的一樣產生相應的價值，如果沒有，是否應該做出及時的調整。

除了通過自動化的方式去構建軟體交付的端到端流程提升軟體交付，並且持續的獲取軟體交付的各個階段所產生的資料以外。

我們還應該在軟體交付流程中去設定相應的門禁機制，去讓不滿足質量要求的構建快速失敗。

在實踐當中，根據軟體產品的體量的不同完整執行端到端自動化的過程可能會非常長。

所以對於研發團隊而言，持續部署流程所產生的反饋週期過長，不利於研發團隊快速發現和解決問題。

1. 基本CI流水線頻繁執行，由程式碼提交觸發，包含構建，單元測試，整合測試，程式碼靜態掃描，部分自動化驗收測試等（端到端執行週期短）。
2. FOR TEAM：全量流水線每日定時多次觸發，包含構建，單元測試，整合測試，程式碼掃描，全量的自動化驗收測試，部署，部署冒煙測試等等（端到端執行週期長）。
3. FOR QA：手動指定版本部署，手動觸發。

通過分層流水線，在滿足快速反饋的原則的同時，又能持續的對軟體進行整合和測試。

同時在流水線當中通過引入質量門去控制程式碼質量，避免技術債務的積累。

當然對於歷史遺留系統而言，通常會存在大量的歷史債務，這時候我們可以將當前系統的程式碼質量作為基線標準，同時針對新增程式碼設定質量門控制，包括新增程式碼的程式碼風格，複雜度，測試覆蓋率等。

通過視覺化流水線將將持續部署流水線的構建過程向整個團隊進行展示，讓所有人都知道當前的專案構建狀態以及進度，如果又構建失敗了，成員之間也可以相互提醒儘快修復流水線的失敗。

持續的獲取過程有效性資料和質量有效性資料為團隊提供視覺化看板。

除了門禁機制以外，質量內建也是團隊成功實施DevOps的關鍵因素，通過在軟體交付的各個階段建立自動化的保障體系可以使團隊能夠儘早的發現和解決發現的缺陷。

對於度量驅動的DevOps轉型，通過自動化部署流水線有效提高軟體交付的效率，通過質量內建確保軟體交付的質量，通過對過程性資料的持續收集和分析發現交付過程中存在的瓶頸，通過對軟體產品和使用者的線上資料獲取反饋並且及時作出調整，通過結果性資料去評價團隊的成效。

最後對於企業DevOps轉型而言：

Automation 自動化是實施DevOps轉型的先決條件，自動化一切可以自動化的，降低部署和釋出的難度。

Measure 通過建立有效的監控與度量手段來獲得反饋，推動產品和團隊的持續改進，支援業務決策。

Lean 協作文化，自動化，和有效的反饋，這些實施是個長期的過程，需要以精益的方式小步快跑，對過程與技術進行持續改善。

Culture OKR目標和關鍵成果驅動 建立具有跨職能協作文化和共同目標的一體化團隊；這是DevOps運動的根本！

Sharing 不同職能、不同產品之間分享開發和運維過程中的想法，知識，問題，以及失敗經驗，共同提升能力。

Q&A

Q：基於Jenkins的CI/CD不同使用者是怎麼管理的 ？許可權怎麼控制的？

A：在DevOps實施裡面提倡充分授權團隊，所以在基礎設施自服務的基礎上讓團隊有自己獨佔的Jenkins Master能夠有效的減少許可權控制此類問題，同時可以避免不同團隊之間構建任務的相互影響；如果是共用JenkinsMaster，Jenkins有許可權控制的外掛可以控制使用者的許可權。

Q：剛才你介紹的CI整個交付流程，每個細節都需要花大量的時間和精力去開發和實施，如果公司團隊很多，如果分配自己團隊的時間，時間少了自然達不到效果。

A：在實施DevOps轉型過程裡面，可以先嚐試試點團隊，通過試點團隊去完成DevOps工具鏈相關的技術選型，在工具鏈成熟的情況下向其它團隊推廣。

Q ：請問你們有DevOps的自動化運維平臺嗎？可能是一個Web頁面，把DevOps相關的流程和工具整合在上面，方便管理的同時也方便運維開發一體化操作。這個平臺可能還包括全鏈路檢測系統？

A：目前我們公司做的基於容器持續交付平臺主要就是解決此類問題，通過流水線來組織工具鏈，同時對相關的環節進行度量，為避免廣告嫌疑就不便多說。

Q： 你們在這個過程中怎麼做溝通管理，以防止因為這造成的對需求理解的偏差等問題？

A：這塊更多是團隊的組織結構的問題，有興趣可以嘗試通過看板方法，團隊的各個角色都會基於看板完成迭代的開發，通過看板可以幫助團隊成員之間的溝通和需求確認。

Q：因為很簡單，持續整合持續交付，快速迭代，小步快跑，穩紮穩打，這些都有所有的理論最後都回歸到程式碼，所有的變更都回歸到本原始碼的變更，如何保障所有的變更無遺漏，如何保證每一次任務都在正確的程式碼基準線上進行，如何出了問題快速反饋到研發第一線，及時終止問題的蔓延？

A：這塊其實主要的方式就是基於持續部署流水線的方式，上面分享的時候有提到。通過將流水線通過自動化流水線的方式進行控制，在任何階段出現問題都應該讓流水線失敗（門禁），另外出問題不怕，快速解決問題是關鍵，對於流水線最好可以設定Webhook實時觸發，可以確保當問題出現後，問題程式碼的域可以關聯到最近的一次提交。

Q：請問你們容器釋出是如何自動區分開發、測試、正式等不同環境的，是否需要人工介入修改應用訪問關係和啟動環境變數？

A：目前我們自己持續交付平臺對接不同的容器執行環境（目前主要是Rancher），團隊會對環境進行分類管理，流水線中進行容器部署的時候選擇相應的環境即可；另外由於主要是基於容器在做，所以也對容器映象的不同狀態也進行了劃分，並且在多個Registry例項之間進行了流轉，物理隔離了開發，測試以及釋出狀態的容器映象。人工介入的部分主要是控制映象狀態的變化這塊。

Q：Jenkins的Pipeline和普通的Project都可以支援流水線 ，2者有區別嗎？

A：主要解決的問題就是當構建出問題的時候如何快速定位問題，假如在流水線線中涉及8個階段，如果只是在一個Project中實現，需要開發者花很多時間定位；如果是Build Pipeline的話，則可以很直觀的知道問題是發生在什麼階段。

以上內容根據2017年1月17日晚微信群分享內容整理。分享人鄭雲龍，睿雲智合持續交付產品負責人，在敏捷和DevOps領域有豐富的實踐經驗，過去作為敏捷和DevOps技術教練向多家大型企業提供諮詢和培訓服務。 DockOne每週都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。

原文釋出時間為：2017-01-18

本文作者：wise2c 

本文來自雲棲社群合作伙伴Dockerone.io，瞭解相關資訊可以關注Dockerone.io。

原文標題：DockOne微信分享（一零五）：度量驅動的DevOps轉型