作者 | 趙振

Linux 發(fā)行版的自主維護(hù)工作一直面臨著巨大的挑戰(zhàn)，軟件包規(guī)模巨大，涉及多個(gè)領(lǐng)域，要進(jìn)行有效的自主維護(hù)，對(duì)人力、能力都有極高的要求。本文根據(jù)騰訊工程師、OpenCloudOS 社區(qū)技術(shù)專家趙振在 2024 年第十一屆開(kāi)源操作系統(tǒng)年度會(huì)議(OS2ATC)上的分享整理，重點(diǎn)探討為打造全鏈路自研操作系統(tǒng)，如何實(shí)現(xiàn)對(duì) 3000+ 大規(guī)模軟件包的全鏈路自主研發(fā)與自主維護(hù)。

一、整體介紹

一個(gè) Linux 發(fā)行版標(biāo)準(zhǔn)鏡像包含 3000 余個(gè)軟件包，具體涉及庫(kù)、工具、服務(wù)、語(yǔ)言運(yùn)行時(shí)、圖形、音視頻等各個(gè)方面，再加上各種場(chǎng)景應(yīng)用，比如云原生、數(shù)據(jù)庫(kù)、AI 等，涉及軟件包數(shù)以萬(wàn)計(jì)，如何維護(hù)如此大規(guī)模的軟件包，對(duì)團(tuán)隊(duì)的人力、人員能力都是巨大的挑戰(zhàn)。

操作系統(tǒng)團(tuán)隊(duì)在對(duì)軟件包分類、分層，按照領(lǐng)域分類、重要性等進(jìn)行差異化維護(hù)之外，更構(gòu)建了一套全流程自動(dòng)化的基礎(chǔ)設(shè)施和工具平臺(tái)，以提升維護(hù)效率和質(zhì)量，讓軟件包的維護(hù)者有更多的精力投入到重要包的掌握和能力建設(shè)中。

該工具平臺(tái)從上游跟蹤到代碼同步，各個(gè)流程環(huán)節(jié)盡可能自動(dòng)化，主要包括以下 5 個(gè)部分及對(duì)應(yīng)的工具。

第一個(gè)工具 rpm-upgrade 用來(lái)跟蹤上游社區(qū)的發(fā)布情況，包括獲取新版本的 changelog 了解社區(qū)的動(dòng)態(tài)。第二個(gè)工具 rpm-tracker 用來(lái)跟蹤重要包的 commits，扒取 bugfix、cve 相關(guān)的 patch。通過(guò)這兩個(gè)工具可以及時(shí)獲取上游最新的動(dòng)態(tài)、修復(fù)，按需同步到自主維護(hù)的版本，軟件包維護(hù)者就不用人肉跟蹤上游社區(qū)；獲取到上游的更新、修復(fù)后，會(huì)嘗試自動(dòng)提交 PR。

對(duì)于提交成功的PR，會(huì)通過(guò)第三個(gè)工具 rpm-check 進(jìn)行變更識(shí)別和兼容性檢查，如果發(fā)現(xiàn)兼容性變化，會(huì)自動(dòng)通過(guò)第四個(gè)工具 rpm-dep 來(lái)查找受影響的軟件包來(lái)進(jìn)行重編、執(zhí)行受影響的包的用例，最后通過(guò)第五個(gè)工具 rpm-sync 來(lái)同步到其他分支。

以上是軟件包維護(hù)全過(guò)程，通過(guò) CI 串聯(lián)起來(lái)實(shí)現(xiàn)全流程自動(dòng)化。

二、具體實(shí)現(xiàn)

1.rpm-upgrade：上游新 Release 跟蹤查詢

問(wèn)題：軟件包的上游社區(qū)形式多樣，有 Git、svn、hg 等不同的協(xié)議，github/gitlab、pypi、metacpan、Sourceforge 等不同接口，且軟件包最新的 Release 發(fā)布時(shí)間不定，有的發(fā)布頻繁，有的長(zhǎng)期無(wú)新 Release，不同系列的軟件包選型的間隔也存在差異，如果無(wú)差異地對(duì)所有包執(zhí)行升級(jí)查詢，浪費(fèi)資源和人力。

