導(dǎo)讀| 如何讓功能缺陷修復(fù)快速上線？版本發(fā)出問題時(shí)怎樣快速回退？效率提升后質(zhì)量掉隊(duì)？為解決這些常讓運(yùn)維工程師頭疼的事情，本欄目特邀騰訊知名運(yùn)維工程師袁旭東，講述對(duì)象存儲(chǔ)COS的發(fā)布演進(jìn)過程，為各位開發(fā)者提供業(yè)務(wù)通用的高效高質(zhì)變更方法。該業(yè)務(wù)通過提升灰度自測(cè)能力、優(yōu)化流轉(zhuǎn)時(shí)間和并發(fā)策略等方法實(shí)現(xiàn)提效，同時(shí)提出措施保障質(zhì)量，并設(shè)置了一套可度量體系保障持續(xù)監(jiān)控、調(diào)優(yōu)，最終帶動(dòng)發(fā)布變更水平上新臺(tái)階。?????背景

1）背景訴求

現(xiàn)網(wǎng)發(fā)布變更對(duì)運(yùn)維開發(fā)工程師來說是最繁重的工作。發(fā)布變更的概念、節(jié)奏等已經(jīng)是老生常談。但在ToB時(shí)代到來后，云上業(yè)務(wù)的訴求是功能/缺陷修復(fù)盡快上線、版本發(fā)出問題快速回退，防止客戶業(yè)務(wù)受損。在整個(gè)需求上線環(huán)節(jié)中，CD部分由運(yùn)維實(shí)施。如何讓版本更快的交付上線是核心任務(wù)。

2）對(duì)象存儲(chǔ)COS

(相關(guān)資料圖)

騰訊云近幾年開始大力發(fā)展，對(duì)象存儲(chǔ)COS架構(gòu)也經(jīng)歷了一次存儲(chǔ)引擎升級(jí)YottaStore的大迭代。對(duì)象存儲(chǔ)COS從用戶接入到數(shù)據(jù)落地，要經(jīng)歷三個(gè)核心子平臺(tái)：邏輯接入層、索引存儲(chǔ)層、數(shù)據(jù)存儲(chǔ)層。每個(gè)子平臺(tái)內(nèi)部還有數(shù)十個(gè)模塊相互配合提供服務(wù)，任何一個(gè)鏈路出現(xiàn)異常都可能對(duì)數(shù)據(jù)PUT、GET、LIST、HEAD等接口造成可用性影響，COS節(jié)點(diǎn)數(shù)更是突破了10W+。

歷史的存儲(chǔ)引擎(TFS、LAVADB等)在變更中需要小set內(nèi)串行，或?qū)?shù)據(jù)遷走然后變更。這類變更耗時(shí)是顯而易見的（從耗時(shí)過長(zhǎng)會(huì)引發(fā)意想不到的變更方式：按照版本組合來變更，按照各區(qū)域版本自治完全沒有統(tǒng)一概念等）。這類型的變更最多做到流程標(biāo)準(zhǔn)化。它可以set之間并發(fā)或批量遷走數(shù)據(jù)再變更，但解決不了本質(zhì)問題。

YottaStore相比傳統(tǒng)TFS模式或LAVADB模式而言，好在將小set模式的變更方式升級(jí)為集群百分比變更，打破理解set變更的模式，每個(gè)節(jié)點(diǎn)剔除加回也不需要等待數(shù)據(jù)遷移。這本質(zhì)上提高了存儲(chǔ)變更效率上限。

COS關(guān)鍵提效手段1）管理區(qū)域MZ適配發(fā)布YottaStore在上線的時(shí)候就對(duì)節(jié)點(diǎn)標(biāo)簽引入了MZ（Management Zone）的概念：同集群內(nèi)跨MZ不能同時(shí)變更，減小誤操作爆炸半徑。例如，模塊上線后使用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之間串行，并且開始時(shí)智研平臺(tái)并發(fā)度受限在100以內(nèi)。

優(yōu)化后：考慮集群內(nèi)節(jié)點(diǎn)同服務(wù)角色，將灰度節(jié)奏調(diào)整為隨機(jī)一個(gè)MZ全量，減少跨MZ帶來的耗時(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)化的策略，主要是通過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%。

2）灰度自測(cè)能力為降低人工check等待時(shí)間，COS在單機(jī)變更模版引入變更的自檢過程。

第一，灰度機(jī)器加回現(xiàn)網(wǎng)之前，掃描日志初始化，進(jìn)而確認(rèn)程序初始化成功。第二，灰度機(jī)器加回現(xiàn)網(wǎng)之前，引入自動(dòng)化回滾。這里需持續(xù)豐富測(cè)試用例，打通測(cè)試平臺(tái)建立完整測(cè)試流程。

