這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】虛擬化，容器化，雲端運算，自動化為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實施所產生的效果，從過程性資料中去發現交付過程中的瓶頸，根據用資料以及線上監控資料去評價軟體產品是否如預期的一樣產生相應的價值，如果沒有，是否應該做出及時的調整。
除了通過自動化的方式去構建軟體交付的端到端流程提升軟體交付，並且持續的擷取軟體交付的各個階段所產生的資料以外。
我們還應該在軟體交付流程中去設定相應的門禁機制，去讓不滿足品質要求的構建快速失敗。
在實踐當中，根據軟體產品的體量的不同完整運行端到端自動化的過程可能會非常長。
所以對於研發團隊而言，持續部署流程所產生的反饋周期過長，不利於研發團隊快速發現和解決問題。
基本CI流水線頻繁執行，由代碼提交觸發，包含構建，單元測試，整合測試，代碼靜態掃描，部分自動化驗收測試等（端到端運行周期短）。
FOR TEAM：全量流水線每日定時多次觸發，包含構建，單元測試，整合測試，代碼掃描，全量的自動化驗收測試，部署，部署煙霧測試 (Smoke Test)等等（端到端運行周期長）。
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，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。
