9000億投資浪費在數(shù)字化轉(zhuǎn)型，罪魁禍首在DevOps？

pselx2="568" data-cropsely1="0" data-cropsely2="62" data-ratio="0.6" data-w="800" style="width: 568px;height: 341px;" src="/images/21ic_nopic.gif" data-src="66a4UeozZ/nCMVuZYvgK55qgfwSEoLFCCsZZYJuYGdKFmjPSg5TRSYo9CIQeE9Rdpt87zOjet6TCgRHfta9ku5b1dpTmjQvWeohM" class="delay_img" alt="9000億投資浪費在數(shù)字化轉(zhuǎn)型，罪魁禍首在DevOps？" >

來自：DBAplus社群

作者介紹

• 數(shù)字化轉(zhuǎn)型：Digital Transformation (DT)；

• 開發(fā)運維一體化：DevOps；

• 云計算：Cloud Computing，常見的公有云有Amazon Cloud Service(AWS)、Microsoft Azure Cloud、Google Cloud Platform(GCP)、阿里云(Alibaba Cloud)、騰訊云(Tencent Cloud)， 以及華為云(Huawei Cloud)；

• 測試驅(qū)動開發(fā)：Test-driven Development, 是一種開發(fā)面向測試用例的軟件開發(fā)模式和流程。

數(shù)字化轉(zhuǎn)型(digital transformation)乃至云化已經(jīng)從互聯(lián)網(wǎng)行業(yè)，滲透到了各個傳統(tǒng)行業(yè)，乃至于借助云計算，大數(shù)據(jù)隱隱然已經(jīng)成為了企業(yè)面向未來十年的必然選擇。 

在哈佛商業(yè)評論所作的一項針對企業(yè)業(yè)務(wù)高管的調(diào)查中顯示，企業(yè)普遍認為在2019年中數(shù)字化轉(zhuǎn)型是企業(yè)的第一要務(wù)，但是超過70%的轉(zhuǎn)型并沒有達到企業(yè)的預(yù)期，并且超過9000億美金的投資被浪費掉了。

這樣的浪費有很多原因，但不乏是由于傳統(tǒng)行業(yè)對于軟件開發(fā)、部署、發(fā)布、迭代以及運維的了解有限，因而本文面向傳統(tǒng)企業(yè)轉(zhuǎn)型中的困難和疑問，通過推進組織的DevOps轉(zhuǎn)型作為抓手來嘗試提供一份數(shù)字化轉(zhuǎn)型指南，以資參考。

數(shù)字化轉(zhuǎn)型是使用云計算、大數(shù)據(jù)，以及其他信息技術(shù)對企業(yè)的運營、組織架構(gòu)和商業(yè)模式進行改造的過程，以提高企業(yè)相應(yīng)客戶需求的速度，增強企業(yè)與客戶的聯(lián)系。數(shù)字化轉(zhuǎn)型不僅僅是技術(shù)轉(zhuǎn)型，更需要從商業(yè)戰(zhàn)略、組織架構(gòu)、文化、客戶關(guān)系等多維角度來確定企業(yè)的轉(zhuǎn)型策略和目標。

這些維度和開發(fā)運營一體化(DevOps)變革和敏捷運動有眾多重疊的領(lǐng)域。因而，我們可以使用DevOps作為抓手，在確定商業(yè)目標的同時，減少數(shù)字化轉(zhuǎn)型中的成本，通過DevOps的成熟度指標，來關(guān)聯(lián)和量化數(shù)字化轉(zhuǎn)型的成果。缺乏量化性的指標，就無法管理數(shù)字化轉(zhuǎn)型的過程，也是造成大量投資浪費的原因之一。

