1）背景訴求
現(xiàn)網(wǎng)發(fā)布變更對(duì)運(yùn)維開(kāi)發(fā)工程師來(lái)說(shuō)是最繁重的工作。發(fā)布變更的概念、節(jié)奏等已經(jīng)是老生常談。但在ToB時(shí)代到來(lái)后，云上業(yè)務(wù)的訴求是功能/缺陷修復(fù)盡快上線(xiàn)、版本發(fā)出問(wèn)題快速回退，防止客戶(hù)業(yè)務(wù)受損。在整個(gè)需求上線(xiàn)環(huán)節(jié)中，CD部分由運(yùn)維實(shí)施。如何讓版本更快的交付上線(xiàn)是核心任務(wù)。2）對(duì)象存儲(chǔ)COS
【資料圖】
歷史的存儲(chǔ)引擎(TFS、LAVADB等)在變更中需要小set內(nèi)串行，或?qū)?shù)據(jù)遷走然后變更。這類(lèi)變更耗時(shí)是顯而易見(jiàn)的（從耗時(shí)過(guò)長(zhǎng)會(huì)引發(fā)意想不到的變更方式：按照版本組合來(lái)變更，按照各區(qū)域版本自治完全沒(méi)有統(tǒng)一概念等）。這類(lèi)型的變更最多做到流程標(biāo)準(zhǔn)化。它可以set之間并發(fā)或批量遷走數(shù)據(jù)再變更，但解決不了本質(zhì)問(wèn)題。
YottaStore相比傳統(tǒng)TFS模式或LAVADB模式而言，好在將小set模式的變更方式升級(jí)為集群百分比變更，打破理解set變更的模式，每個(gè)節(jié)點(diǎn)剔除加回也不需要等待數(shù)據(jù)遷移。這本質(zhì)上提高了存儲(chǔ)變更效率上限。
COS關(guān)鍵提效手段1）管理區(qū)域MZ適配發(fā)布YottaStore在上線(xiàn)的時(shí)候就對(duì)節(jié)點(diǎn)標(biāo)簽引入了MZ（Management Zone）的概念：同集群內(nèi)跨MZ不能同時(shí)變更，減小誤操作爆炸半徑。例如，模塊上線(xiàn)后使用20個(gè)MZ，跨MZ屏蔽節(jié)點(diǎn)會(huì)失?。ūＵ犀F(xiàn)網(wǎng)最大5%的機(jī)器可以并發(fā)變更）。當(dāng)然，在更核心服務(wù)配置時(shí)MZ應(yīng)該設(shè)置的更多。優(yōu)化前，基于MZ的概念變更節(jié)奏為：?jiǎn)螜C(jī)灰度：隨機(jī)一個(gè)MZ變更1臺(tái)；灰度：所有MZ隨機(jī)變更1臺(tái)；全量：MZ內(nèi)全量并發(fā)，MZ之間串行，并且開(kāi)始時(shí)智研平臺(tái)并發(fā)度受限在100以?xún)?nèi)。
優(yōu)化后：考慮集群內(nèi)節(jié)點(diǎn)同服務(wù)角色，將灰度節(jié)奏調(diào)整為隨機(jī)一個(gè)MZ全量，減少跨MZ帶來(lái)的耗時(shí)，同時(shí)智研平臺(tái)支持將最大并發(fā)調(diào)整為500+（單集群節(jié)點(diǎn)數(shù)/mz數(shù)量目前小于500，故相當(dāng)于實(shí)現(xiàn)了MZ內(nèi)全量并發(fā)）。
基于區(qū)域MZ適配發(fā)布優(yōu)化的策略，主要是通過(guò)COS對(duì)MZ編排做了適配，同時(shí)智研平臺(tái)把并發(fā)度支持從100并發(fā)調(diào)整到500并發(fā)，對(duì)于單機(jī)模板執(zhí)行效率也做了優(yōu)化。這整體優(yōu)化了平臺(tái)并發(fā)能力和發(fā)布流轉(zhuǎn)效率，全園區(qū)覆蓋效率提升100%。
第一，灰度機(jī)器加回現(xiàn)網(wǎng)之前，掃描日志初始化，進(jìn)而確認(rèn)程序初始化成功。第二，灰度機(jī)器加回現(xiàn)網(wǎng)之前，引入自動(dòng)化回滾。這里需持續(xù)豐富測(cè)試用例，打通測(cè)試平臺(tái)建立完整測(cè)試流程。
COS發(fā)布分離線(xiàn)計(jì)算，自研云集群、公有云海外、公有云國(guó)內(nèi)（每個(gè)云屬性下有多個(gè)集群）、同云屬性集群都可以在灰度健康的情況下開(kāi)啟并發(fā)。正常的版本發(fā)布耗時(shí)大約在1周工作日內(nèi)完成。
4）優(yōu)化流轉(zhuǎn)時(shí)間將發(fā)布流程放大并將每一環(huán)可能產(chǎn)生的問(wèn)題明確，我們可以看到不必要的浪費(fèi)和可節(jié)約的時(shí)間。COS當(dāng)前采用研發(fā)提單（僅提供提單權(quán)限）。系統(tǒng)群內(nèi)推送給到開(kāi)發(fā)leader審批，預(yù)發(fā)布環(huán)境發(fā)布，再到運(yùn)維leader審批現(xiàn)網(wǎng)發(fā)布的方式。其中流轉(zhuǎn)通過(guò)自動(dòng)群推送的方式減少人頻繁@時(shí)間，與知會(huì)時(shí)間。
現(xiàn)網(wǎng)發(fā)布時(shí)，由于云上是區(qū)分客戶(hù)等級(jí)的，所以在發(fā)布區(qū)域上用唯一流水線(xiàn)固化發(fā)布順序來(lái)降低區(qū)域選擇和流轉(zhuǎn)時(shí)間。（流水線(xiàn)覆蓋權(quán)限，且支持發(fā)布中臨時(shí)調(diào)整）。其實(shí)固化對(duì)于質(zhì)量的提升更多，后面來(lái)說(shuō)。
上述點(diǎn)優(yōu)化后，變更耗時(shí)從15天變更1w+設(shè)備，到4天變更4W+設(shè)備。
5）關(guān)注提效的更多探索????某次大規(guī)模故障復(fù)盤(pán)當(dāng)晚，我們對(duì)于快速故障處理時(shí)的發(fā)布提出了思考：回滾或者緊急的發(fā)布能否支持更快完成？軟件發(fā)布是否還有提效的空間？答案是肯定的。為了從細(xì)節(jié)出發(fā)，我們對(duì)每一次單機(jī)變更做了記錄。最終發(fā)現(xiàn)關(guān)鍵軟件由于程序包太大，下載耗時(shí)就占了40%。該下發(fā)方案是，多臺(tái)機(jī)器同時(shí)從變更系統(tǒng)拉取程序包。這使我們一下子就聯(lián)想到了客戶(hù)集中下載COS單對(duì)象的場(chǎng)景，該場(chǎng)景最優(yōu)的解決方案，就是引入CDN的特性與優(yōu)勢(shì)：預(yù)熱！
在實(shí)現(xiàn)上，我們用了兩種方案：
第一，緩存接入點(diǎn)就近分發(fā)。機(jī)器觸發(fā)新包拉取的時(shí)候存一份到緩存接入點(diǎn)。后續(xù)機(jī)器拉包去到就進(jìn)的緩存接入點(diǎn)拉取，減少拉包時(shí)間。缺點(diǎn)是需要盡可能多的緩存接入點(diǎn)；COS地域較多，會(huì)導(dǎo)致耗成本。
第二，預(yù)拉取。變更系統(tǒng)知曉發(fā)布單的所有行為，所以在任務(wù)啟動(dòng)的時(shí)候后臺(tái)就開(kāi)始（比如以200臺(tái)的并發(fā)度）將包往機(jī)器上分發(fā)。后面執(zhí)行的機(jī)器在單機(jī)變更模版基礎(chǔ)上加一步：判斷是否已經(jīng)分發(fā)過(guò)。當(dāng)標(biāo)志位是已分發(fā)時(shí)，則會(huì)跳過(guò)分發(fā)包直接開(kāi)始變更步驟。（COS使用該方案，節(jié)省了緩存接入點(diǎn)，降低帶寬與本機(jī)器成本）方案上線(xiàn)后，單機(jī)執(zhí)行效率提升40%。
6）只考慮提效帶來(lái)的問(wèn)題云上2B業(yè)務(wù)規(guī)模量龐大，疊加對(duì)象存儲(chǔ)COS內(nèi)部模塊數(shù)超20個(gè)，節(jié)點(diǎn)數(shù)超10萬(wàn)，對(duì)于版本迭代中的質(zhì)量必須提出極高要求。
質(zhì)量對(duì)于效率是非直觀的，但是始終會(huì)影響真實(shí)的交付效率。
總的來(lái)說(shuō)：現(xiàn)網(wǎng)發(fā)布中，效率是訴求，但發(fā)布質(zhì)量是痛點(diǎn)，若質(zhì)量問(wèn)題不解決，單純提效并不完善。
發(fā)布要提效，質(zhì)量是痛點(diǎn)COS對(duì)于發(fā)布中引入的質(zhì)量問(wèn)題優(yōu)化是艱難的。年維度的時(shí)間迭代，期間包含了COS運(yùn)營(yíng)模式改造、存儲(chǔ)架構(gòu)升級(jí)、變更體系完善、變更系統(tǒng)適配改造等多項(xiàng)措施。解決質(zhì)量問(wèn)題時(shí)不僅解決了效率痛點(diǎn)、規(guī)范了變更流程、保障變更質(zhì)量的同時(shí)還降低變更人力，多方面助力發(fā)布提效。下面講下COS如何做發(fā)布質(zhì)量的提升，希望能給你一些思路。
1）明確質(zhì)量痛點(diǎn)COS自身的問(wèn)題第一，OSS不完善，無(wú)實(shí)例管理。由于前期沒(méi)有統(tǒng)一的OSS，部署/開(kāi)區(qū)都通過(guò)拷包完成。OSS缺失導(dǎo)致發(fā)布中的狀態(tài)感知及各種發(fā)布中的問(wèn)題排查都是低效的。三級(jí)模塊管理很容易出錯(cuò)。因此，實(shí)例接口化升級(jí)是必要途徑。第二，配置包區(qū)域化，模版不一致。每個(gè)區(qū)域都有自己獨(dú)特的配置，而獨(dú)立性并不是需要的。修改一次全網(wǎng)特性需要去每一個(gè)區(qū)域包里面改配置，確認(rèn)時(shí)也一樣。差異化配置眾多，改造統(tǒng)一配置文件是重中之重。
第三，發(fā)布流程隨意，發(fā)布成功率靠運(yùn)維能力保障。原發(fā)布變更系統(tǒng)是沒(méi)有順序概念的，只有通用的編排比如串行/并行指著ip發(fā)布。
變更過(guò)程的問(wèn)題從歷史中能看到，問(wèn)題最多的原發(fā)布變更系統(tǒng)。業(yè)務(wù)發(fā)展初期，典型的情況是只考慮變更效率的極致提升，無(wú)考慮管控不足帶來(lái)的質(zhì)量風(fēng)險(xiǎn)。所以在系統(tǒng)選型上，需要按照自身業(yè)務(wù)的管控需求來(lái)做。管控不足主要分為以下六點(diǎn)：結(jié)合COS業(yè)務(wù)特性進(jìn)行發(fā)布場(chǎng)景梳理與邏輯梳理，我們分別從正常部署、正常回滾、配置發(fā)布、擴(kuò)縮容、緊急逃生、混部后的發(fā)布入手，結(jié)合現(xiàn)網(wǎng)變更中遇到的所有問(wèn)題確定所有場(chǎng)景。
另外回退對(duì)云業(yè)務(wù)來(lái)說(shuō)是預(yù)案。當(dāng)和發(fā)布有關(guān)聯(lián)，應(yīng)該第一時(shí)間回退。若不是回退問(wèn)題，其實(shí)我們期望讓回滾流轉(zhuǎn)成正向發(fā)布以繼續(xù)變更。
?
每次變更軟件負(fù)責(zé)人提供的額外注意事項(xiàng)，變更后的功能點(diǎn)更新的驗(yàn)證。以及是否可回滾，不可回滾變更的預(yù)案處理方法；
要關(guān)注變更期間的事件（不僅僅是變更模塊的告警，而是需要關(guān)注整體的告警）和用戶(hù)投訴、集群異常事件的產(chǎn)生等。2）逐項(xiàng)攻克解決配置文件管理升級(jí)為配置模板+配置變量的管理模式，對(duì)于整體運(yùn)營(yíng)上的提升有巨大幫助?
第一，開(kāi)區(qū)識(shí)別配置模版與配置變量，OSS支持自動(dòng)化開(kāi)區(qū)，獨(dú)立客戶(hù)單應(yīng)用創(chuàng)建；第二，OSS識(shí)別配置變量，對(duì)于每一個(gè)配置變量可以確定功能，明確變量使用場(chǎng)景，做到配置修改和下發(fā)的預(yù)案模型，取代sed；第三，管理配置模版后，全局配置統(tǒng)一，不需要擔(dān)心任何一個(gè)區(qū)域的配置文件再存在特異性問(wèn)題；第四，區(qū)分配置模版、配置變量后，可以逐漸根據(jù)情況縮減配置變量，讓通用性更強(qiáng)，運(yùn)營(yíng)復(fù)雜度降低；第五，配置變量對(duì)應(yīng)的文件可以獨(dú)立抽出來(lái)后，方便的做配置中心管理等更高級(jí)的下發(fā)升級(jí)；第六，實(shí)例問(wèn)題——OSS建設(shè)，實(shí)例接口化升級(jí)（耗時(shí)半年）。
接口實(shí)例化升級(jí)?首先，接口化便于指定發(fā)布、日志、監(jiān)控系統(tǒng)的統(tǒng)一管理（oss只維護(hù)接口，所有平臺(tái)支持監(jiān)聽(tīng)接口自動(dòng)更新）；其次，實(shí)例接口化后統(tǒng)一接入部門(mén)產(chǎn)品樹(shù)和產(chǎn)品下的集群樹(shù)，規(guī)范化集群和LZ（邏輯區(qū)域），根源上杜絕IP變更；此外，基于標(biāo)簽化的配置作用域管理，通過(guò)建立標(biāo)簽映射關(guān)系的工具支持，可以降低很多運(yùn)維的平臺(tái)遷移工作。變更過(guò)程改造第一，固化發(fā)布流程。因?yàn)轵v訊云是通過(guò)區(qū)域售賣(mài)區(qū)域管理，COS屬于Region級(jí)產(chǎn)品，所以按照Region來(lái)作為內(nèi)部發(fā)布平臺(tái)的抽象任務(wù)，內(nèi)部區(qū)分實(shí)際不同功能特性的集群。但是所有軟件的發(fā)布方式原本都各式各樣，沒(méi)辦法保障每個(gè)人來(lái)發(fā)布都能不出問(wèn)題。所以我們的方案是，降低發(fā)布爆炸半徑且固化：區(qū)域發(fā)布順序唯一且固化，設(shè)置可最大程度降低發(fā)布爆炸半徑的流程編排并驗(yàn)證（如第二部分COS的直觀提效第4點(diǎn)的發(fā)布流程優(yōu)化圖），并且所有的規(guī)范都通過(guò)智研平臺(tái)標(biāo)準(zhǔn)化落地，一個(gè)應(yīng)用，一個(gè)流程，現(xiàn)代化升級(jí)和固化發(fā)布流程，工具化落地審批、double check、強(qiáng)制回滾，預(yù)發(fā)布流程等，杜絕人為失誤，為自動(dòng)化變更打好基礎(chǔ)。詳細(xì)的點(diǎn)還包含：
每列分為一個(gè)完整的云屬性概念，保障不同屬性?xún)?yōu)先級(jí)順序，不同列之間引入暫停確認(rèn)；將LZ(邏輯區(qū)域)的概念落為編排單元（圖中的每一個(gè)任務(wù)）；LZ內(nèi)實(shí)現(xiàn)set化管理，保障區(qū)域內(nèi)針對(duì)不同云上客戶(hù)優(yōu)先級(jí)編排發(fā)布順序；新開(kāi)區(qū)場(chǎng)景會(huì)自動(dòng)識(shí)別到流水線(xiàn)模板，保障每次新增/減少集群都會(huì)加入到變更流水線(xiàn)上，保障發(fā)布全網(wǎng)覆蓋。
第二，固化發(fā)布策略保障了發(fā)布流程，當(dāng)然還要保障發(fā)布過(guò)程（發(fā)布策略）。失敗可暫停，變更必灰度，變更模式統(tǒng)一；統(tǒng)一的變更策略：程序變更統(tǒng)一最大失敗數(shù)，組內(nèi)/組間并發(fā)度；統(tǒng)一的灰度策略：所有變更按照【1-確認(rèn)-10%-確認(rèn)-100%】的灰度節(jié)奏，強(qiáng)保障變更影響面和人工觀察確認(rèn)；統(tǒng)一的單機(jī)變更模板：正常情況程序變更和配置變更的單機(jī)變更模板各有一個(gè)，其他按各場(chǎng)景各自唯一；統(tǒng)一的發(fā)布時(shí)間：落地部門(mén)變更標(biāo)準(zhǔn)時(shí)間，變更時(shí)間過(guò)后發(fā)布單自動(dòng)停止。
其他變更過(guò)程如下：
改造后的收益架平很多服務(wù)需要極致壓榨硬件性能，與存儲(chǔ)設(shè)備混部。該場(chǎng)景區(qū)別于在離線(xiàn)混部，屬于在線(xiàn)和在線(xiàn)混部，每個(gè)服務(wù)都需要保障可用性。故需要考慮發(fā)布中此類(lèi)場(chǎng)景的容災(zāi)設(shè)計(jì)。
需要杜絕的情況：第一，軟件A數(shù)量>>軟件B，軟件A灰度10%觸發(fā)機(jī)器死機(jī)導(dǎo)致軟件B100%服務(wù)異常；第二，軟件B類(lèi)三副本cell模型（參考索引存儲(chǔ)、塊存儲(chǔ)等實(shí)現(xiàn)），軟件A機(jī)器變更影響軟件B成對(duì)異常也會(huì)導(dǎo)致部分?jǐn)?shù)據(jù)不可用的場(chǎng)景。
解決方案是引入通用理解的容災(zāi)分組，保證上述流程落地后規(guī)范并發(fā)布。
發(fā)布問(wèn)題，解決的要點(diǎn)不僅僅是發(fā)布。COS對(duì)于變更額外還提出了很多自身運(yùn)營(yíng)上的的要求。
整體來(lái)說(shuō)，發(fā)布概念、發(fā)布流程把控的標(biāo)準(zhǔn)化解決了在大部分發(fā)布流程上人工誤操作可能引起的問(wèn)題。足夠標(biāo)準(zhǔn)化帶來(lái)的收益就是全面標(biāo)準(zhǔn)化外包化發(fā)布，通過(guò)運(yùn)維和開(kāi)發(fā)配合持續(xù)降低發(fā)布變更的人力投入。并且關(guān)鍵的是：版本發(fā)布未再出現(xiàn)由人為操作引起的故障case。
COS的變更改造總結(jié)持續(xù)度量，持續(xù)優(yōu)化
如果所有發(fā)布正向環(huán)節(jié)都考慮完備，能將效率與質(zhì)量都進(jìn)行提升。但這是否就足夠呢？答案是NO。還需要良好的可度量體系，才能保障各項(xiàng)環(huán)節(jié)有數(shù)據(jù)反饋，持續(xù)調(diào)優(yōu)。
好的度量具有兩個(gè)特征：一是能夠回答一個(gè)本質(zhì)問(wèn)題，另一個(gè)是能夠引導(dǎo)出正確的行為，兩者缺一不可。
目前來(lái)看，COS按照每一項(xiàng)發(fā)布的目標(biāo)做行為上的數(shù)據(jù)審計(jì)?？梢詤⒖家韵聨c(diǎn)：
第一，成熟度指標(biāo)體系：比如達(dá)到了某些標(biāo)志性的數(shù)據(jù)后，可以直觀地標(biāo)識(shí)成熟度等級(jí)（但等級(jí)低可能是包含了各種歷史和業(yè)務(wù)原因的）。?
第二，發(fā)布效率提升：比如從執(zhí)行日志找到單機(jī)類(lèi)效率低的點(diǎn)，比如從整個(gè)發(fā)布環(huán)節(jié)中找到時(shí)間delay比較多并且可優(yōu)化的點(diǎn)。?
第三，發(fā)布行為考量：比如整個(gè)發(fā)布環(huán)節(jié)究竟占了多少人力，一次變成成功率是否高？由于人為環(huán)節(jié)或系統(tǒng)因素導(dǎo)致頻繁發(fā)布失敗，發(fā)布結(jié)單是有數(shù)據(jù)的，從這些數(shù)據(jù)可以負(fù)反饋給到用戶(hù)是否該好好梳理下當(dāng)前的發(fā)布問(wèn)題及如何提升（是否環(huán)境污染、配置填錯(cuò)、模板不冪等）。因?yàn)榻y(tǒng)計(jì)后發(fā)現(xiàn)30%的人力消耗都在發(fā)布后，我們對(duì)于發(fā)布的調(diào)優(yōu)才變的非常重要。
第四，發(fā)布過(guò)程事件關(guān)聯(lián)：通過(guò)不同問(wèn)題類(lèi)型觸發(fā)的故障影響，給各個(gè)問(wèn)題做貢獻(xiàn)度系數(shù)，最終可以做變更質(zhì)檢的打分體系。?
第五，發(fā)布軟件原因：從程序上入手，可以從程序問(wèn)題的原因分類(lèi)來(lái)做統(tǒng)計(jì)，比如相同軟件經(jīng)常出BUG，相同平臺(tái)頻繁出BUG，BUG平均影響線(xiàn)上時(shí)長(zhǎng)等等反饋研發(fā)團(tuán)隊(duì)的可改進(jìn)方案。?
第六，審計(jì)負(fù)反饋通過(guò)部門(mén)某平臺(tái)匯總展示：定期郵件到所有產(chǎn)品的發(fā)布情況，引導(dǎo)各項(xiàng)環(huán)節(jié)完善管理。?
基于騰訊云上發(fā)布的理解，COS將發(fā)布成熟度區(qū)分為以下5級(jí)，最終目標(biāo)為全自動(dòng)發(fā)布。建立標(biāo)準(zhǔn)和成熟度模型，數(shù)據(jù)化牽引改進(jìn)發(fā)布變更各環(huán)節(jié)的成熟度，邁向自動(dòng)化。
首先是變更質(zhì)檢。區(qū)域告警關(guān)聯(lián)區(qū)域變更，事件總線(xiàn)建設(shè)（相關(guān)事件關(guān)聯(lián)），故障快速定位建設(shè)。用質(zhì)檢和打分體系代替灰度與全量&區(qū)域與區(qū)域之間的每一個(gè)暫停確認(rèn)點(diǎn)，把流程自動(dòng)化起來(lái)。
其次，用事件關(guān)聯(lián)變更、統(tǒng)一的質(zhì)檢看板與結(jié)果分析、軟件可回滾的前置條件下，把自動(dòng)回滾能力也同步建設(shè)到位。
基于主干開(kāi)發(fā)，引入城際快車(chē)發(fā)布模式，繼承其帶來(lái)的好處。每個(gè)人都非常清楚各個(gè)時(shí)間點(diǎn)、每個(gè)人都感覺(jué)到特性進(jìn)展、速度不斷提升、更加聚焦于生產(chǎn)質(zhì)量。
最后，結(jié)合云業(yè)務(wù)特性與devops中的變更看板：統(tǒng)一把控發(fā)布與發(fā)布評(píng)審（如同一區(qū)域最多同時(shí)發(fā)多少單等等），讓每個(gè)人都有緊迫感的同時(shí)，也不會(huì)漏發(fā)關(guān)鍵功能版本。
騰訊工程師技術(shù)干貨直達(dá)：1、算法工程師深度解構(gòu)ChatGPT技術(shù)
2、10分鐘！從架構(gòu)視角讀懂K8s
3、探秘微信業(yè)務(wù)優(yōu)化：DDD從入門(mén)到實(shí)踐
4、耗時(shí)減半？騰訊云OCR只做了3件事
關(guān)鍵詞：
