丨配置管理最容易被忽視的devops工程實(shí)踐基礎(chǔ)

熟悉運(yùn)維的同學(xué)可能會(huì)說(shuō)，不就是類似Asile、altsack的環(huán)境配置管理工具嗎？還有人會(huì)說(shuō)，CMDB配置管理數(shù)據(jù)庫(kù)也是配置管理吧？這些說(shuō)法都沒(méi)錯(cuò)。配置管理這個(gè)概念在軟件開(kāi)發(fā)領(lǐng)域應(yīng)用得非常普遍，幾乎可以說(shuō)無(wú)處不在，但是剛剛提到的這些概念，都是細(xì)分領(lǐng)域內(nèi)的局部定義。我今天要講到的配置管理，是一個(gè)宏觀的概念，是站在軟件交付全生命周期的視角，對(duì)整個(gè)開(kāi)發(fā)過(guò)程進(jìn)行規(guī)范管理，控制變更過(guò)程，讓協(xié)作更加順暢，確保整個(gè)交付過(guò)程的完整、一致和可追溯?？吹竭@里，我估計(jì)你可能已經(jīng)暈掉了。的確，配置管理的非常龐大。但是沒(méi)關(guān)系，你只需要把四個(gè)理念記在心中就足夠了。這四個(gè)理念分別是：版本變更標(biāo)準(zhǔn)化，將一切納入版本控制，全流程可追溯和單一可信數(shù)據(jù)源。碼?，F(xiàn)在很多公司都在使用類似Git、SVN之類的工具管理源代碼，這些工具其實(shí)都是版現(xiàn)代軟件開(kāi)發(fā)越來(lái)越復(fù)雜，往往需要多人協(xié)作，所以，如何管理每個(gè)開(kāi)發(fā)者的版本，并把它們有效地集成到一起，就成了一個(gè)難題。實(shí)際上，版本控制系統(tǒng)就是為了解決這個(gè)問(wèn)題的。試想一下，如果沒(méi)有這么一套系統(tǒng)的話，所有代碼都在本地，不要說(shuō)其他人了，就連自己都會(huì)搞不清楚哪個(gè)是代碼。那么，當(dāng)所有人的代碼集成到一起的時(shí)候，那該是多么啊！不僅如此，如果線上發(fā)生了嚴(yán)重問(wèn)題，也找不到對(duì)應(yīng)的歷史版本，只能直接把的代碼發(fā)布上去，簡(jiǎn)直就是。配置管理中的另一個(gè)概念是變更。我們對(duì)軟件做的任何改變都可以稱之為一次變更，比如一個(gè)需求，一行代碼，甚至是一個(gè)環(huán)境配置。版本來(lái)源于變更。對(duì)于變更而言，就是比如，版本控制系統(tǒng)需要打通公司的統(tǒng)一認(rèn)證系統(tǒng)，也就是任何人想要版本控制系統(tǒng)，都需要經(jīng)過(guò)公司統(tǒng)一登錄的認(rèn)證。同時(shí)，在使用Git的時(shí)候，你需要正確配置本地信息，尤其是用戶名和郵箱信息，這樣才能在提交時(shí)生成完整的用戶信息。另外，系統(tǒng)本身也需要增加相關(guān)的校驗(yàn)機(jī)制，避免由于員工配置錯(cuò)誤導(dǎo)致無(wú)效信息被提交入庫(kù)。這些改動(dòng)應(yīng)該遵循一種標(biāo)準(zhǔn)化的格式，并且有相關(guān)的格式說(shuō)明和書(shū)寫方式，比哪些關(guān)鍵字，每一行的長(zhǎng)度，變更編號(hào)的區(qū)隔是使用逗號(hào)、空格還是分號(hào)等等。如果按照這個(gè)標(biāo)準(zhǔn)來(lái)書(shū)寫每次的變更記錄，其實(shí)成本還是很高的，更不要說(shuō)使用英文來(lái)書(shū)寫的話，英文的表達(dá)方式和內(nèi)容展現(xiàn)形式又是一個(gè)難題。我跟你一個(gè)的提交注釋，你可以參考一下switchtoFlask-XML-RPCdependencyCR:PBX-2222TheFlask-XML-RPC-ReforkhasPython3support,butithasaothertestsuitedoesnotlatestcodeisnotpiledsourcecodeisnotdistributedviaTheFlask-XML-RPCmoduleisessentiallydeadupstream,butitispackagedinEPEL7andFedora.ThismodulewillgetusfarenoughtopointthatwecancompletephaseoneforthisWhenwecareaboutPython3,wecandropXML-RPCentirelyandgettheserviceconsumerstoswitchtoaRESTAPIinstead.(Note,withthischange,theTravisCItestswillfailforPythonsolutionistodropXML-RPC這時(shí)，肯定有人會(huì)問(wèn)，花這么大力氣做這個(gè)事情，會(huì)不會(huì)有點(diǎn)得不償失呢？從局部來(lái)看，的確如此。但是，換個(gè)角度想，當(dāng)其他人看到你的改動(dòng)，或者是評(píng)審你的代碼的時(shí)候，如果通過(guò)提交記錄就能清晰地了解你的意圖，而不是一臉蒙地叫過(guò)來(lái)，讓你再講一遍，這樣節(jié)約的時(shí)間比當(dāng)時(shí)你書(shū)寫提交記錄的時(shí)間要多得多。當(dāng)然，如果標(biāo)準(zhǔn)化流程要完全依靠人的自覺(jué)性來(lái)保障，那就太不靠譜了。畢竟，人總是容易犯錯(cuò)的，會(huì)影響到標(biāo)準(zhǔn)的執(zhí)行效果。所以，當(dāng)團(tuán)隊(duì)內(nèi)部經(jīng)過(guò)不斷磨合，逐步形成一套規(guī)范之后，最好還是用自動(dòng)化的保障流程的標(biāo)準(zhǔn)化。這樣做的好處有兩點(diǎn)：一方面，可以降低人為因素的影響，如果你不按標(biāo)準(zhǔn)來(lái)，就會(huì)寸步難行，也減少了人為鉆空子的可能性。比如，有時(shí)候因?yàn)閼?，每次提交都寫同樣一個(gè)需求變更號(hào)，這樣的確滿足了標(biāo)準(zhǔn)化的要求，但是卻產(chǎn)生了大量無(wú)效數(shù)據(jù)。這時(shí)候，你就可以適當(dāng)增加一些校驗(yàn)機(jī)制，比如只允許添加你名下的變更，或者是只允許開(kāi)放狀態(tài)的變更號(hào)等等。另一方面，在標(biāo)準(zhǔn)化之后，很多重復(fù)性的工作就可以自動(dòng)化完成，標(biāo)準(zhǔn)化的信息也方便計(jì)算機(jī)分析提取，這樣就可以提升流程的流轉(zhuǎn)效率。可以說(shuō)，標(biāo)準(zhǔn)化是自動(dòng)化的前提，自動(dòng)化又是DevOps最的實(shí)踐。這樣看來(lái)，說(shuō)配置管理是DevOps工程實(shí)踐的基礎(chǔ)就一點(diǎn)不為過(guò)了吧。你：“一切都需要！”比如軟件源代碼、配置文件、測(cè)試編譯、流水線配置、環(huán)境配這是因?yàn)椋浖旧砭褪且粋€(gè)復(fù)雜的集合體，任何變更都可能帶來(lái)問(wèn)題，所以，全程版本控制賦予了我們?nèi)鞒套匪莸哪芰Γ⑶铱梢钥焖倩赝说侥硞€(gè)時(shí)間點(diǎn)的版本狀態(tài)，這對(duì)于定位和修復(fù)問(wèn)題是非常重要的。之前，我就遇到過(guò)一個(gè)問(wèn)題。一個(gè)iOS應(yīng)用發(fā)灰度版本的時(shí)候一切正常，但是正式版本就遇到了無(wú)法的情況。當(dāng)時(shí)因?yàn)樯暇€，為了查這個(gè)問(wèn)題，可以說(shuō)是全員上陣，團(tuán)隊(duì)甚納入版本控制的價(jià)值不止如此。實(shí)際上，很多DevOps實(shí)踐都是基于版本控制來(lái)實(shí)現(xiàn)的，比如，環(huán)境管理方面推薦采用基礎(chǔ)設(shè)施即代碼的方式管理環(huán)境，也就是說(shuō)把用代碼化的方式描述復(fù)雜的環(huán)境配置，同時(shí)把它納入版本控制系統(tǒng)中。這樣一來(lái)，任何環(huán)境變更都可以像提交代碼一樣來(lái)完成，不僅變更的內(nèi)容一目了然，還可以很輕松地實(shí)現(xiàn)自動(dòng)化。把原本復(fù)雜的事情簡(jiǎn)單化，每一個(gè)人都可以完成環(huán)境變更。這樣一來(lái)，開(kāi)發(fā)和運(yùn)維之間的鴻溝就被逐漸抹平了，DevOps不過(guò)，這里我需要澄清一下，納入版本控制并不等同于把所有內(nèi)容都放到Git中管理。有些時(shí)候，我們很容易把能力和工具混為一談。Git調(diào)的其實(shí)是一種能力，工具只是能力的載體。比如，Git這些大文件放到Artifactory或者其他自建平臺(tái)上進(jìn)行管理。對(duì)自建系統(tǒng)來(lái)說(shuō)，實(shí)現(xiàn)版本控制的方式有很多種，比如，可以針對(duì)每次變更，插入一組新的數(shù)據(jù)，或者直接復(fù)用Git這種比較成工具作為。唯一不變的要求就是，無(wú)論使用什么樣的系統(tǒng)和工具，都需要把版本控制的能力考慮進(jìn)去。另外，在實(shí)踐將一切納入版本控制的時(shí)候，你可以參考一條小原則。如果你不確定是否需要納入版本控制，有一個(gè)簡(jiǎn)單的判斷方法就是：如果這個(gè)產(chǎn)物可以通過(guò)其他產(chǎn)物來(lái)重現(xiàn)，那么就可以作為制品管理，而無(wú)需納入版本控制。舉個(gè)例子，軟件包可以通過(guò)源代碼和工具重新打包生成，那么，代碼、工具和打包環(huán)境就需要納入管控，而生成的軟件包可以作為制品；軟件的測(cè)試報(bào)告如果可以通過(guò)測(cè)試管理平臺(tái)重新自動(dòng)化生成，那么同樣可以將其視為制品，但前提是，測(cè)試管理平臺(tái)可以針對(duì)每一個(gè)版本重新生成測(cè)試報(bào)告。對(duì)傳統(tǒng)行業(yè)來(lái)說(shuō)，全流程可追溯的能力從來(lái)不是可選項(xiàng)，而是必選項(xiàng)。像航空航天、企業(yè)制造、金融行業(yè)等，對(duì)變更的管控都是非常嚴(yán)謹(jǐn)?shù)?，一旦出現(xiàn)問(wèn)題，就要追溯當(dāng)時(shí)的全部數(shù)據(jù)，像軟件源代碼、測(cè)試報(bào)告、運(yùn)行環(huán)境等等。如果由于缺乏管理，難以提供證明基于當(dāng)時(shí)的客觀情況已經(jīng)做了充分的驗(yàn)證，就會(huì)的罰款和賠償，這可不是鬧著玩的事情。像最近流行的技術(shù)，除了發(fā)幣以外，最典型的場(chǎng)景也是全流程可追溯。所以說(shuō)，技術(shù)可以日新月異，但很多理念都是長(zhǎng)久不變的。對(duì)于配置管理來(lái)說(shuō)，除了追溯能力以外，還有一個(gè)重要的價(jià)值，就是記錄關(guān)聯(lián)和依賴關(guān)系。怎么理解這句話呢？我先提個(gè)問(wèn)題，在你的公司里面，針對(duì)任意一個(gè)需求，是否能夠快速識(shí)別出它所關(guān)聯(lián)的代碼、版本、測(cè)試案例、上線記錄、缺陷信息、用戶反饋信息和上線監(jiān)控?cái)?shù)據(jù)呢？對(duì)于任意一個(gè)應(yīng)用，是否可以識(shí)別出它所依賴的環(huán)境，中間件，上下游存在調(diào)用關(guān)系的系統(tǒng)、服務(wù)和數(shù)據(jù)呢？如果你的回答是“yes”，那么恭喜你，公司做得非常好。不過(guò)，絕大多數(shù)公司都是無(wú)法做到這一點(diǎn)的。因?yàn)檫@不僅需要系統(tǒng)與系統(tǒng)之間的關(guān)聯(lián)打通、數(shù)據(jù)聯(lián)動(dòng)，也涉及到一整套完整的管理機(jī)制。DevOps非常強(qiáng)調(diào)價(jià)值導(dǎo)向，強(qiáng)調(diào)團(tuán)隊(duì)內(nèi)部共享目標(biāo)，這個(gè)目標(biāo)其實(shí)就是業(yè)務(wù)目標(biāo)。但實(shí)際情況是，業(yè)務(wù)所關(guān)注的維度，和開(kāi)發(fā)、測(cè)試、運(yùn)維所關(guān)注的維度都各不相同。業(yè)務(wù)關(guān)心的是需求有沒(méi)有上線，而開(kāi)發(fā)關(guān)心的是這個(gè)需求的代碼有沒(méi)有集成，運(yùn)維關(guān)心的是包含這個(gè)代碼的版本是否上線。所以，如果不能把這些信息串聯(lián)打通，就沒(méi)有真正做到全流程可追溯。關(guān)于這個(gè)問(wèn)題，我給你的建議是把握，建立主線。所謂，對(duì)于軟件開(kāi)發(fā)而言，最原始的就是需求，所有的變更都來(lái)源于需求。所以，首先要統(tǒng)一管理需求，無(wú)論是開(kāi)發(fā)需求、測(cè)試需求還是運(yùn)維需求。接下來(lái)，要以需求作為抓手，去關(guān)聯(lián)下游環(huán)節(jié)，打通數(shù)據(jù)，這需要系統(tǒng)能力的支持，也需要程，這樣既可以減少無(wú)意義的環(huán)節(jié)，給予團(tuán)隊(duì)一定的靈活性，也達(dá)到了全流程管控的目標(biāo)。這是一個(gè)比較漫長(zhǎng)的過(guò)程，但不積跬步，無(wú)以至千里，DevOps也需要一步一個(gè)腳印地有一個(gè)網(wǎng)絡(luò)熱詞叫作“官宣”，也就是宣布的意思。一般情況下，官宣的信息都是板上釘釘?shù)模尚哦确浅８?。可?wèn)題是，如果有多個(gè)官宣的，信息還都不一樣，你怎么知道要相信哪一個(gè)呢？這就是單一可信數(shù)據(jù)源的意義。同時(shí)，單一可信數(shù)據(jù)源也要能覆蓋企業(yè)內(nèi)部元數(shù)據(jù)的管控。比如，企業(yè)內(nèi)部經(jīng)常出現(xiàn)這種情況，同樣是應(yīng)用，在A部門的系統(tǒng)中叫作123，在B部門的系統(tǒng)中叫作ABC，在打通兩邊平臺(tái)的時(shí)候，這就相當(dāng)于“雞同鴨講”，完全對(duì)不上。再比如，團(tuán)隊(duì)了一套應(yīng)用列表，但實(shí)際上，在業(yè)務(wù)系統(tǒng)中，很多應(yīng)用都已經(jīng)下線且不再了，這樣一來(lái)，不僅會(huì)今天我給你介紹了DevOps工程實(shí)踐的基礎(chǔ)配置管理，以及配置管理的四大理念，分別是雖然配置管理看起來(lái)并不起眼，但是就像那句經(jīng)典的話一樣：“歲月靜好，是因?yàn)橛腥颂婺阖?fù)重前行?！睂?duì)于任何一家企業(yè)來(lái)說(shuō)，信息過(guò)載都是常態(tài)，而配置管理的最大價(jià)值正是將信息序列化