開發(fā)運營一體化(DevOps)是對于企業(yè)內(nèi)部開發(fā)和運營的整合的方法論、工具和指標。衡量一個組織的DevOps成熟度，需要從技術(shù)、流程、度量和文化四個維度來進行評價。根據(jù)當(dāng)前主流業(yè)界的標準，DORA(DevOps Research and Assessment) DevOps成熟度模型、軟件交付表現(xiàn)SDP(Software Delivery Performance)包含了下面這些指標，包括前置時間(Lead Time)、變更失敗(Change Fail)、可靠性(Availability)，以及部署頻率(Deployment Frequency)和恢復(fù)時間(Time to Restore)。

微軟公司，作為操作系統(tǒng)和辦公軟件的業(yè)界翹楚，也同樣面臨著數(shù)字化轉(zhuǎn)型的壓力。但是不同于其他企業(yè)，微軟有深厚的工程師文化，強大的IT技術(shù)儲備。他們面臨的問題是如何將基于授權(quán)(license)的商業(yè)模式轉(zhuǎn)型為以訂閱(subscribe)為基礎(chǔ)的訂閱服務(wù)上。例如傳統(tǒng)的單機密鑰授權(quán)轉(zhuǎn)換為云化的office 365訂閱服務(wù)。

在這期間，微軟著重推行了敏捷開發(fā)模式并且是office業(yè)務(wù)上云，同時將其傳統(tǒng)的基于私有數(shù)據(jù)中心的Team Foundation Server改造成為基于微軟云業(yè)務(wù)的Microsoft Azure DevOps。這成為了微軟內(nèi)部的運營開發(fā)一體化的轉(zhuǎn)型抓手和重要推動引擎。

依據(jù)DORA(DevOps Research and Accessment)超過六年對業(yè)界技術(shù)能力(Technical)、流程(Process)、度量(Measurement)和文化(Cultrue)四個維度的連續(xù)研究和評估，我們同樣可以從這四方面進行建設(shè)。

版本控制跟自動化緊密相關(guān)。事實上，建設(shè)持續(xù)集成和持續(xù)交付能力的建立在成熟的版本控制流程和工具的基礎(chǔ)之上。很多企業(yè)在建立版本控制的時候，更多關(guān)注的是代碼，而忽略了代碼之外的配套流程和制品，例如測試用例、自動化測試腳本、測試數(shù)據(jù)、基礎(chǔ)設(shè)施和數(shù)據(jù)庫。我們在建立版本控制的時候，需要實現(xiàn)基礎(chǔ)設(shè)施即代碼、配置即代碼、數(shù)據(jù)即代碼，以及測試即代碼。版本控制可以幫助企業(yè)滿足以下兩個最關(guān)鍵的需求，即：

1）可復(fù)制性(Reproducibility)

可復(fù)制性是保障我們的開發(fā)、測試，以及生產(chǎn)環(huán)境的可復(fù)制性。能夠快速通過自動化的手段實現(xiàn)環(huán)境的復(fù)制和重建，進而保證環(huán)境的一致性。

2）可追蹤性(Traceability)

可追蹤性的目的是為了保證團隊可以在任何時間都可以利用版本重建環(huán)境，并且可以比較兩套環(huán)境的區(qū)別。

業(yè)界有兩種常見的軟件開發(fā)模式，即功能分支模式(Feature Branch Based Development)和主干開發(fā)模式(Trunk-based Developoment)。

1）功能分支模式

功能分支模式是指開發(fā)人員從主干分支(Master分支)拉取代碼來開始開發(fā)，直到開發(fā)人員認為代碼開發(fā)結(jié)束，即從不可部署階段到可部署階段。如上圖所示，即從淺灰色變?yōu)樯罨疑?，才將代碼重新合并到主分支。

這種模式有兩個主要問題。第一，每一次發(fā)布都伴隨著大量的代碼合并，并且會引起代碼沖突。原因是每次分支合并的代碼量過大；第二，需要手工維護代碼的合并，因為代碼不僅僅是合并到主干，還需要人工判斷是否需要合并到其他功能分支上。一般的邏輯是如果另一個功能分支的發(fā)布時間晚于當(dāng)前要合并的分支，并且后面的發(fā)布需要當(dāng)前分支的功能或問題修復(fù)，即需要合并，即所謂的向后合并。向后合并可以采用自動化合并的模式來實現(xiàn)，例如可以依賴于Jenkins來實現(xiàn)自動向后合并。由于每次合并代碼都需要完整的測試，所以需要代碼鎖定(Code Freeze)，以確保代碼的穩(wěn)定性。