解決方案：團(tuán)隊(duì)設(shè)計(jì)的 rpm-upgrade 工具，可通過(guò)多種查詢接口，覆蓋不同類型的上游平臺(tái)；通過(guò)綜合發(fā)布時(shí)間、頻率、選型時(shí)間、選型間隔內(nèi)的版本數(shù)等，多維度評(píng)估該版本是否需要自動(dòng)升級(jí)。

效果：當(dāng)前主流平臺(tái) Git/svn/pypi/perl 等都已覆蓋，3200+ 軟件包中的 98.5% 都能實(shí)現(xiàn)自動(dòng)化查詢升級(jí)，基本不再需要人工跟蹤上游。

2.rpm-upgrade：上游新 Release 自動(dòng)升級(jí)

問(wèn)題：上游新 Release 查詢到后，符合條件的軟件包就可以進(jìn)行自動(dòng)升級(jí)。但在升級(jí)過(guò)程中，還存在多 source 源，tarball 需自行生成、上游未提供完整 tarball，補(bǔ)丁沖突等復(fù)雜情況導(dǎo)致自動(dòng)化困難。

解決方案：工具先修改version、Release、chaneglog，再根據(jù)修改后的內(nèi)容獲取源碼包。如果是多源碼包情況，則根據(jù)宏解析自動(dòng)下載；如果是 tarball 無(wú)法直接獲取等情況，則支持維護(hù)者自定義腳本處理。

對(duì)于升級(jí)過(guò)程中的補(bǔ)丁沖突，則根據(jù)補(bǔ)丁來(lái)源和補(bǔ)丁編號(hào)規(guī)則處理。上游補(bǔ)丁沖突時(shí)，視為上游已合入，移除該補(bǔ)丁并記錄； 發(fā)行版補(bǔ)丁沖突時(shí)，報(bào)警提示并記錄，由 maintainer 介入分析。

效果：升級(jí)軟件包平均節(jié)省 10 分鐘以上，并且自動(dòng)解決補(bǔ)丁沖突可達(dá) 85% 以上，軟件包升級(jí)效率提升 80%+。

3.rpm-tracker：上游 commits 跟蹤扒取

問(wèn)題：軟件分支、commit 信息多，傳統(tǒng) git clone 方式耗時(shí)長(zhǎng)；主要關(guān)注 bugfix、cve，需要對(duì) commtis 進(jìn)行分類，人工費(fèi)力、關(guān)鍵詞匹配方式不準(zhǔn)確。

解決方案：rpm-tracker工具通過(guò) Python 的 GraphQL API 爬取上游 commits 信息，支持 GitHub、GitLab 等主流平臺(tái)；并且選擇專門(mén)基于代碼訓(xùn)練的大模型，結(jié)合微調(diào)，對(duì) commits 進(jìn)行分類，把 bug 修復(fù)、cve 修復(fù)等類型的 commits 識(shí)別出來(lái)，backport 到代碼中。爬取后自動(dòng)提交 PR。

效果：當(dāng)前工具可以一次性查詢上百個(gè)軟件，模型在普通臺(tái)式機(jī)上無(wú)量化的情況下可以穩(wěn)定運(yùn)行，輸出結(jié)果準(zhǔn)確率 80% 以上，大大減少人工分析、回合的工作量。

4.rpm-check：兼容性檢查，軟件包變更的守門(mén)人

問(wèn)題：上游新 Release、commits 扒取回合，提交 PR、完成編譯后，進(jìn)行兼容性檢查。當(dāng)前業(yè)界已有的兼容性檢查開(kāi)源工具主要是對(duì) C/C++ 程序、Java 程序進(jìn)行檢查，同時(shí)存在需要人工指定包以及庫(kù)、無(wú)法處理庫(kù)中部分特殊字符、無(wú)法判斷符號(hào)是否對(duì)外、結(jié)果可讀性差、速度較慢等情況。

解決方案：rpm-check 在 abicc 社區(qū)工具的基礎(chǔ)上解決了上述幾個(gè)問(wèn)題，同時(shí)基于Python AST 模塊自研了 Python 兼容性檢查工具。