3）優(yōu)化并發(fā)策略變更系統(tǒng)提供人工控制入口，部署編排中的所有任務(wù)可以人工確認(rèn)后直接啟動(dòng)，速度直線提升。

COS發(fā)布分離線計(jì)算，自研云集群、公有云海外、公有云國(guó)內(nèi)（每個(gè)云屬性下有多個(gè)集群）、同云屬性集群都可以在灰度健康的情況下開啟并發(fā)。正常的版本發(fā)布耗時(shí)大約在1周工作日內(nèi)完成。

4）優(yōu)化流轉(zhuǎn)時(shí)間將發(fā)布流程放大并將每一環(huán)可能產(chǎn)生的問題明確，我們可以看到不必要的浪費(fèi)和可節(jié)約的時(shí)間。

COS當(dāng)前采用研發(fā)提單（僅提供提單權(quán)限）。系統(tǒng)群內(nèi)推送給到開發(fā)leader審批，預(yù)發(fā)布環(huán)境發(fā)布，再到運(yùn)維leader審批現(xiàn)網(wǎng)發(fā)布的方式。其中流轉(zhuǎn)通過自動(dòng)群推送的方式減少人頻繁@時(shí)間，與知會(huì)時(shí)間。

現(xiàn)網(wǎng)發(fā)布時(shí)，由于云上是區(qū)分客戶等級(jí)的，所以在發(fā)布區(qū)域上用唯一流水線固化發(fā)布順序來降低區(qū)域選擇和流轉(zhuǎn)時(shí)間。（流水線覆蓋權(quán)限，且支持發(fā)布中臨時(shí)調(diào)整）。其實(shí)固化對(duì)于質(zhì)量的提升更多，后面來說。

上述點(diǎn)優(yōu)化后，變更耗時(shí)從15天變更1w+設(shè)備，到4天變更4W+設(shè)備。

5）關(guān)注提效的更多探索????某次大規(guī)模故障復(fù)盤當(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)想到了客戶集中下載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)就開始（比如以200臺(tái)的并發(fā)度）將包往機(jī)器上分發(fā)。后面執(zhí)行的機(jī)器在單機(jī)變更模版基礎(chǔ)上加一步：判斷是否已經(jīng)分發(fā)過。當(dāng)標(biāo)志位是已分發(fā)時(shí)，則會(huì)跳過分發(fā)包直接開始變更步驟。（COS使用該方案，節(jié)省了緩存接入點(diǎn)，降低帶寬與本機(jī)器成本）方案上線后，單機(jī)執(zhí)行效率提升40%。

6）只考慮提效帶來的問題

云上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í)的交付效率。

總的來說：現(xiàn)網(wǎng)發(fā)布中，效率是訴求，但發(fā)布質(zhì)量是痛點(diǎn)，若質(zhì)量問題不解決，單純提效并不完善。

發(fā)布要提效，質(zhì)量是痛點(diǎn)

COS對(duì)于發(fā)布中引入的質(zhì)量問題優(yōu)化是艱難的。年維度的時(shí)間迭代，期間包含了COS運(yùn)營(yíng)模式改造、存儲(chǔ)架構(gòu)升級(jí)、變更體系完善、變更系統(tǒng)適配改造等多項(xiàng)措施。解決質(zhì)量問題時(shí)不僅解決了效率痛點(diǎn)、規(guī)范了變更流程、保障變更質(zhì)量的同時(shí)還降低變更人力，多方面助力發(fā)布提效。下面講下COS如何做發(fā)布質(zhì)量的提升，希望能給你一些思路。

1）明確質(zhì)量痛點(diǎn)COS自身的問題第一，OSS不完善，無(wú)實(shí)例管理。由于前期沒有統(tǒng)一的OSS，部署/開區(qū)都通過拷包完成。OSS缺失導(dǎo)致發(fā)布中的狀態(tài)感知及各種發(fā)布中的問題排查都是低效的。三級(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)是沒有順序概念的，只有通用的編排比如串行/并行指著ip發(fā)布。

變更過程的問題從歷史中能看到，問題最多的原發(fā)布變更系統(tǒng)。業(yè)務(wù)發(fā)展初期，典型的情況是只考慮變更效率的極致提升，無(wú)考慮管控不足帶來的質(zhì)量風(fēng)險(xiǎn)。所以在系統(tǒng)選型上，需要按照自身業(yè)務(wù)的管控需求來做。管控不足主要分為以下六點(diǎn)：

COS發(fā)布場(chǎng)景梳理