2）主干開發(fā)模式

不同于功能分支模式，主干開發(fā)模式是實現(xiàn)持續(xù)集成的必要條件。開發(fā)人員只有在代碼準備發(fā)布的時候，才會拉出發(fā)布分支，所以發(fā)布分支一直是可部署的狀態(tài)。而在功能分支模式下，功能分支不一定是可部署狀態(tài)。開發(fā)人員每天都會把當(dāng)下代碼簽入主干，但是要求開發(fā)人員如果自己簽入的新代碼引起了任何問題，必須立即修復(fù)，否則會阻塞其他開發(fā)人員簽入代碼。因為每次簽入的代碼量比較少，所以出現(xiàn)代碼沖突的可能性就會大幅度降低。同時，主干代碼因為繼承了回歸測試的自動化，任何破壞回歸功能的代碼都會被立刻修復(fù)，也維護了代碼質(zhì)量。主干開發(fā)模式不需要鎖定代碼或者其他手段來保證代碼穩(wěn)定性。

實現(xiàn)主干開發(fā)模式的要點：

開發(fā)人員經(jīng)常誤認為開發(fā)運營一體化(DevOps)就是討論開發(fā)和運維，即Development和Operation，其實這是一個望文生義的一種誤解。在推進DevOps轉(zhuǎn)型中，很多企業(yè)和團隊經(jīng)常忽略了自動化測試這一個關(guān)鍵的因素。沒有完善的測試驅(qū)動開發(fā)流程，沒有完善的回歸測試自動化，持續(xù)集成就是空談。

上圖是測試驅(qū)動開發(fā)TDD的流程示意。新的功能在拿到需求之后，測試人員和開發(fā)人員都需要被通知。所有的開發(fā)都是基于對測試用例的實現(xiàn)。首先增加新的測試用例，并且運行自動化測試。此時，由于代碼還沒有開發(fā)，測試一定會失敗。這么做的原因是讓開發(fā)和測試人員明確在代碼開發(fā)之前新增加的測試用例是失敗的，從而避免測試用例的錯誤而造成測試用例錯誤通過的問題。開發(fā)人員根據(jù)測試來進行功能開發(fā)，直到所有測試用例通過。當(dāng)測試用例通過之后，開發(fā)人員進行代碼的重構(gòu)來進行代碼優(yōu)化，以實現(xiàn)安全性和性能的要求。在簽入代碼到主干的時候，如果發(fā)現(xiàn)自動化回歸測試失敗，測試人員需要更新自動化回歸測試確?；貧w測試是最新狀態(tài)。

實現(xiàn)TDD的要點：

自動化測試給開發(fā)人員提供了一種快速反饋的機制。自動化測試是保證持續(xù)集成的基礎(chǔ)條件。自動化測試包括下面兩種測試種類：

1）單元測試(Unit Test)

單元測試是TDD流程中經(jīng)常使用的針對單個函數(shù)、類或者方法，來保證開發(fā)人員的代碼按照預(yù)期的測試方法。單元測試的開發(fā)早于業(yè)務(wù)代碼，流程在上一節(jié)介紹TDD的內(nèi)容中已經(jīng)提及。 

2）驗收測試(Acceptance Tests)

驗收測試是針對程序或這API進行功能上的測試，本身也是開發(fā)工作的一部分。開發(fā)人員在沒有通過驗收測試之前是不能夠認為開發(fā)工作已經(jīng)完成。

上圖從四個角度分析了自動化測試的使用。

