本次分享我們將會(huì)討論到：
DevOps以及企業(yè)DevOps轉(zhuǎn)型的現(xiàn)狀
為什么我們需要在DevOps轉(zhuǎn)型中強(qiáng)調(diào)度量
如何實(shí)現(xiàn)度量驅(qū)動(dòng)的DevOps轉(zhuǎn)型
DevOps轉(zhuǎn)型中的其它實(shí)踐
Wiki上講：DevOps（Development和Operations的組合詞）是一種重視“軟件開(kāi)發(fā)人員（Dev）”和“IT運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化、運(yùn)動(dòng)或慣例 （這個(gè)是目標(biāo)）透過(guò)自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程（這個(gè)是方法）來(lái)使得構(gòu)建、測(cè)試、發(fā)布軟件能夠更加地快捷、頻繁和可靠（這是結(jié)果）。
所以對(duì)于企業(yè)來(lái)說(shuō)的真正價(jià)值則在于通過(guò)團(tuán)隊(duì)間協(xié)作關(guān)系的改善， 整個(gè)組織效率的提升的同時(shí)，可以有效降低伴隨頻繁變化而帶來(lái)的生產(chǎn)環(huán)境風(fēng)險(xiǎn)，從而提升企業(yè)應(yīng)對(duì)市場(chǎng)變化響應(yīng)力。
根據(jù)2016 DevOps調(diào)查報(bào)告顯示。成功實(shí)施DevOps組織可以更快的去適應(yīng)整個(gè)市場(chǎng)環(huán)境的變化，同時(shí)能夠更快的做出調(diào)整。
擁有相比競(jìng)爭(zhēng)對(duì)手擁有更加高的部署頻率，更快的故障恢復(fù)時(shí)間，更低的變更失敗率以及以及更短的需求交付周期。
然后當(dāng)企業(yè)大量的采納并使用這些新的工具鏈之后，我們并沒(méi)有看到我們所交付的軟件真的如同DevOps的目標(biāo)一樣，能夠真正的實(shí)現(xiàn)軟件快捷，頻繁并且可靠的交付。
DevOps不是盲目的使用新的工具鏈和技術(shù)棧，通過(guò)自動(dòng)化部署流水線的方式，將低質(zhì)量的代碼頻繁的部署到運(yùn)行環(huán)境。
目前實(shí)施DevOps轉(zhuǎn)型的傳統(tǒng)企業(yè)，通過(guò)引入自動(dòng)化確實(shí)能提升在軟件交付的某些環(huán)節(jié)中的效率，但是卻很難去提升軟件的交付質(zhì)量，依然引入獨(dú)立的測(cè)試部門進(jìn)行大量的系統(tǒng)測(cè)試來(lái)確保軟件的質(zhì)量，同時(shí)企業(yè)也很難度量持續(xù)交付和DevOps實(shí)施的效果。
所以目前大部分企業(yè)基本上是把自動(dòng)化當(dāng)做DevOps在做，把自動(dòng)化部署當(dāng)做持續(xù)交付在做，而很少去考慮軟件交付流程的整體性優(yōu)化。
自動(dòng)化是實(shí)施DevOps的先決條件但是并不能真正的幫助企業(yè)跨越DevOps轉(zhuǎn)型的鴻溝的銀彈。
而對(duì)于DevOps的成功轉(zhuǎn)型而言，我們需要做的是持續(xù)的對(duì)我們的軟件交付過(guò)程進(jìn)行優(yōu)化，發(fā)現(xiàn)軟件交付過(guò)程各個(gè)環(huán)節(jié)中存在的瓶頸并持續(xù)改進(jìn)。
You Can’t Fixed What You Can’t.
而數(shù)據(jù)和度量則是幫助企業(yè)去發(fā)現(xiàn)DevOps轉(zhuǎn)型過(guò)程中的瓶頸并且做出改進(jìn)的關(guān)鍵基礎(chǔ)。
在開(kāi)始時(shí)我們說(shuō)從Wiki上看，DevOps會(huì)主要設(shè)計(jì)到3個(gè)部分：目標(biāo)，方法和結(jié)果。
所以從度量的交付上看我們需要從兩個(gè)方面去度量我們的DevOps轉(zhuǎn)型。哪些度量指標(biāo)是能夠支撐企業(yè)判定DevOps轉(zhuǎn)型結(jié)果。而哪些是能夠去評(píng)判軟件的交付過(guò)程，并且用于發(fā)現(xiàn)交付瓶頸的。
根據(jù)2016DevOps報(bào)告顯示，目前度量企業(yè)DevOps轉(zhuǎn)型是否成功的最終結(jié)果性關(guān)鍵指標(biāo)包括：
吞吐量指標(biāo)：部署頻率，變更交付周期。
穩(wěn)定性指標(biāo)：變更失敗率，問(wèn)題平均恢復(fù)時(shí)長(zhǎng)（mean time to recover）。
吞吐量即敏捷性，確保企業(yè)能夠適應(yīng)市場(chǎng)的變化，并且快速做出反饋。穩(wěn)定性，即高質(zhì)量。
相比于傳統(tǒng)的IT服務(wù)流程績(jī)效指標(biāo)ITIL而言，DevOps更加關(guān)注結(jié)果性指標(biāo)， 即客戶價(jià)值。
就好比我們做軟件交付和外賣小哥其實(shí)很像，可以評(píng)價(jià)一個(gè)產(chǎn)品是否優(yōu)秀更多的是看交付效率如何，質(zhì)量如何，并且是不是能夠滿足我的預(yù)期的？
這兩種截然不同的度量方式本質(zhì)就是OKR和KPI的區(qū)別：
OKR基于目標(biāo)和關(guān)鍵成果，促使我們思考，溝通，每個(gè)人都知道什么是最重要的；并且能讓團(tuán)隊(duì)所有人共同的為某件事而努力。
所以對(duì)于基于OKR驅(qū)動(dòng)的DevOps可以確保參與軟件交付過(guò)程中的所以角色圍繞具有通過(guò)的目標(biāo)，并且為了這些共同目標(biāo)去嘗試新的技術(shù)和方法。
而KPI理論則避免按照SMART標(biāo)準(zhǔn)制訂，有些事情值得去做，但在做出來(lái)一部分之前無(wú)法測(cè)量因此無(wú)法制訂目標(biāo)。KPI 還有一個(gè)更嚴(yán)重的問(wèn)題，那就是為了完成可測(cè)量的目標(biāo)，有可能實(shí)際執(zhí)行手段與該目標(biāo)要達(dá)到的愿景正好相反。
KPI使得團(tuán)隊(duì)使勁往前走，而OKR則確保團(tuán)隊(duì)能夠往正確的方向走。而在軟件交付過(guò)程中，開(kāi)發(fā)，測(cè)試，運(yùn)維都有著不同的考核標(biāo)準(zhǔn)。所以KPI能夠團(tuán)隊(duì)各個(gè)成員使勁的按照各自的目標(biāo)走，而OKR則確保團(tuán)隊(duì)能夠一起往正確的方向走。
DevOps需要的是整體性的優(yōu)化，當(dāng)你選擇自己企業(yè)內(nèi)部的度量標(biāo)準(zhǔn)時(shí)，請(qǐng)問(wèn)自己兩個(gè)問(wèn)題：
為什么需要度量這個(gè)指標(biāo)？從這個(gè)指標(biāo)中我們能學(xué)到什么？
根據(jù)DevOps 2016報(bào)告高效的IT組織與中等和低效的IT組織之間在DevOps最終結(jié)果性關(guān)鍵指標(biāo)存在則顯著的差異。
DevOps的最終結(jié)果性指標(biāo)能夠幫助企業(yè)去衡量和評(píng)判DevOps轉(zhuǎn)型的結(jié)果。
當(dāng)然除了結(jié)果性的指標(biāo)去驗(yàn)證DevOps轉(zhuǎn)型所起到的作用以外，我們還需要持續(xù)的度量其他的數(shù)據(jù)去幫助我們發(fā)現(xiàn)在軟件交付各個(gè)階段的問(wèn)題。
包括從需求管理，源碼管理，構(gòu)建過(guò)程，測(cè)試過(guò)程，部署過(guò)程，發(fā)布，配置管理，監(jiān)控等各個(gè)方面，這里我們列舉了在各個(gè)過(guò)程當(dāng)中可能需要的一些度量數(shù)據(jù)。
其中比較典型的包括通過(guò)對(duì)需求管理進(jìn)行度量，我們可以知道從需求到需求部署上線的變更交付時(shí)間。
在CI過(guò)程中我們持續(xù)的去獲取相關(guān)的過(guò)程數(shù)據(jù)，如構(gòu)建次數(shù)，構(gòu)建頻率，構(gòu)建時(shí)長(zhǎng)，成功率，平均恢復(fù)時(shí)間等可以幫助團(tuán)隊(duì)去判定研發(fā)團(tuán)隊(duì)是否能夠做到小步提交，頻繁提交，并且當(dāng)發(fā)現(xiàn)問(wèn)題之后能夠快速的恢復(fù)。
除此之外，低質(zhì)量的，高復(fù)雜度的代碼也會(huì)使得軟件交付效率無(wú)法得到有效提升，所以我們需要持續(xù)的獲取代碼質(zhì)量相關(guān)的數(shù)據(jù)，持續(xù)改進(jìn)代碼質(zhì)量等等。
所以對(duì)于度量驅(qū)動(dòng)的DevOps轉(zhuǎn)型而言，我們需要持續(xù)的去獲取在軟件交付各個(gè)階段所產(chǎn)生的數(shù)據(jù)，以及軟件部署上線之后的監(jiān)控?cái)?shù)據(jù)，用戶行為數(shù)據(jù)等，并且形成對(duì)團(tuán)隊(duì)所有人可見(jiàn)的DevOps可視化看板。
而產(chǎn)品/需求管理人員，則可以根據(jù)DevOps結(jié)果性數(shù)據(jù)去評(píng)價(jià)在過(guò)去一段時(shí)間內(nèi)DevOps實(shí)施所產(chǎn)生的效果，從過(guò)程性數(shù)據(jù)中去發(fā)現(xiàn)交付過(guò)程中的瓶頸，根據(jù)用數(shù)據(jù)以及線上監(jiān)控?cái)?shù)據(jù)去評(píng)價(jià)軟件產(chǎn)品是否如預(yù)期的一樣產(chǎn)生相應(yīng)的價(jià)值，如果沒(méi)有，是否應(yīng)該做出及時(shí)的調(diào)整。
除了通過(guò)自動(dòng)化的方式去構(gòu)建軟件交付的端到端流程提升軟件交付，并且持續(xù)的獲取軟件交付的各個(gè)階段所產(chǎn)生的數(shù)據(jù)以外。
我們還應(yīng)該在軟件交付流程中去設(shè)置相應(yīng)的門禁機(jī)制，去讓不滿足質(zhì)量要求的構(gòu)建快速失敗。
在實(shí)踐當(dāng)中，根據(jù)軟件產(chǎn)品的體量的不同完整運(yùn)行端到端自動(dòng)化的過(guò)程可能會(huì)非常長(zhǎng)。
所以對(duì)于研發(fā)團(tuán)隊(duì)而言，持續(xù)部署流程所產(chǎn)生的反饋周期過(guò)長(zhǎng)，不利于研發(fā)團(tuán)隊(duì)快速發(fā)現(xiàn)和解決問(wèn)題。
基本CI流水線頻繁執(zhí)行，由代碼提交觸發(fā)，包含構(gòu)建，單元測(cè)試，集成測(cè)試，代碼靜態(tài)掃描，部分自動(dòng)化驗(yàn)收測(cè)試等（端到端運(yùn)行周期短）。
FOR TEAM：全量流水線每日定時(shí)多次觸發(fā)，包含構(gòu)建，單元測(cè)試，集成測(cè)試，代碼掃描，全量的自動(dòng)化驗(yàn)收測(cè)試，部署，部署冒煙測(cè)試等等（端到端運(yùn)行周期長(zhǎng)）。
FOR QA：手動(dòng)指定版本部署，手動(dòng)觸發(fā)。
通過(guò)分層流水線，在滿足快速反饋的原則的同時(shí)，又能持續(xù)的對(duì)軟件進(jìn)行集成和測(cè)試。
同時(shí)在流水線當(dāng)中通過(guò)引入質(zhì)量門去控制代碼質(zhì)量，避免技術(shù)債務(wù)的積累。
當(dāng)然對(duì)于歷史遺留系統(tǒng)而言，通常會(huì)存在大量的歷史債務(wù)，這時(shí)候我們可以將當(dāng)前系統(tǒng)的代碼質(zhì)量作為基線標(biāo)準(zhǔn)，同時(shí)針對(duì)新增代碼設(shè)置質(zhì)量門控制，包括新增代碼的代碼風(fēng)格，復(fù)雜度，測(cè)試覆蓋率等。
通過(guò)可視化流水線將將持續(xù)部署流水線的構(gòu)建過(guò)程向整個(gè)團(tuán)隊(duì)進(jìn)行展示，讓所有人都知道當(dāng)前的項(xiàng)目構(gòu)建狀態(tài)以及進(jìn)度，如果又構(gòu)建失敗了，成員之間也可以相互提醒盡快修復(fù)流水線的失敗。
持續(xù)的獲取過(guò)程有效性數(shù)據(jù)和質(zhì)量有效性數(shù)據(jù)為團(tuán)隊(duì)提供可視化看板。
除了門禁機(jī)制以外，質(zhì)量?jī)?nèi)建也是團(tuán)隊(duì)成功實(shí)施DevOps的關(guān)鍵因素，通過(guò)在軟件交付的各個(gè)階段建立自動(dòng)化的保障體系可以使團(tuán)隊(duì)能夠盡早的發(fā)現(xiàn)和解決發(fā)現(xiàn)的缺陷。
對(duì)于度量驅(qū)動(dòng)的DevOps轉(zhuǎn)型，通過(guò)自動(dòng)化部署流水線有效提高軟件交付的效率，通過(guò)質(zhì)量?jī)?nèi)建確保軟件交付的質(zhì)量，通過(guò)對(duì)過(guò)程性數(shù)據(jù)的持續(xù)收集和分析發(fā)現(xiàn)交付過(guò)程中存在的瓶頸，通過(guò)對(duì)軟件產(chǎn)品和用戶的線上數(shù)據(jù)獲取反饋并且及時(shí)作出調(diào)整，通過(guò)結(jié)果性數(shù)據(jù)去評(píng)價(jià)團(tuán)隊(duì)的成效。
最后對(duì)于企業(yè)DevOps轉(zhuǎn)型而言：
Automation 自動(dòng)化是實(shí)施DevOps轉(zhuǎn)型的先決條件，自動(dòng)化一切可以自動(dòng)化的，降低部署和發(fā)布的難度。
Measure 通過(guò)建立有效的監(jiān)控與度量手段來(lái)獲得反饋，推動(dòng)產(chǎn)品和團(tuán)隊(duì)的持續(xù)改進(jìn)，支持業(yè)務(wù)決策。
Lean 協(xié)作文化，自動(dòng)化，和有效的反饋，這些實(shí)施是個(gè)長(zhǎng)期的過(guò)程，需要以精益的方式小步快跑，對(duì)過(guò)程與技術(shù)進(jìn)行持續(xù)改善。
Culture OKR目標(biāo)和關(guān)鍵成果驅(qū)動(dòng) 建立具有跨職能協(xié)作文化和共同目標(biāo)的一體化團(tuán)隊(duì)；這是DevOps運(yùn)動(dòng)的根本！
Sharing 不同職能、不同產(chǎn)品之間分享開(kāi)發(fā)和運(yùn)維過(guò)程中的想法，知識(shí)，問(wèn)題，以及失敗經(jīng)驗(yàn)，共同提升能力。
第三十六屆CIO班招生
國(guó)際CIO認(rèn)證培訓(xùn)
首席數(shù)據(jù)官（CDO）認(rèn)證培訓(xùn)
責(zé)編：content
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來(lái)自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請(qǐng)及時(shí)通知本站，予以刪除。
搶沙發(fā)