結(jié)合COS業(yè)務(wù)特性進(jìn)行發(fā)布場(chǎng)景梳理與邏輯梳理，我們分別從正常部署、正?；貪L、配置發(fā)布、擴(kuò)縮容、緊急逃生、混部后的發(fā)布入手，結(jié)合現(xiàn)網(wǎng)變更中遇到的所有問題確定所有場(chǎng)景。

另外回退對(duì)云業(yè)務(wù)來說是預(yù)案。當(dāng)和發(fā)布有關(guān)聯(lián)，應(yīng)該第一時(shí)間回退。若不是回退問題，其實(shí)我們期望讓回滾流轉(zhuǎn)成正向發(fā)布以繼續(xù)變更。

觀察點(diǎn)梳理—質(zhì)量崗哨梳理COS發(fā)布前后的觀察點(diǎn)，便于理解變更行為從而設(shè)置“崗哨”。包括基礎(chǔ)的進(jìn)程是否拉起、日志是否有錯(cuò)誤、coredump、正常/異常返回碼是否正常、延遲成功率業(yè)務(wù)請(qǐng)求是否變化。

?

每次變更軟件負(fù)責(zé)人提供的額外注意事項(xiàng)，變更后的功能點(diǎn)更新的驗(yàn)證。以及是否可回滾，不可回滾變更的預(yù)案處理方法；

要關(guān)注變更期間的事件（不僅僅是變更模塊的告警，而是需要關(guān)注整體的告警）和用戶投訴、集群異常事件的產(chǎn)生等。2）逐項(xiàng)攻克解決

配置文件管理升級(jí)為配置模板+配置變量的管理模式，對(duì)于整體運(yùn)營(yíng)上的提升有巨大幫助?

第一，開區(qū)識(shí)別配置模版與配置變量，OSS支持自動(dòng)化開區(qū)，獨(dú)立客戶單應(yīng)用創(chuàng)建；第二，OSS識(shí)別配置變量，對(duì)于每一個(gè)配置變量可以確定功能，明確變量使用場(chǎng)景，做到配置修改和下發(fā)的預(yù)案模型，取代sed；第三，管理配置模版后，全局配置統(tǒng)一，不需要擔(dān)心任何一個(gè)區(qū)域的配置文件再存在特異性問題；第四，區(qū)分配置模版、配置變量后，可以逐漸根據(jù)情況縮減配置變量，讓通用性更強(qiáng)，運(yùn)營(yíng)復(fù)雜度降低；第五，配置變量對(duì)應(yīng)的文件可以獨(dú)立抽出來后，方便的做配置中心管理等更高級(jí)的下發(fā)升級(jí)；第六，實(shí)例問題——OSS建設(shè)，實(shí)例接口化升級(jí)（耗時(shí)半年）。

接口實(shí)例化升級(jí)?首先，接口化便于指定發(fā)布、日志、監(jiān)控系統(tǒng)的統(tǒng)一管理（oss只維護(hù)接口，所有平臺(tái)支持監(jiān)聽接口自動(dòng)更新）；其次，實(shí)例接口化后統(tǒng)一接入部門產(chǎn)品樹和產(chǎn)品下的集群樹，規(guī)范化集群和LZ（邏輯區(qū)域），根源上杜絕IP變更；此外，基于標(biāo)簽化的配置作用域管理，通過建立標(biāo)簽映射關(guān)系的工具支持，可以降低很多運(yùn)維的平臺(tái)遷移工作。變更過程改造

第一，固化發(fā)布流程。因?yàn)轵v訊云是通過區(qū)域售賣區(qū)域管理，COS屬于Region級(jí)產(chǎn)品，所以按照Region來作為內(nèi)部發(fā)布平臺(tái)的抽象任務(wù)，內(nèi)部區(qū)分實(shí)際不同功能特性的集群。但是所有軟件的發(fā)布方式原本都各式各樣，沒辦法保障每個(gè)人來發(fā)布都能不出問題。所以我們的方案是，降低發(fā)布爆炸半徑且固化：區(qū)域發(fā)布順序唯一且固化，設(shè)置可最大程度降低發(fā)布爆炸半徑的流程編排并驗(yàn)證（如第二部分COS的直觀提效第4點(diǎn)的發(fā)布流程優(yōu)化圖），并且所有的規(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è)完整的云屬性概念，保障不同屬性優(yōu)先級(jí)順序，不同列之間引入暫停確認(rèn)；將LZ(邏輯區(qū)域)的概念落為編排單元（圖中的每一個(gè)任務(wù)）；LZ內(nèi)實(shí)現(xiàn)set化管理，保障區(qū)域內(nèi)針對(duì)不同云上客戶優(yōu)先級(jí)編排發(fā)布順序；新開區(qū)場(chǎng)景會(huì)自動(dòng)識(shí)別到流水線模板，保障每次新增/減少集群都會(huì)加入到變更流水線上，保障發(fā)布全網(wǎng)覆蓋。