工具掃描目錄下所有 rpm 包及其 debuginfo 包、devel 包進(jìn)行匹配成對(duì)后以篩選出需要檢查的 rpm 包，然后通過(guò)多進(jìn)程方式對(duì)每對(duì)包進(jìn)行處理，同時(shí)會(huì)在文件粒度上也進(jìn)行并發(fā)操作，最大限度縮短檢查時(shí)間。

檢查項(xiàng)包括幾個(gè)方面：

• 子包列表：檢查子包是否有增刪
• rpm 的能力：（requires/provides/..），判斷是否有能力發(fā)生變化
• 文件列表：檢查重點(diǎn)位置的文件是否有增刪，同時(shí)排除無(wú)關(guān)信息（如版本號(hào)）以及無(wú)影響文件
• 動(dòng)態(tài)庫(kù)的 ABI/API：根據(jù)代碼變化定位影響的結(jié)構(gòu)體、函數(shù)等
• 二進(jìn)制可執(zhí)行程序比較：比較軟件包中存在的可執(zhí)行文件（工具、腳本等）的選項(xiàng)、參數(shù)是否發(fā)生變化
• 配置文件：支持多種配置文件格式，精確找到具體的變化項(xiàng)

多進(jìn)程檢查結(jié)束后，會(huì)對(duì)檢查結(jié)果進(jìn)行分析評(píng)估：比如 ABI/API 的變化，會(huì)先經(jīng)過(guò)內(nèi)外部符號(hào)判定，判斷該變化為內(nèi)部變化還是外部變化，然后經(jīng)過(guò)評(píng)估算法確定其影響等級(jí)，影響等級(jí)用來(lái)判斷該次變化的嚴(yán)重程度以及是否需要進(jìn)一步判斷其影響范圍。

最后根據(jù)評(píng)估結(jié)果等級(jí)確認(rèn)影響范圍，這一步通過(guò)在依賴包中進(jìn)行符號(hào)搜索來(lái)完成，同時(shí)，搜索也會(huì)通過(guò)本地緩存進(jìn)行加速。經(jīng)過(guò)以上檢查和精確查找，得到此次的變化影響的符號(hào)、軟件包以及受到影響的庫(kù)。

效果：支持 C、C++、Python、Java 等主流語(yǔ)言，特殊場(chǎng)景基本覆蓋；從符號(hào)粒度確認(rèn)影響范圍，精確度 90% 以上；包及文件粒度并發(fā)，本地緩存縮短檢查以及符號(hào)搜索耗時(shí) 50% 以上。

5.rpm-dep： 查詢包依賴與排序

問(wèn)題：受兼容性變化影響的包，通過(guò) rpm-dep 工具獲取。當(dāng)前 DNF 工具無(wú)法快速獲取發(fā)生變化的包所影響到的包，包括依賴當(dāng)前變化的包進(jìn)行編譯的包，依賴當(dāng)前變化的包進(jìn)行安裝的包，即反向依賴。

同時(shí)，獲取到反向依賴包列表后，列表中的包之間也存在層級(jí)關(guān)系，進(jìn)行構(gòu)建時(shí)，需要先構(gòu)建底層的，后處理高層級(jí)的，這就需要排序。

解決方案：rpm-dep 工具初始化時(shí)，解析 repo 源的 repodata 文件，構(gòu)造出依賴關(guān)系表，將依賴關(guān)系表存入 Redis，提高查詢速度。

• 依賴查詢時(shí)，通過(guò) key - value 查詢，以及 bfs 多層的檢索，即可獲取指定層數(shù)的依賴關(guān)系樹(shù)。
• 依賴排序時(shí)，首先建立包的依賴圖，對(duì)于存在循環(huán)依賴的情況，會(huì)統(tǒng)計(jì)循環(huán)鏈上的所有包的被引用情況，從被引用最少的節(jié)點(diǎn)拆開(kāi)循環(huán)鏈條。

然后得到一個(gè)有向無(wú)環(huán)圖，接下來(lái)使用拓?fù)渑判虻乃枷?，每一輪循環(huán)都取出無(wú)前向依賴的節(jié)點(diǎn)，即可對(duì)同層的 RPM 包排出優(yōu)先級(jí)。

效果：多種依賴場(chǎng)景秒級(jí)查詢多層依賴樹(shù)；包排序指導(dǎo)按依賴層級(jí)進(jìn)行構(gòu)建。

