開(kāi)門(mén)見(jiàn)山：從實(shí)踐入手，配合工具的使用，以解決具體的問(wèn)題為出發(fā)點(diǎn)。由實(shí)踐的組合使用，倒推流程與組織文化的升級(jí)。
很多團(tuán)隊(duì)都會(huì)遇到這個(gè)問(wèn)題：DevOps 所倡導(dǎo)的理念、文化、實(shí)踐都挺好的，但是不知道應(yīng)該怎么入手，總覺(jué)得這么系統(tǒng)化的方法論和體系只能從上到下的推進(jìn)。造成大家困惑的原因有以下幾點(diǎn)：
在組織或者團(tuán)隊(duì)內(nèi)部貿(mào)然引入 DevOps 面臨的阻力和風(fēng)險(xiǎn)很大，需要在短期內(nèi)有明顯的效果來(lái)背書(shū)
最容易也最體現(xiàn)效果的是從（最佳）實(shí)踐入手，每個(gè)實(shí)踐都是可以單獨(dú)應(yīng)用的，為了解決某個(gè)具體的問(wèn)題，使用成本低，很多時(shí)候在團(tuán)隊(duì)內(nèi)即可完成，比如自動(dòng)化部署，測(cè)試團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)都能自己?jiǎn)为?dú)做。
無(wú)論你是研發(fā)、測(cè)試還是運(yùn)維，都建議你從持續(xù)集成開(kāi)始，按照《持續(xù)集成：軟件質(zhì)量改進(jìn)和風(fēng)險(xiǎn)降低之道》一書(shū)的描述，持續(xù)集成要包括版本控制、自動(dòng)化構(gòu)建、代碼質(zhì)量、自動(dòng)化測(cè)試等等。
但是大多數(shù)時(shí)候，我們都將持續(xù)集成和自動(dòng)化測(cè)試分開(kāi)說(shuō)，大多數(shù)時(shí)候，這兩個(gè)實(shí)踐屬于不同的部門(mén)。有一句忠告：“沒(méi)有持續(xù)集成和自動(dòng)化測(cè)試，敏捷就是災(zāi)難。”
版本化一切是 DevOps 提倡的，包括源代碼、依賴(lài)、制品配置、環(huán)境配置、應(yīng)用配置、數(shù)據(jù)配置等等。版本控制將團(tuán)隊(duì)的協(xié)作拉到了同一水平線(xiàn)。
關(guān)于需求等文檔的，傳統(tǒng)的情況下都是以二進(jìn)制的方式存儲(chǔ)到版本控制系統(tǒng)中。使用 Confluence 管理需求版本也是不錯(cuò)的選擇，另外，如果是技術(shù)文檔，強(qiáng)烈推薦使用Markdown（互聯(lián)網(wǎng)之子的杰作）管理文檔，Gitlab等系統(tǒng)都是可以直接在線(xiàn)閱讀Markdown的。別問(wèn)為什么，因?yàn)橛斜聘瘛?/div>
強(qiáng)烈反饋將依賴(lài)的二進(jìn)制文件放到版本控制系統(tǒng)中（Gitlab、Github都提供大文件存儲(chǔ)方案）
制品文件可以采用 Nexus 和 Artifactory 或者是FTP來(lái)管理，但是需要有SNAPSHOT, Staging, Release 的分層
Infrastructure as Code 是一個(gè)很好的實(shí)踐
UCM（統(tǒng)一變更管理）依然是可以堅(jiān)持的實(shí)踐
特性開(kāi)關(guān)往往和分支策略相輔相成，怕管亂了還是不要用
1.2 自動(dòng)化構(gòu)建
標(biāo)準(zhǔn)化是自動(dòng)化的前提，首先要做到將代碼結(jié)構(gòu)標(biāo)準(zhǔn)，類(lèi)似 Maven 提倡的CoC（Convention Over Configuration）
另外，不建議某幾個(gè)人寫(xiě)依賴(lài)和編譯腳本，一定要讓工程師自己動(dòng)手
自動(dòng)化構(gòu)建的目標(biāo)是編譯過(guò)程完全自動(dòng)化，不能存在工程師手動(dòng)出版本包，出補(bǔ)丁用于發(fā)布的情況。
注：構(gòu)建本身涵蓋編譯、代碼掃描、單元測(cè)試等，此處理解為編譯即可。
1.3 自動(dòng)化測(cè)試
首先需要了解測(cè)試金字塔
自動(dòng)化測(cè)試需要專(zhuān)業(yè)的測(cè)試團(tuán)隊(duì)去推進(jìn)，相信很多團(tuán)隊(duì)都在這么做，但是本著誰(shuí)寫(xiě)的代碼誰(shuí)測(cè)試的原則，工程師要盡量寫(xiě)單元測(cè)試，對(duì)單元測(cè)試的覆蓋率提升應(yīng)該作為團(tuán)隊(duì)的整體目標(biāo)。
1.4 代碼掃描
代碼掃描（靜態(tài)和動(dòng)態(tài)）關(guān)注的是代碼質(zhì)量，代碼的質(zhì)量直接影響產(chǎn)品的質(zhì)量。
首先需要了解技術(shù)債務(wù)，“出來(lái)混遲早都是要還的”，這句話(huà)要謹(jǐn)記，攜程 CTO 葉亞明在總結(jié)“合格 CTO 的六要素”時(shí)，第1條是技術(shù)問(wèn)題的解決能力，第2條就是具備強(qiáng)烈的“還債”意識(shí)。
其次需要了解代碼七宗罪：不均勻分布的復(fù)雜性、重復(fù)代碼、不合適的注釋、違反代碼規(guī)范、缺乏單元測(cè)試、缺陷和潛在的缺陷
代碼掃描是度量技術(shù)債務(wù)的有效方式，代碼掃描的結(jié)果也應(yīng)該作為 Code Review 的科學(xué)依據(jù)。
管理技術(shù)債務(wù)的一般步驟：
定義代碼質(zhì)量標(biāo)準(zhǔn)（需要團(tuán)隊(duì)達(dá)成一致，簽字畫(huà)押都不為過(guò)）
可視化技術(shù)債務(wù)（度量）
償還技術(shù)債務(wù)（每個(gè)迭代都可以安排少量任務(wù)償還技術(shù)債務(wù)，相信我，沒(méi)有所謂的相對(duì)空閑的迭代，互聯(lián)網(wǎng)時(shí)代，怎么可能有工作做完的時(shí)候呢，所以要在每個(gè)迭代盡量?jī)斶€技術(shù)債務(wù)）
設(shè)置質(zhì)量門(mén)（債務(wù)只許少不許多）
如果你有興趣，可以將團(tuán)隊(duì)的代碼質(zhì)量先用SonarQube等工具量化出來(lái)，讓大家看看，大家就知道問(wèn)題的嚴(yán)重性了
1.5 Code Review
Code Review 屬于開(kāi)發(fā)技術(shù)領(lǐng)域，重點(diǎn)強(qiáng)調(diào)：Code Review 一定要做，小批量的做，不要一個(gè)月，幾個(gè)月來(lái)一次代碼審查（強(qiáng)烈鄙視審查這個(gè)詞）會(huì)議。Code Review是代碼共享文化和團(tuán)隊(duì)成員相互學(xué)習(xí)成長(zhǎng)的重要實(shí)踐。代碼時(shí)團(tuán)隊(duì)的，需要大家一起Review，幫助改進(jìn)，共同學(xué)習(xí)。
1.6 自動(dòng)化部署
關(guān)于自動(dòng)化，我的理解是復(fù)雜的事務(wù)和重復(fù)的事務(wù)都應(yīng)該自動(dòng)化。部署屬于既復(fù)雜又重復(fù)的工作，面對(duì)復(fù)雜的分布式架構(gòu)，手工顯然不靠譜。
采用工具自動(dòng)化部署過(guò)程
將測(cè)試環(huán)境的部署工作開(kāi)放給測(cè)試團(tuán)隊(duì)
采用 Infrastructure as Code、虛擬化技術(shù)、容器化技術(shù)來(lái)定義部署環(huán)境
采用全量部署
金絲雀發(fā)布、藍(lán)綠部署
1.7 持續(xù)反饋
持續(xù)地將自動(dòng)化構(gòu)建、代碼掃描、Code Review、自動(dòng)化測(cè)試、自動(dòng)化部署納入到持續(xù)交付流水線(xiàn)，持續(xù)地做，甚至每次提交都進(jìn)行構(gòu)建、掃描、測(cè)試、部署。提交即構(gòu)建，Merge 即構(gòu)建，提交即部署，這寫(xiě)對(duì)自動(dòng)化能力考驗(yàn)很高，慢慢來(lái)。
但是持續(xù)測(cè)試和持續(xù)部署不僅僅是將自動(dòng)化持續(xù)的做。業(yè)界通常的理解，持續(xù)部署和持續(xù)交付是對(duì)等的，持續(xù)部署將每次提交都進(jìn)行部署，持續(xù)交付是由業(yè)務(wù)決定部署內(nèi)容。Etsy 就是持續(xù)部署模式，每個(gè)新入職的工程師，第一天就是要向生產(chǎn)環(huán)境推送一個(gè)變更。
此處重點(diǎn)是要給大家強(qiáng)調(diào)持續(xù)的理念。
1.8 自動(dòng)化運(yùn)維
在我們的理解中，DevOps 重點(diǎn)關(guān)注的領(lǐng)域：持續(xù)交付+技術(shù)運(yùn)營(yíng)。技術(shù)運(yùn)營(yíng)的實(shí)踐很多（參考SRE）。持續(xù)交付和技術(shù)運(yùn)營(yíng)的有很多實(shí)踐是重疊的。技術(shù)運(yùn)營(yíng)也關(guān)注發(fā)布工程、測(cè)試，但是角度不同。
對(duì)技術(shù)運(yùn)營(yíng)的實(shí)踐嘗試的不多，整理一些我了解的：
關(guān)于規(guī)范，可以參考老王之前共享的運(yùn)維規(guī)范和開(kāi)放運(yùn)維聯(lián)盟的《互聯(lián)網(wǎng)應(yīng)用運(yùn)維標(biāo)準(zhǔn)框架》
監(jiān)控（黑盒+白盒）
事故處理流程、事故分析與故障庫(kù)
容量規(guī)劃
除了這些在工程領(lǐng)域常見(jiàn)的實(shí)踐，還有云原生應(yīng)用（12-Factors、Serverless）、微服務(wù)、不可變基礎(chǔ)設(shè)施、Feature Team、Kanban 等等。
實(shí)踐大都需要工具來(lái)承載，關(guān)于工具選型，建議選擇最熟悉的，可以參考 Xebialab 的 DevOps 工具周期表。
實(shí)踐不僅僅局限于工程領(lǐng)域，大家可以參考 Gartner 的報(bào)告：
無(wú)論組織和文化多么虛幻，我都還是想強(qiáng)調(diào)，組織文化對(duì) DevOps 至關(guān)重要。在嘗試 DevOps 實(shí)踐時(shí)別忘了關(guān)注文化
2、DevOps 組織文化
DevOps 的本質(zhì)是文化，是要打造團(tuán)隊(duì)持續(xù)試驗(yàn)和學(xué)習(xí)的文化。DevOps 的理論基礎(chǔ)是精益，精益的核心是消除浪費(fèi)、創(chuàng)造價(jià)值。
“在信息豐富的世界里，唯一稀缺的資源就是人類(lèi)的注意力”（—Herbert Simon），如果我們規(guī)劃、開(kāi)發(fā)、測(cè)試、發(fā)布的軟件產(chǎn)品或者服務(wù)沒(méi)人用，沒(méi)人喜歡，這才是最大的浪費(fèi)。
DevOps 要教會(huì)我們的是如何讓團(tuán)隊(duì)去持續(xù)地專(zhuān)注于創(chuàng)造更有價(jià)值的產(chǎn)品和服務(wù)給用戶(hù)。
文化轉(zhuǎn)變以信任為基礎(chǔ)，從幫助他人開(kāi)始。
不用刻意的去打造某種文化，只需要團(tuán)隊(duì)與團(tuán)隊(duì)之間，團(tuán)隊(duì)成員之間的相互信任，主動(dòng)幫助他人，自然會(huì)形成DevOps的核心文化：Shared Responsibility (責(zé)任共擔(dān))，在此基礎(chǔ)上，自動(dòng)化、內(nèi)建質(zhì)量、反饋的文化才有可能逐漸形成。
所以很多時(shí)候，我們強(qiáng)調(diào) DevOps 反對(duì)責(zé)備，責(zé)備對(duì)團(tuán)隊(duì)的破壞性非常大。培養(yǎng) Blameless 的文化時(shí)可以在事故處理實(shí)踐中，事故分析報(bào)告不責(zé)備個(gè)人或團(tuán)隊(duì)錯(cuò)誤，相互推卸責(zé)任。交付穩(wěn)定的高價(jià)值的服務(wù)給用戶(hù)是整個(gè)團(tuán)隊(duì)的責(zé)任。
2.1 公司內(nèi)部松散的 DevOps 社區(qū)
關(guān)于在組織或團(tuán)隊(duì)內(nèi)部培養(yǎng) DevOps 文化，可以嘗試組建內(nèi)部松散的 DevOps 小組（圈子，社區(qū)）并和外部的 DevOps 社區(qū)形成聯(lián)系。內(nèi)部DevOps小組可以將跨職能，跨團(tuán)隊(duì)的同事都圈在一起，大家可以互相借鑒好的做法，互相幫助解決問(wèn)題。
和外部 DevOps 社區(qū)的聯(lián)系，比如邀請(qǐng)外部社區(qū)大牛加入內(nèi)部圈子，大家相互成長(zhǎng)。這樣對(duì)引入外部的優(yōu)秀理念和實(shí)踐及工具，培養(yǎng)內(nèi)部松散協(xié)作，互相幫助的文化是很有幫助的。
尤其是當(dāng)你的所在的團(tuán)隊(duì)還有很多人不了解 DevOps 的時(shí)候，內(nèi)部圈子作用明顯。
2.2 The Satir Change Model
這是人們抗拒變革的曲線(xiàn)模型：1.初期階段 2.抵抗階段 3. 混亂階段 4. 整合階段 5. 新階段。
階段 描述 怎么做能更快更有效的變革
1 初期階段 鼓勵(lì)人們從組織外部尋找改進(jìn)方法和理念
2 抵抗階段 幫助人們保持開(kāi)放的心態(tài)，克服否定、逃避、指責(zé)的反應(yīng)
3 混亂階段 幫助人們建立一個(gè)安全的環(huán)境，使人們能夠?qū)Ｗ⒂谒麄兊母惺?，承認(rèn)恐懼，并使用他們的支持系統(tǒng)， 避免任何試圖用神奇的解決方案短路這個(gè)階段的行為
4 整合階段 提供保證，并幫助找到應(yīng)對(duì)困難的新方法。
5 新階段 幫助人們重新感受到安全以便人們可以去嘗試實(shí)踐
任何的變革都會(huì)引發(fā)阻力，這是必然。我們不能因?yàn)榇蠹叶疾蛔?，不支持，就不做正確的事。我們做 DevOps 需要一點(diǎn)一點(diǎ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ā)
