作者：子醜
爲什麼會有研發規範
很多程序員入職一家新的公司，領完電腦再安裝完必備的開發工具，接下來最先接觸的恐怕就是新公司的研發規範了。幾乎所有的軟件企業都有或繁或簡的一套或多套研發規範，並且大部分軟件團隊都認爲他們的研發規範是不太一樣的，是適合他們當前的實際情況的。
研發規範是什麼？它又是如何產生的呢？
我們回看歷史，會發現研發規範是伴隨着上世紀 60 年代開始的軟件危機而產生的。在那個時候，軟件由過去個人或者小團隊的開發形式，逐漸向規模化、大團隊的開發模式轉變，軟件自身的複雜度變高了，軟件研發團隊的協作複雜度也變高了，出現了諸如軟件項目超預算、交付需求延期、交付質量低下、實現不符合需求等等問題。
軟件危機的主要原因，把它很不客氣地說：在沒有機器的時候，編程根本不是問題；當我們有了電腦，編程開始變成問題；而現在我們有巨大的電腦，編程就成爲了一個同樣巨大的問題。
— 艾茲赫爾·戴克斯特拉， 謙遜的程序員， 《Communications of the ACM》
爲了解決軟件危機，軟件工程出現了，而研發規範是軟件工程實踐的組成部分。
研發規範的目標，是爲了解決或降低出現軟件危機的風險。 其首先要解決的，是隨着軟件複雜度提高和團隊規模變大，所帶來的協作低效的問題，比如實現與需求不符、項目難以管理等。
所以，研發規範首先包含了研發過程中的協作規範，比如需求從提出到交付的流程規範、代碼從開始開發到應用發佈的分支規範等，這些規範本質上都是爲了解決軟件研發過程中不同團隊、不同角色之間的協作問題。除了流程，協作規範還會定義需求的描述規範、代碼的提交規範等，通過規範化的方式保證信息的完整性和傳遞的有效性。
另一方面，軟件工程的發展，產生了很多優秀的工程實踐，比如實例化需求、測試自動化、代碼靜態分析等，這些實踐有着一定的學習門檻和執行成本，但如果使用得當，則可以幫助提升軟件的研發效率和質量。因此，研發規範也會包含必要的工程實踐，以規範的形式要求研發人員遵守並執行，一方面降低實踐的執行成本，擡高軟件研發的效率和質量底線，另一方面通過這種方式提升研發人員的工程 素養。
在某些企業，研發規範會制定得非常詳細，包括：
- 需求管理規範：定義如何收集、記錄、分析、驗證和管理來自業務和產品的需求，包括需求的模板、需求分析實踐、需求流轉流程等。
- 代碼管理規範：定義代碼庫的組織結構、分支策略、提交規範、合併流程、代碼規範及如何處理衝突等，也包括代碼評審的實踐、代碼質量的實踐等。
- 製品管理規範：定義製品庫的組織結構、製品的存儲方式、製品的版本控制、製品的依賴管理以及如何發佈和分發製品等。
- 測試管理規範：定義如何組織和執行軟件測試活動，包括所用到的測試手段如單元測試、集成測試、驗收測試等，也包括具體的測試實踐，如契約測試實踐。
- 自動化測試規範：是測試管理的一個子集，專注於測試自動化的實施，包括自動化測試工具的選型、用例的設計、開發、維護和執行流程等。
- 生產發佈規範：定義如何將軟件經過開發、測試，最終部署到生產環境的實踐和流程，包括版本的管理、部署流程、發佈審批、回滾策略、監控和告警設置等。
- 服務治理規範：定義服務級別、服務發現、負載均衡、熔斷、限流、降級處理等方面的策略和流程，也包括如 AB 測試等工程實踐。
- 安全研發規範：定義整個研發生命週期的安全措施和流程，涵蓋需求分析、架構設計、技術實現、測試驗收、生產發佈等各個階段，包括需求安全、安全架構、安全編碼實踐、漏洞管理、密鑰和證書管理、合規性檢查等方面。
- 等等
📝 小結： 研發規範以解決或降低出現軟件危機的風險爲目的，期望通過規範的方式保障軟件按時、按質地交付。研發規範包含爲解決團隊內外研發協同問題而產生的協作規範，和爲提升團隊工程水平而產生的工程實踐規範。
研發規範落地的難點及流水線的侷限
距離研發規範的誕生過去了半個多世紀，很多研發團隊依舊在與需求交付延期、軟件質量低下等問題做着艱苦的鬥爭。顯然，大家在落地研發規範的過程中遇到了困難。難點在哪裏呢？
我的觀察是，很多團隊都能輕易地制定出文檔化的研發規範，但研發規範紙面上的精準很難轉換爲團隊工作中的習慣。更難的是，隨着業務的發展和團隊的變化，研發規範也需要經常更新，如何讓大量的研發人員能夠及時更新工作實踐，以符合新的研發規範，並避免切換期間的混亂，是一個成本很高、又經常被吐槽的事情。
如何讓研發規範不只是停留在紙面上？
很多團隊想到了將研發規範定義在工具上，期望研發人員只要用這些工具，就必須遵守研發規範。這也是很多企業採購或自研研發工具的初衷之一。在這種模式下：
- 企業會將代碼、製品等研發資產都託管到代碼庫、製品庫等工具上，並通過分支保護策略、製品晉級機制等手段，將原本定義在文檔中的代碼規範、製品規範交由代碼庫、製品庫工具來承載。
- 另一方面，企業會找到一款流水線工具，按照研發的各個階段，定義多條流水線，例如：開發流水線、測試流水線、生產流水線，在每條流水線定義好要執行的步驟，比如：單元測試、代碼掃描、自動化掃描等。
- 最後，企業會將這些代碼庫、製品庫和流水線都定義成模板，後續團隊都基於這些模板來創建代碼庫、製品庫和流水線，就自然而然會遵守研發規範了。
下面是我在 2020 年編寫的某個基於代碼庫和流水線的研發規範落地示例。
研發規範（示例）：
- 任何特性開發都起始於 feature 分支，feature 分支從 develop 分支拉取
- feature 只有完成需求開發並通過功能測試和代碼評審後，才能合入 develop，進入集成測試階段
- 集成測試階段驗證通過，並獲得待發布准入，合入 master，進入發佈階段
- 發佈階段必須從 master 分支有新的合入開始，且獲得發佈准入後，才能進行生產部署
- 任何一個階段失敗需要修復，都需要從 feature 階段重新開始
工具落地（示例）：
- 在代碼庫中將 develop 和 master 都設置爲保護分支
- 分別爲 feature 分支、develop 分支和 master 分支各配置一條流水線（見下面 3 張示意圖）
開發流水線
集成流水線
發佈流水線
這種方式看起來很完美，但執行的時候對工程師的要求仍然較高，比如如果在集成階段出現一個缺陷，工程師可能會跳過 feature 階段流水線，直接將改動合併到 develop 上。因此實際落地的效果通常不如預期，且隨着時間的推移和規範的更新，只有一小部分規範能被嚴格執行，其他的又迴歸紙面了。
造成這種狀況的原因是什麼？因爲研發規範從文檔變爲工具上的配置的時候，經過了轉換和妥協，導致操作對象的變化和關鍵環節的丟失。即落到工具上的研發規範，跟文檔形式的研發規範，已經不一樣了，有些概念變了，有些環節丟了，原本完整的規範，經過這一變化，出現了錯漏。
我們舉幾個例子，來看下這種因爲工具導致的研發規範妥協的問題：
例子 1：代碼提交規範
規範：代碼的每次 commit 都應該爲解決某一個需求或缺陷服務，commit 的提交信息中都應包含以 #<需求 ID> 的形式定義的需求 ID，且該需求爲當前項目中的有效需求。
工具：定義代碼庫的 push 規則，要求 commit 的提交信息必須符合正則表達式 ^fix #[A-Z]+-[0-9]+。
說明：按照規範，每次提交都要對應一個有效的需求，但是代碼庫裏的檢查，卻只檢查了提交信息是否符合某個格式，對需求的有效性並沒有做校驗。於是，沒有與任何需求有關的 commit 同樣可以推送上來，導致這個規範的實踐效果打折扣。
例子 2：提測規範
規範：測試只接受自測完成且冒煙測試通過的版本，需求開發完成並滿足上述條件，纔可提交測試驗證。提測時需填寫提測單，註明待測的需求、應用版本，並附上自測的報告和冒煙測試的通過報告。如果有新的提交，也需要確保自測和冒煙通過後再流轉到測試。
工具：爲開發和測試配置不同的流水線，開發流水線執行通過後，開發人員通過 OA 工具或測試平臺填寫提測表單。測試人員收到提測表單後，按照表單內容準備環境，執行測試流水線。
說明：按照規範，只有經過自測和冒煙的需求，纔可提交測試，且需要保證測試驗證的版本與開發自測的版本一致，但實際開發和測試在各自不同的流水線裏工作，雙方的協作依賴第三方的表單或工具，無法保證測試執行與開發自測的是同一個版本。另外，工具也無法確保開發人員有新的提交後，也會遵循通過自測和冒煙再流轉到測試的約定。
例子 3：發佈准入規範
規範：任何線上發佈均需要提交發布單，說明涉及到的需求和應用列表，由團隊負責人、安全負責人、測試、運維審覈通過後，纔可進行發佈。
工具：發佈工程師通過 OA 工具填寫發佈單，交由相關人員審批，審批通過後，發佈工程師運行生產流水線，如果遇到問題，線下找相關人員修復，再重新運行生產流水線，直到發佈完成。
說明：按照規範，未經過發佈准入的應用無法執行發佈操作，但實際審批與執行是獨立的兩個工具，由發佈工程師自覺遵守發佈紀律，保證只有經過審覈的發佈才能執行，且需自覺保證實際發佈的範圍與審批的範圍一致，比如該合到發佈分支的代碼都合入了，且沒有未經審覈的需求被帶進來。
上面的 3 個例子體現了工具對研發規範的 2 種形式的限制：
- 關鍵驗證點因爲數據未聯通或聯通成本高，導致無法有效驗證，如例子 1：代碼提交規範。
- 流程的兩個相鄰階段因爲在工具上各自獨立，無法線上自動連接，如例子 2：提測規範和例子 3：發佈准入規範。
嘗試基於流水線來解決決上述問題
一開始，我們嘗試基於流水線來解決這些問題，以提測的場景爲例，我們嘗試過 2 種方法：
1. 用一條流水線串聯開發到測試的整個流程
這種方式下，每次代碼提交都可能會觸發整個流程的執行，但大部分都是不需要提測的。當某個時間點，開發完成，需要手動點擊提測按鈕，進入到流水線的後半部分。這就導致了流水線運行歷史中存在大量的阻在提測步驟的記錄，且每次有新的執行都需要重新提測。
2. 讓開發流水線完成後自動觸發測試流水線
這個方案通過自動觸發的方式，將兩條獨立的流水線串聯了起來，但是不觸發測試的時候開發流水線的結束狀態就比較奇怪了。可能是失敗，也可能是跳過，都不太合理。另外，測試流水線仍然是可以獨立運行的，因此無法控制只有前序開發流水線通過後，才能運行測試流水線，需要依靠團隊的自覺。
這兩個方法都未能完整解決提測場景的問題，其它的幾個場景也類似。這個時候，我們開始認識到，流水線的定位是一個工具，而我們想定義的是一個解決方案，兩者之間在關注點上存在差距，我們得跳出流水線工具，在 DevOps 層面重新思考這個問題。
📝 小結： 工具決定了研發規範的落地方式，而對於工具的妥協也影響了研發規範的落地效果。流水線受限於工具的定位，無法解決研發規範的落地問題，需要在更高的層面來解決。
Aone 帶來的啓發
阿里內部有個自研的研發工具平臺叫 Aone，數萬人在上面進行研發協作。之前雲效和 Aone 由同一個團隊負責，兩者產品模型有差異，但很多基礎能力是通用的。在商業化的初期，雲效推出過一個 RDC 的版本，在模型上與 Aone 非常像，但也正因爲與 Aone 的相似性，導致非阿里出去的用戶對很多概念難以理解，使用方式也不習慣。於是，在 2020 年的時候，雲效又推出了一個全新的版本：雲效 2020。在這一版本中，雲效變成了松耦合的多個基礎工具的形態，包括 Codeup、Flow、Packages、Projex 等，各個工具既可以獨立使用，也可以組合和互相打通。
雲效 2020 比較好地滿足了廣大小微團隊的訴求。但是很多中大型的研發團隊，會發現基於這套產品做研發協同，過於靈活了些，管不住是很多人面臨的問題。
這時候，我們意識到對於中大型的研發團隊，他們都有自己的研發規範，靠這種松耦合的基礎工具組合是很難支撐研發規範的落地的。而回過頭來看 Aone，作爲一個深度定製化的產品，它很好地支撐了像前面提到的發佈准入規範、安全規範等在阿里巴巴的落地，也成爲了技術線對工程實踐進行治理的主要入口，顯然它解決了阿里巴巴自己對於研發規範的工具化落地訴求。
那麼，我們能從 Aone 得到什麼啓發呢？
啓發 1：應用作爲研發工作的主入口
Aone 在項目之外，還有一個名爲應用的研發工作的空間。項目和應用在設計初衷上有明顯的區別，項目用於需求協作，更多地關注需求的流轉和交付；應用用於開發、測試和部署發佈，更多地關注工程交付。Aone 的應用，包含了跟這個應用相關的代碼、配置、團隊、環境、應用從開發到部署上線的流程、以及額外的管控策略如安全策略、發佈策略等。
每個應用都有確定的歸屬團隊，由這個團隊負責其開發、測試、部署、運維直到生老病死。這種工作方式與當前很多敏捷型團隊的實踐如出一轍。應用的這種定位，使其非常適合承載研發規範。
啓發 2：流水線掛在應用下，按環境排列
Aone 給我們的第二個啓發，是流水線的管理方式。
流水線有兩種常見的組織形式：一種是以 Jenkins 和雲效 Flow 爲代表，每條流水線都是獨立的，通過建立分組和標籤人爲地進行分類；另一種是以 Gitlab 和 Travis 爲代表，流水線是屬於代碼庫的，每個代碼庫可定義自己的流水線。這兩種方式，當團隊上規模之後都有問題。第一種方式遇到的問題是流水線太多造成的管理難題；而第二種方式的主要問題是當代碼庫爲大庫，包含多個應用代碼，或者從代碼提交到部署要經過多個頻率不同的階段時，流水線與代碼庫之間很難一一對應，常常需要做很多妥協。
Aone 採用了另一種流水線組織方式：按應用組織流水線。這種方式並不只是簡單將多條流水線按應用分組到一起，而是將流水線直接作爲應用的一部分。應用中的流水線，其代碼庫是確定的，這就避免了流水線影響其它應用。同時，Aone 收口了應用的部署，且在流水線的創建上通過內置的模板做了全局管控，將發佈准入等卡點內嵌到了流水線中，由大團隊管理員統一管控，從而保證了發佈的安全可控。像雙十一的封網，某些核心應用的強制分批發布，就是在這一管控基礎上實現的。
啓發 3：分支模式內置在應用中
Aone 帶來的第三個啓發，在於分支模式的內嵌。
作爲企業內部的研發工具平臺，Aone 可以按照整體架構的要求，規範每個應用的分支模式，並在工具上，對其中某些分支模式做深度的集成。好的方面，任何一個開發者，進入到應用的開發中，他的工作方式都必須遵循這個應用的分支模式，否則流程上無法往下走；不好的方面，正由於分支模式的深度集成，導致支持更多的分支模式時，Aone 需要付出很多額外的成本。因此在面向更廣泛的場景時，產品的設計者需要在深度集成與支持廣度上進行取捨。
啓發 4：以變更作爲應用交付的主對象
Aone 帶給我們的最後一個啓發，是變更這個阿里特有的工程交付概念。
本質上，Aone 定義在應用內的變更，約等於應用的一個 feature。任何一次應用交付，都以創建變更作爲起點，經過各個流水線階段，直到生產發佈完成後關閉。Aone 給我們展示了這一概念的具象化定義，以及實際應用的場景和優勢。例如，某團隊強制要求所有的應用開發都要關聯需求或缺陷，因此，開發者拿到一個需求，進入開發的第一步，就是在應用上創建變更，並關聯需求。
變更的主體是應用，這一設計讓開發者更傾向於以單應用持續部署的思路去進行開發、測試和發佈。更爲重要的是，由於有變更以及變更和需求的關聯關係，研發效能的度量有了客觀和精細化的數據基礎。
📝 小結： 讓研發規範管得住是中大型研發團隊的核心訴求。作爲一個內部的研發工具平臺，Aone 很好地支撐了阿里巴巴研發規範的落地，通過 Aone 這個例子，我們發現以下 4 點對於管住研發規範有很大的幫助：
- 統一應用研發和運維的入口爲應用
- 按應用統一編排流水線，並通過流水線模板進行全局管控
- 應用內置分支模式
- 顯式定義開發任務（Aone 稱之爲變更），並用其串聯應用交付全過程
我們的解決方案及背後的設計
在問題的牽引和 Aone 的啓發下，我們經過多輪迭代，最終形成了阿里云云效的一個新的子產品：雲效應用交付平臺 Appstack，並在該子產品中引入了 2 個新的概念：研發流程、變更。
接下來，我會分享下背後的一些設計思路。
尋找 DevOps 的模型
在早期對這個問題和解決方案進行跨角色討論的時候，我們遇到了一個非常典型的問題：
由於研發規範涉及到的概念較多，溝通的時候，不同的角色很難在同一個維度討論，導致溝通的效率非常低，以致於很難得到結論。
這是一個非常常見的（業務）需求分析問題，當業務、產品、技術等擁有不同背景的成員在一起討論某個需求的時候，需要保證大家對需求有一致的理解，既不能太偏向技術術語，又不能與技術實現映射不起來。
我們解決這個問題的方法類似 DDD，各個角色一起面向 DevOps 的領域模型進行問題的討論和場景的梳理。有興趣的讀者可以查看 BizDevOps 白皮書，裏面對這個模型有系統的解釋。
參考：必致（BizDevOps）白皮書2022-藏經閣-阿里雲開發者社區 [ 1]
基於模型討論最大的好處是所有參與方可以在相同的上下文語境下討論，通過問題和研發場景牽引模型的演進，進而推動產品的迭代更新。
下圖是研發流程相關模型的精簡版。
可以看到，我們繼承了 Aone 的應用和變更的概念，但在應用的流水線之上加了一層研發流程，這幾個對象構成了應用交付域的核心模型。
研發流程 = N * 流水線 + 管控
我們對研發流程的定義爲：研發流程是多條流水線的順序組合，每條流水線代表一個研發階段，可獨立運行，但又受到定義在研發流程上的管控策略的約束。其表現形式類似下圖：
在這張圖中，一個研發流程按執行階段劃分爲 n 條流水線，每條流水線都有在研發流程中定義的管控規則，比如測試准入規則。
管控規則包含哪些內容？爲什麼定義在流水線之外呢？
簡單來說，管控規則包含的是對一系列鍵值對的檢查，這些鍵值對來源於該條階段流水線外部的執行記錄，如另一條階段流水線、外部安全工具等。比如，每一條階段流水線執行完畢後，都會記錄一個鍵值對，標識這次所驗證的對象的執行結果是否成功。正因爲管控規則的數據都來自於當前流水線之外，且作用於整條流水線，其配置就更適合放在流水線之外了。
基於這一設計，我們第二章的研發規範，可以表示爲如下形式：
變更背後的設計
細心的讀者可能會發現，在上一節我們討論研發流程的管控規則的時候，提到會將流水線執行記錄標記到某個對象上，那麼這個被標記的對象是什麼呢？
這一塊是我們在建設過程中討論時間最長和爭議最多的部分。從原始訴求的角度，我們需要一個對象來全流程跨階段記錄驗證結果，作爲管控規則的准入；從技術實現的角度，已有的對象（分支、代碼 commit、流水線執行記錄）都不合適，我們不得不創建一個新的對象來定義它。本質上，我們需要的是一個能聚合與某個交付有關的所有技術活動的對象，像極了平時常說的技術任務。
按照 BizDevOps 白皮書中的定義，我們認爲：變更請求是爲實現特定的產品需求或修復產品中的缺陷，某個應用所需要完成的工作。變更請求的視線，是包含設計、編碼、提交和部署等在內的完整過程。與分散的技術任務不同，變更請求聚合了爲響應特定產品需求，應用上所發生的所有技術活動。
變更背後是如何設計與實現的呢？
我們以上一節最後的示例爲例，我們希望，當某個 feature 分支在開發階段通過檢測併合入到 develop 分支後，能夠在集成階段自動識別它是否通過了開發階段的驗證。因此，我們會在創建變更的時候，關聯上明確的變更分支，作爲變更的源頭，之後在該分支上的所有提交和流水線執行，我們都會進行追蹤，並關聯到變更對象上。而管控規則，則是對記錄到變更對象上的數據的消費。將研發流程與其變更背後的數據分開看，大致關係類似下圖。
我們用研發流程和變更解決了某個應用的研發規範問題，那如何將這一規範批量落地到所有應用呢？我們的答案是使用模板並收口權限。歡迎查看我們前面的文章：如何批量管理上百個微服務，上千條流水線
引入研發流程後帶來的改變
現在我們通過兩張圖，看下引入應用研發流程後所帶來的改變。
先看沒有研發流程時的狀態，見下圖：
此時，企業的研發資產和研發活動，會按類型天然揉在一起，比如代碼都在代碼庫裏，環境都在集羣裏，測試都在測試庫裏。稍大一些的團隊，都擁有大量的資產，每天都會產生大量的活動，由於這些都是分散的，某一點的信息只在某些人的記憶裏，還可能出現偏差。日常研發活動中，團隊內和團隊間需要大量線下的協同工作，來保證整體工作往前推進，而如果遇到架構升級、資源優化、安全治理等橫向的工作，則需要由專人負責盤點和推進，往往曠日持久。另外，團隊內和團隊外，只能觀察到最上層的需求交付數據（假設需求管理執行完善）和最下面的單點活動數據（如代碼提交次數），這些數據無法建立起關係。在這種情況下，數字化的產研協同和效能改進無從談起。
再看引入了研發流程時的狀態。
在這一狀態中，無論是代碼、配置還是其它資產，均可以歸屬到某個應用上， 多個應用又可以按照邏輯關係，組合爲一個系統。更進一步，企業可以根據應用的所有者，做到按團隊和人來管理資產，資產的盤點和治理將是順理成章的事情。
另外，研發人員都以特性開始研發工作，每個特性的研發都需要遵守該應用的研發規範，且與該特性有關的所有研發活動都能被識別和管理起來。更進一步，由於研發活動都按照特性內生關聯在一起了， 企業可以基於每個特性研發活動的數據，及時發現可能存在的風險，並持續對研發規範進行優化調整。
📝 小結：
模型應當是開放的，與產品無關的。
模型比產品更貼近 DevOps 本質，應通過模型的升級來牽引產品的演進。
研發流程本質上是包含跨階段管控能力的多條階段流水線的編排，通過在流水線外增加管控能力，讓研發規範在單個應用可以被管得住。
我們假定每個研發活動都是有目的的，期望通過變更請求來描述這個目的，進而把聚合起來的研發活動，與需求協作連接起來。
我們期望通過使用模板和控制權限，達到在企業中批量管理研發規範的目的。
未來的研發規範會怎樣
前面我們一起看了看腳下的大地，現在讓我們仰望星空，思考未來的研發規範會有哪些變化？
在第一章我們提到，研發規範的出現，是爲了通過規範團隊的研發協同和工程實踐，降低出現軟件危機的風險。而軟件危機的根源在於軟件複雜度的提升及軟件團隊規模的變大。換言之，因爲當前軟件研發的主體是人，軟件活動受限於人自身的腦力和體力，是一個極爲耗時且容易出現偏差的活動。因此，如果軟件研發的主體發生改變，軟件活動的耗時大幅降低，軟件團隊的協作需求大量減少，研發規範必然會需要重新設計。
回顧研發規範出現後的幾十年，我們在軟件研發的工程效率上並沒有本質的提升。但 AI 成爲了最大的變量。隨着 AI 的發展，研發活動的參與者和主體都可能發生變化。在此，我不負責任地 YY 一下：
- 在 AI 時代，AI 工程師纔是研發活動的主體，人將成爲 copilot 和 observer。
- 爲 AI 工程師制定精細的研發規範，可能成爲組建 AI 工程師團隊的首要任務。
- 對 AI 工程師來說，專業工作和角色協同不再佔用大量時間，研發規範將會更爲精細和標準，軟件開發規範將會越來越靠近現在的工業生產規範。
- 安全將變得至關重要，業界將會出現研發規範的底線安全標準。
最後，如果您對雲效的研發流程感興趣，希望免費試用，或者是研發規範落地上存在困難，希望與我們交流，歡迎加入下方釘釘羣（羣號：72815007140）
相關鏈接：
[1] 必致（BizDevOps）白皮書2022-藏經閣-阿里雲開發者社區