第二，固化發(fā)布策略保障了發(fā)布流程，當(dāng)然還要保障發(fā)布過程（發(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í)間：落地部門變更標(biāo)準(zhǔn)時(shí)間，變更時(shí)間過后發(fā)布單自動(dòng)停止。

其他變更過程如下：

改造后的收益

3）解決存儲(chǔ)業(yè)務(wù)混部場(chǎng)景

架平很多服務(wù)需要極致壓榨硬件性能，與存儲(chǔ)設(shè)備混部。該場(chǎng)景區(qū)別于在離線混部，屬于在線和在線混部，每個(gè)服務(wù)都需要保障可用性。故需要考慮發(fā)布中此類場(chǎng)景的容災(zāi)設(shè)計(jì)。

需要杜絕的情況：第一，軟件A數(shù)量>>軟件B，軟件A灰度10%觸發(fā)機(jī)器死機(jī)導(dǎo)致軟件B100%服務(wù)異常；第二，軟件B類三副本cell模型（參考索引存儲(chǔ)、塊存儲(chǔ)等實(shí)現(xiàn)），軟件A機(jī)器變更影響軟件B成對(duì)異常也會(huì)導(dǎo)致部分?jǐn)?shù)據(jù)不可用的場(chǎng)景。

解決方案是引入通用理解的容災(zāi)分組，保證上述流程落地后規(guī)范并發(fā)布。

4）完善變更體系

發(fā)布問題，解決的要點(diǎn)不僅僅是發(fā)布。COS對(duì)于變更額外還提出了很多自身運(yùn)營(yíng)上的的要求。

整體來說，發(fā)布概念、發(fā)布流程把控的標(biāo)準(zhǔn)化解決了在大部分發(fā)布流程上人工誤操作可能引起的問題。足夠標(biāo)準(zhǔn)化帶來的收益就是全面標(biāo)準(zhǔn)化外包化發(fā)布，通過運(yùn)維和開發(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ì)問題，另一個(gè)是能夠引導(dǎo)出正確的行為，兩者缺一不可。

1）審計(jì)負(fù)反饋

目前來看，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ī)類效率低的點(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ù)反饋給到用戶是否該好好梳理下當(dāng)前的發(fā)布問題及如何提升（是否環(huán)境污染、配置填錯(cuò)、模板不冪等）。因?yàn)榻y(tǒng)計(jì)后發(fā)現(xiàn)30%的人力消耗都在發(fā)布后，我們對(duì)于發(fā)布的調(diào)優(yōu)才變的非常重要。

第四，發(fā)布過程事件關(guān)聯(lián)：通過不同問題類型觸發(fā)的故障影響，給各個(gè)問題做貢獻(xiàn)度系數(shù)，最終可以做變更質(zhì)檢的打分體系。?

第五，發(fā)布軟件原因：從程序上入手，可以從程序問題的原因分類來做統(tǒng)計(jì)，比如相同軟件經(jīng)常出BUG，相同平臺(tái)頻繁出BUG，BUG平均影響線上時(shí)長(zhǎng)等等反饋研發(fā)團(tuán)隊(duì)的可改進(jìn)方案。?

第六，審計(jì)負(fù)反饋通過部門某平臺(tái)匯總展示：定期郵件到所有產(chǎn)品的發(fā)布情況，引導(dǎo)各項(xiàng)環(huán)節(jié)完善管理。?

2）成熟度體系

基于騰訊云上發(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)化。

未來：向更智能的發(fā)布模式演進(jìn)

首先是變更質(zhì)檢。區(qū)域告警關(guān)聯(lián)區(qū)域變更，事件總線建設(shè)（相關(guān)事件關(guān)聯(lián)），故障快速定位建設(shè)。用質(zhì)檢和打分體系代替灰度與全量&區(qū)域與區(qū)域之間的每一個(gè)暫停確認(rèn)點(diǎn)，把流程自動(dòng)化起來。

其次，用事件關(guān)聯(lián)變更、統(tǒng)一的質(zhì)檢看板與結(jié)果分析、軟件可回滾的前置條件下，把自動(dòng)回滾能力也同步建設(shè)到位。

基于主干開發(fā)，引入城際快車發(fā)布模式，繼承其帶來的好處。每個(gè)人都非常清楚各個(gè)時(shí)間點(diǎn)、每個(gè)人都感覺到特性進(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從入門到實(shí)踐

4、耗時(shí)減半？騰訊云OCR只做了3件事