6.自動(dòng) Release+1 重編受影響的包

需求：兼容性變化，需要準(zhǔn)確無(wú)誤的重編受影響的軟件包，根據(jù)影響和風(fēng)險(xiǎn)的不同，分為測(cè)試重編和正式重編，測(cè)試重編不 Release+1 提交 PR、只用來(lái)驗(yàn)證變化會(huì)不會(huì)導(dǎo)致問(wèn)題，如 API 頭文件變化，正式重編是指要 Release+1 提交 PR，如 soname 變化會(huì)導(dǎo)致找不到依賴，就要正式重編。測(cè)試重編、正式重編，都要保障編譯源依賴的是變化后的包，不能基于老包編譯。

解決：為了避免遺漏或者范圍過(guò)廣出現(xiàn)無(wú)效重編，我們根據(jù)兼容性變化的具體內(nèi)容和影響范圍，確定重編類型，如表格所示，然后使用 rpm-dep 工具找出受影響的依賴包。

• 對(duì)于測(cè)試重編，我們將 PR 編譯通過(guò)的軟件包結(jié)合當(dāng)前編譯源，制作成臨時(shí)編譯源；在這個(gè)臨時(shí)編譯源的基礎(chǔ)上，我們對(duì)受影響的包進(jìn)行測(cè)試重編。
• 對(duì)于正式重編，創(chuàng)建 issue 進(jìn)行跟蹤，按照依賴關(guān)系層級(jí)排序，自動(dòng)依次發(fā)起正式重編 PR，上一層級(jí)的 PR 編譯成功、進(jìn)入編譯源后，提交下一層級(jí)的 PR，直到所有需要 Release+1 重編的包都完成編譯。

效果：重編精準(zhǔn)，無(wú)遺漏無(wú)冗余 Release+1；按依賴層級(jí)編譯、構(gòu)造編譯源，編譯依賴新包；人工只需確認(rèn)，效率提升 100%。

7.精準(zhǔn)全面測(cè)試+快速高質(zhì)量發(fā)布

需求：PR 編譯通過(guò)后，要對(duì)軟件包進(jìn)行更新發(fā)布，既要保證軟件包更新的及時(shí)性，也要保證軟件包更新的質(zhì)量。

解決方案：我們通過(guò)消息機(jī)制保證編譯完成的軟件包能夠及時(shí)更新至測(cè)試平臺(tái)，立即獲取更新后的軟件包到測(cè)試 YUM 源，然后進(jìn)行升級(jí)測(cè)試、安裝測(cè)試、服務(wù)啟停測(cè)試、功能測(cè)試，并根據(jù)前面提到的 rpm-dep 工具給出的受影響包列表執(zhí)行受影響包的測(cè)試，以此來(lái)做到精準(zhǔn)測(cè)試，覆蓋全面，同時(shí)高效地得到質(zhì)量反饋。

此外，為了防止出錯(cuò)軟件包阻塞其他通過(guò)測(cè)試的軟件包的正常發(fā)布流程，對(duì)于測(cè)試未通過(guò)的軟件包，會(huì)以單個(gè)軟件包的粒度回退，清理對(duì)應(yīng)軟件包及其重編包，并發(fā)起問(wèn)題處理流程。然后繼續(xù)進(jìn)行其他保證其他正常軟件包的及時(shí)發(fā)布。

效果：小時(shí)級(jí)軟件更新速度（代碼提交到更新發(fā)布）；軟件升級(jí)沖突、功能等問(wèn)題有效攔截。

8.rpm-sync：分支間高效同步

PR 合入后，后臺(tái)會(huì)根據(jù) PR 填入的 commit 模板信息，進(jìn)行分類。識(shí)別到是 bugfix， 安全修復(fù)，后臺(tái)會(huì)自動(dòng)調(diào)整相關(guān) commit，向下游分支發(fā)起同步。如果同步失敗，會(huì)自動(dòng)創(chuàng)建工單通知相關(guān)人員對(duì)同步的 PR 進(jìn)行分析調(diào)整。

效果：多分支及時(shí)保持同步；流程自動(dòng)化，形成完備的錯(cuò)誤處理機(jī)制；減少人工同步、多分支維護(hù)的工作量。