從業(yè)務(wù)角度來看，驗收測試和手工探索性測試都是針對業(yè)務(wù)功能進行的，來保證業(yè)務(wù)流的順利進行。一般手工測試在代碼上生產(chǎn)環(huán)境之前進行，有些團隊稱之為PVT(Product Validation Testing)，即產(chǎn)品驗證測試，對應(yīng)的測試人員一般都是業(yè)務(wù)專家。

從開發(fā)支持的角度來看，單元測試和自動化驗收測試是實現(xiàn)CICD和TDD的關(guān)鍵。

以上為一個完整的CICD從開發(fā)到發(fā)布的流程。在commit stage中，經(jīng)常會進行代碼掃描和單元測試。如果單元測試或者代碼掃描未通過，開發(fā)人員可以獲得快速反饋，并根據(jù)需要重新修改代碼。這個地方可以實現(xiàn)問題的左移, 即代碼風(fēng)格問題左移和安全性左移。

在自動化驗收測試時，如果測試未通過，有兩種可能性。第一是業(yè)務(wù)代碼有問題，第二為驗收測試代碼需要調(diào)整。這個反饋應(yīng)該發(fā)送給對應(yīng)的測試團隊和開發(fā)團隊。

3）自動化測試金字塔(Automation Testing Pyramid)

根據(jù)自動化測試金字塔模型，盡可能多的問題應(yīng)該被自動化單元測試發(fā)現(xiàn)，這樣可以降低測試成本，開發(fā)人員可以盡早獲得反饋以修改代碼。驗收測試的作者和維護者，應(yīng)該盡可能是開發(fā)人員，這一點經(jīng)常被很多企業(yè)和團隊所忽略。

測試數(shù)據(jù)管理是很多團隊和企業(yè)在做DevOps轉(zhuǎn)型中容易忽略的領(lǐng)域。測試數(shù)據(jù)是保證測試能夠正常進行的基礎(chǔ)。沒有良好的測試數(shù)據(jù)管理，會提告測試缺陷的誤報率，降低團隊的信息，忽略真正的嚴重產(chǎn)品缺陷。

測試數(shù)據(jù)管理必須要保證自動化測試能夠順利進行。針對不同的環(huán)境，例如測試環(huán)境、預(yù)生產(chǎn)環(huán)境、測試數(shù)據(jù)必須能夠區(qū)別管理，因為不同環(huán)境的測試數(shù)據(jù)有可能會有不同。

測試數(shù)據(jù)管理應(yīng)該能夠自動的在環(huán)境設(shè)置完成之后，配置測試環(huán)境，以便開展自動化測試。在測試完成之后，能夠自動清理數(shù)據(jù)，并且恢復(fù)環(huán)境至測試開始之前。

測試數(shù)據(jù)管理必須要能夠根據(jù)代碼開發(fā)更新，確保數(shù)據(jù)的實時性。

本文主要從技術(shù)的角度探討DevOps如何助力企業(yè)數(shù)字化轉(zhuǎn)型，后續(xù)將陸續(xù)推出包括DevOps流程、指標、文化和組織角度的解讀，敬請持續(xù)關(guān)注。

• 《哈佛商業(yè)評論 - 數(shù)字化轉(zhuǎn)型并不僅僅是技術(shù)》

  https://hbr.org/2019/03/digital-transformation-is-not-about-technology

• 《State of DevOps Report by puppet》

  https://www.thinkahead.com/wp-content/uploads/2018/10/State-of-DevOps-Report.pdf

• 《Five Foundational DevOps Practices by Splunk》

  https://www.splunk.com/pdfs/ebooks/5-foundational-devops-practices.pdf

• 《Google DevOps Research》

  https://cloud.google.com/devops

• 《DORA State 2018》

  https://cloudplatformonline.com/rs/248-TPC-286/images/DORA-State%20of%20DevOps.pdf

• 《測試驅(qū)動開發(fā)(TDD)》

  https://en.wikipedia.org/wiki/Test-driven_development