<th id="0poub"></th>
  1. <th id="0poub"><track id="0poub"><dl id="0poub"></dl></track></th><dd id="0poub"><track id="0poub"></track></dd>

    <dd id="0poub"></dd>
    <dd id="0poub"><pre id="0poub"></pre></dd><th id="0poub"></th>
    <th id="0poub"><track id="0poub"></track></th>
    <tbody id="0poub"><pre id="0poub"></pre></tbody>
    <em id="0poub"><acronym id="0poub"><kbd id="0poub"></kbd></acronym></em>
    logo

    地址:深圳南山區大沖國際中心21樓

    聯系我們 : contact@wise2c.com

    產品支持 : service@wise2c.com

    售前咨詢 : sales@wise2c.com

    電話: +86 (755) 33268246

    粵ICP備16049363號

    度量驅動的DevOps轉型

    深圳睿云智合科技有限公司 > 睿云新聞  > 度量驅動的DevOps轉型

    度量驅動的DevOps轉型

    鄭云龍

    分享人:鄭云龍

    時間:2017-1-17

     

    睿云智合持續交付產品負責人,在敏捷和DevOps領域有豐富經驗的實踐,過去作為敏捷和DevOps技術教練向多家大型企業提供咨詢和培訓服務。

     

    虛擬化,容器化,云計算,自動化為DevOps運動提供了底層技術支持,新的工具鏈和技術棧的采用進一步降低了DevOps的技術門檻,越來越多的企業紛紛開始自己的DevOps轉型之路,然而……

    ? DevOps以及企業DevOps轉型的現狀

    ? 為什么我們需要在DevOps轉型中強調度量

    ? 如何實現度量驅動的DevOps轉型

    ? DevOps轉型中的其它實踐

    減少交付周期

     

     

    Wiki上講:DevOps(Development和Operations的組合詞)是一種重視“軟件開發人員(Dev)”和“IT運維技術人員(Ops)”之間溝通合作的文化、運動或慣例?(這個是目標)透過自動化“軟件交付”和“架構變更”的流程(這個是方法)來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠(這是結果)。

    所以對于企業來說的真正價值則在于通過團隊間協作關系的改善,?整個組織效率的提升的同時,可以有效降低伴隨頻繁變化而帶來的生產環境風險,從而提升企業應對市場變化響應力。

    DevOps

     

    根據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轉型結果。而哪些是能夠去評判軟件的交付過程,并且用于發現交付瓶頸的。

    DevOps的最終關鍵指標

     

     

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

    吞吐量指標:部署頻率,變更交付周期。

    穩定性指標:變更失敗率,問題平均恢復時長(mean time to recover)。

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

    IT服務流程績效指標

     

     

    相比于傳統的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組織

     

     

    最后對于企業DevOps轉型而言:

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

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

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

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

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

    其它資料

     

     

    Q&A

     

    Q:基于JenkinsCI/CD不同用戶是怎么管理的??權限怎么控制的?

    A:在DevOps實施里面提倡充分授權團隊,所以在基礎設施自服務的基礎上讓團隊有自己獨占的Jenkins Master能夠有效的減少權限控制此類問題,同時可以避免不同團隊之間構建任務的相互影響;如果是共用JenkinsMaster,Jenkins有權限控制的插件可以控制用戶的權限。

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

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

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

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

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

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

    Q:因為很簡單,持續集成持續交付,快速迭代,小步快跑,穩扎穩打,這些都有所有的理論最后都回歸到代碼,所有的變更都回歸到本源代碼的變更,如何保障所有的變更無遺漏,如何保證每一次任務都在正確的代碼基準線上進行,如何出了問題快速反饋到研發第一線,及時終止問題的蔓延?

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

    Q:請問你們容器發布是如何自動區分開發、測試、正式等不同環境的,是否需要人工介入修改應用訪問關系和啟動環境變量?

    A:目前我們自己持續交付平臺對接不同的容器運行環境(目前主要是Rancher),團隊會對環境進行分類管理,流水線中進行容器部署的時候選擇相應的環境即可;另外由于主要是基于容器在做,所以也對容器鏡像的不同狀態也進行了劃分,并且在多個Registry實例之間進行了流轉,物理隔離了開發,測試以及發布狀態的容器鏡像。人工介入的部分主要是控制鏡像狀態的變化這塊。

    QJenkinsPipeline和普通的Project都可以支持流水線?,2者有區別嗎?

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

    No Comments

    Post a Comment

    Comment
    Name
    Email
    Website