9.整體數(shù)據(jù)流設(shè)計(jì)

問(wèn)題：通過(guò)前面的介紹，可以看到，整個(gè)自動(dòng)化流程涉及了上游源碼社區(qū)的更新監(jiān)控，代碼托管平臺(tái)的管理、下游編譯平臺(tái)、分發(fā)平臺(tái)以及測(cè)試平臺(tái)多個(gè)流程的不同組件，平臺(tái)、流程、環(huán)節(jié)多，交互復(fù)雜，包括事件通知、狀態(tài)等待、結(jié)果回傳等。

解決方案：基于這個(gè)問(wèn)題，我們?cè)O(shè)計(jì)了一整套消息機(jī)制，通過(guò)消息隊(duì)列解耦不同平臺(tái)的數(shù)據(jù)依賴問(wèn)題，并通過(guò) CI 平臺(tái)的流水線驅(qū)動(dòng)不同任務(wù)運(yùn)行。

比如，當(dāng)我們監(jiān)聽(tīng)到上游社區(qū)更新了新版本，這個(gè)消息會(huì)寫(xiě)入消息隊(duì)列，等待對(duì)應(yīng)的代碼同步流水線處理更新。再將同步完成的消息寫(xiě)入消息隊(duì)列，等待后續(xù)的編譯、測(cè)試、同步流水線的批次處理。

這套消息處理機(jī)制，解耦了不同流程間的依賴，僅通過(guò)統(tǒng)一的消息來(lái)完成整個(gè)流程的執(zhí)行。并且因?yàn)橄⒈４嬖谙㈥?duì)列中，下游流程不依賴上游數(shù)據(jù)的實(shí)時(shí)更新，對(duì)于執(zhí)行失敗的下游任務(wù)，我們可以重新從隊(duì)列中取得對(duì)應(yīng)的消息，然后從執(zhí)行失敗點(diǎn)繼續(xù)完成后續(xù)工作。

此外，消息隊(duì)列可以驅(qū)動(dòng)流程運(yùn)行，但它沒(méi)有持久存儲(chǔ)的能力，沒(méi)法記錄并追蹤某個(gè)更新的軟件當(dāng)前狀態(tài)（除非我們遍歷消息隊(duì)列），因此，我們通過(guò)數(shù)據(jù)庫(kù)來(lái)記錄某個(gè)軟件包當(dāng)前處在哪個(gè)流程中，來(lái)保證每個(gè)軟件包的可追蹤性。

效果：提升平臺(tái)開(kāi)發(fā)和運(yùn)行效率 50%+。

三、未來(lái)展望

以上通過(guò)自動(dòng)化基礎(chǔ)設(shè)施、工具平臺(tái)的加持，軟件包自主維護(hù)效率得到了成倍的提升，質(zhì)量也得到一定保障，不過(guò)距離自主維護(hù)能力的成熟還有較大的差距。當(dāng)前部分重要包已經(jīng)掌握了代碼架構(gòu)、重要功能的實(shí)現(xiàn)，但還有較多的軟件包需要逐步積累維護(hù)能力；自主可控版本的軟硬件生態(tài)與業(yè)界標(biāo)桿也有差距，隨著軟硬件生態(tài)的推進(jìn)，版本的兼容、穩(wěn)定也會(huì)面臨一些挑戰(zhàn)。

項(xiàng)目在 systemd、glibc、gcc 等關(guān)鍵用戶態(tài)軟件包社區(qū)已經(jīng)有一些貢獻(xiàn)，獲得了 numactl 等社區(qū)的 maintainer，不過(guò)上游社區(qū)參與度遠(yuǎn)遠(yuǎn)不夠，聲量及影響力仍然很弱。

當(dāng)前 AI、異構(gòu)等新場(chǎng)景不斷涌現(xiàn)，開(kāi)發(fā)者、管理員、企業(yè)等需求日新月異，傳統(tǒng)的 OS 也需要與時(shí)俱進(jìn)、不斷創(chuàng)新，才能保持生命力。千里之行始于足下，自主維護(hù)能力建設(shè)已經(jīng)邁出了堅(jiān)實(shí)的一步，剩下的就是腳踏實(shí)地，一步一個(gè)腳印，把自主可控做實(shí)做深。