本文為 CODING 高階產品經理俞典在騰訊雲 CIF 工程效能峰會上所做的分享。文末可前往峰會官網，觀看回放並下載 PPT。
大家好，我是 CODING 高階產品經理俞典。DevOps 對於大家而言應該已經不是一個陌生的概念，它為研發團隊帶來了更快的交付速度、響應變化和更好的團隊協作方式，幫助企業實現幾天到幾周內交付和部署軟體。在 DevOps 流程中，大家可能更容易關注到程式碼、流水線、測試、釋出等工具帶來的效能升級，那麼我們在構建什麼、測試應用的來源是什麼、釋出什麼？——這三個問題的答案都是「製品包」。
軟體開發中的製品管理就如同傳統制造業中的貨倉管理，它連線著產品的生產和釋出兩個階段。前幾天我簡單統計了一下 CODING 研發團隊自身的製品資料，在一天中，整個團隊推送了 6000 多個製品，同時產生了 1 萬多次製品拉取操作。製品不僅數量大，還因為開發語言不同、面向的環境不同有著不同的屬性，需要分門別類的管理。而製品的推拉穩定性、安全性與資訊準確性決定了整個產品的生產質量。那麼圍繞企業級製品管理面臨的各種複雜問題，我今天為大家介紹 CODING 自主研發的企業級製品管理服務——「WePack」的設計理念和落地實踐。
說到痛點，大家可以和我一起來對你所在的團隊的疼痛指數做一個評估。首先是疼痛指數最高的一類使用者：我們之前遇到過很多的使用者，因為整個研發團隊有 Java、C++、前端等不同技術棧，生產的製品型別也各有不同。很多使用者使用傳統的 Ftp 或者 SVN 倉庫來管理軟體壓縮包，自己搭一個 Nexus 來管理開源的第三方 Maven、Npm 依賴。隨著容器映象的普及，研發團隊逐漸產生了一些 Docker 映象需要管理，於是使用者再自己搭了一套 Harbor 來管理映象。
這些系統各有各的一套管理體系和賬號體系，給運維人員帶來了較高的管理成本。製品的管理尚且沒有打通，和其他 DevOps 模組的打通就更是難上加難。因此集中管理製品是企業使用者建立 DevOps 製品管理體系的第一步。
很多使用者意識到了這個問題，因此開始基於 Nexus 這樣的開源製品庫自建，或者採買 JFrog 這類統一的製品管理平臺來管理製品。此時集中化的管理又帶來了新的問題：這些工具雖然提供了統一的賬號、許可權管理功能，讓我們能夠統一管理所有的團隊製品，但隨著企業產品規模的擴大，集中在一起的製品如何劃分管理許可權成為了問題。比如這時一旦有新的專案誕生，或者臨時專案、外包專案出現，製品管理員就需要重新為整個企業的使用者組，配置這些新專案的各種許可權；沒有專案隔離的製品管理也會產生安全問題，這將給運維團隊帶來很大的負擔，讓製品管理成為 DevOps 流程加速的瓶頸。
當我們解決了前面兩點製品管理的單點問題後，新的問題來了：由於製品管理承上啟下的屬性，需要和上下游的工具進行資訊與功能呼叫的整合。很多企業在 DevOps 的每一環選擇了不同的工具，那麼就會需要進行若干次的整合與對接。許多企業選擇購買如國外的 Azure、Gitlab， 或者國內的 CODING DevOps 這樣的一站式產品來解決多次整合的問題，好不容易打通 DevOps 工具鏈，但是又出現了新的問題。
我們在面對很多私有化的客戶時，都提到了對於製品安全掃描功能的需求。無論是出於國家安全監管規定，還是企業自身的資訊保安訴求，DevSecOps 的概念出現了。
有的客戶購買了 Black Duck、Checkmarx 這樣功能強大的安全工具，可以掃描出各種漏洞，並提供多維度的統計報告，但是這個報告只停留在安全工具系統中，最多可以展示在 Jenkins 的外掛中。如何把這些漏洞拆分到對應的專案團隊去解決，為這個報告找一個負責人，並且追蹤報告內漏洞的解決情況？這些工具其實都沒有提供解決方案。這是安全工具和 DevOps 工具鏈割裂而造成的問題，同時因為這樣的割裂，我們很難建立起一個自動化的管控流程來限制安全問題的右移。
還有一個關鍵問題是這些安全工具掃描出的漏洞很難被修復。我們無法迴避大多數研發團隊的安全能力都是有限的這一現狀，可能一個團隊有 100 個研發，只有 1 個安全人員，他無法兼顧到整個團隊引入的安全問題。並且目前安全工具提供的漏洞資訊和解決方案還是相對專業，可能一個普通的開發都難以理解安全軟體提供的修復建議，他按照建議進行了修復，其實也沒有比他更專業的人員去驗證結果，而英文資訊也加大了這一過程的難度，因此修復安全漏洞比發現漏洞難得多。
圍繞這些層層遞進的痛點，我們希望提供給使用者一套完善的製品管理解決方案，因此誕生了企業級製品管理服務——「WePack」，接下來我將為大家介紹 WePack 的設計理念。
我們在設計 WePack 時，首先考慮的便是製品管理最基本的痛點——集中管理的問題。我們希望 WePack 不單是做到製品型別的統一，還可以統一管理企業內部自研的第一方構建包、第二方的平臺基礎製品包、以及來自外網的第三方開源元件，保證自研製品在研發、測試、釋出的生命週期資訊得到記錄，而第三方製品的來源與使用資訊都可以在 WePack 系統中追溯，以此建立起企業唯一的可信製品來源。
同時，由於企業製品管理對於精細化許可權、專案資源隔離的訴求，WePack 沿用了 CODING 經過使用者驗證的許可權管理體系。普通的製品管理工具，比如 JFrog Artifactory、Nexus 的使用者管理體系。企業下若干個專案組共享所有制品資源，製品僅通過倉庫隔離。面對擴張的專案管理需求，使用者就需要靠增加節點來實現專案許可權隔離。最近這些工具也意識到了多專案管理的問題，推出了 Project-based 的產品能力，但專案的個數卻受到付費等級的限制。WePack 繼承了 CODING 專案的管理層級，為使用者提供了名稱空間的管理層級，名稱空間也可以理解為專案或者研發團隊，可以用於管理不同的使用者組，給這些使用者配置不用的製品操作的許可權。系統內的使用者可以隨時加入或退出名稱空間，且名稱空間的個數也沒有限制，企業因此無需擔心臨時專案和外包專案的管理成本。
WePack 目前的許可權粒度精確到了倉庫層級，企業管理員可以通過設定倉庫可見範圍和使用者組，對指定倉庫的製品操作許可權實現精細化的控制，滿足企業複雜的許可權管理訴求。我們同時也在規劃將這一許可權粒度再細化到製品層級。
介紹了 WePack 基本的設計理念後，可能有些熟悉 CODING 的朋友會產生一個疑問，無論是公有云還是私有部署版的 CODING DevOps 中已經有了製品管理這一個模組，為什麼還要單獨設計一款私有化場景下的製品管理單品系統呢？我們主要有以下三個方面的考慮。
首先，CODING 製品管理可以幫助使用者實現基本製品管理功能，連線上下游 CI/CD，彙集資訊，打通整個 DevOps 流程。而對於軟體開發、測試、生產等多環境隔離的使用者，他可以選擇部署多套 Wepack 在多個環境，通過製品同步功能將各個環境打通。或是製品需要分發到多個地域的使用者，在每個環境或是地域部署一套 CODING 顯然是不合適的，而 WePack 可以幫助他們實現各個環境、地域的製品集中管理。
另一方面，許多使用者如果已有自建的 DevOps 工作流，WePack 也能提供很好的開放能力，幫助使用者將製品管理模組和自建的工具便捷打通，實現資訊的匯聚。
最後，製品其實和程式碼一樣，是企業的核心資源，無論是公有云還是私有云，都可能需要這樣的一套系統，在相對隔離的環境單獨儲存製品資源。
接下來我將會詳細介紹 WePack 的功能設計。首先是一些製品管理的基本功能：WePack 目前已經基本覆蓋了主流的製品型別，可以實現多種型別的製品統一管理。並且不同於市面上大多數製品管理工具只提供製品檔案結構資訊，WePack 還展示了製品自帶的描述、標籤、大小、Readme 等後設資料資訊，在製品被推送到 WePack 中時，就能展示製品資訊。在製品的版本管理上，使用者可以通過靈活的版本管理策略，設定製品版本是否可以被覆蓋。在第三方依賴包的管理功能支援上，WePack 提供了製品代理功能，可以將外網的公共製品代理到系統內，配合製品掃描的功能保證開源元件的安全性和可操作、可追溯。
對於上文提到的多環境、多地域的管理訴求，我們提供了製品同步功能來實現製品的跨環境、跨地域流轉。製品同步功能支援將系統內的製品推送到遠端倉庫，也可以將遠端倉庫的製品拉取到本地倉庫中。詳細的實踐案例將會在後文說明，也可以加深對該功能的認識。
WePack 支援靈活對接各種物件儲存產品，也支援使用者對老舊制品進行清理，釋放儲存空間。值得一提的是我們已經支援了 Docker 版本的不停服物理刪除。
最後一個基本功能是製品掃描。我們在掃描能力上選擇了和騰訊安全的專業團隊進行合作，由他們提供不同的安全底層能力的支援，這使得我們的安全能力具備很強的準確性與專業性，滿足對安全有較強訴求企業的製品管理需求。
這是 WePack 的基本功能，接下來我將介紹 WePack 在 DevOps 工作流上的一些應用。WePack 除了後設資料外，還提供了製品屬性的功能，任何資訊，例如程式碼、Commit、構建環境資訊、測試是否通過資訊、質量檢查資訊等都可以被記錄到製品中。同時 CODING 的製品推送外掛，除了可以幫助使用者通過 CODING CI 將製品推送至 WePack 製品倉庫中，還會自動將構建環境中的資訊寫入製品管理系統中，同時我們也提供了 Jenkins 外掛來支援該功能。
那麼提到質量管控的流程，無論是 CODING 中的製品管理還是 WePack 系統中，我們都開通了製品掃描模組，用於當前環境開源元件的漏洞掃描。我們在製品掃描功能中，加上了流程管控的能力，可以在掃描結果出來的當時就禁止有問題製品的下載，這樣便只有安全的、通過檢查的製品才可以流入下一個環節。此時如果開發發現依賴的元件拉取失敗，就可以追溯到失敗原因，去解決有問題的製品。得益於我們打通了漏洞的發現與製品流動的流程管控，可以實現有效地管控安全問題的右移。
在製品的質量、安全職責的問題上，我們避免了將製品掃描這個功能獨立於 DevOps 流程之外，而是隸屬於整個 WePack 團隊/專案的管理層級。我們可以給一個名稱空間的專案組，或者一個製品倉庫配置一個掃描方案，也可以基於一些篩選規則配置一個掃描方案，製品的負責人便可以只關注他許可權範圍內的製品漏洞結果，做到誰的問題誰來解決。
那麼我們在功能設計上，如何幫助研發團隊更好更方便地去修復安全漏洞？首先在漏洞資訊中，使用者可以定位到漏洞所屬的依賴元件，通過我們提供的依賴分析功能，使用者可以找到有問題的元件被哪些生產製品所依賴，以此去定位修復漏洞入口。同時為了避免開源漏洞不準確、商業使用者缺乏中文支援、資訊不夠透明等問題，我們與騰訊安全以及聯合實驗室進行了合作，騰訊安全的專業運營團隊基於通用的安全漏洞庫進行了安全研究，也會將他們的研究成果貢獻至例如 NVD 之類的開源漏洞庫中。根據他們的研究成果，騰訊安全建立了一個自研的軟體開源漏洞特徵庫，大幅降低了漏洞的誤報率，同時提供了中文的漏洞資訊、漏洞元件修復版本資訊等等。
我們的製品掃描引擎在解析出製品依賴後，會訪問漏洞庫的服務，輸出製品掃描報告，然後再寫入 WePack 系統中。在優化漏洞資訊後，我們希望避免使用者一次性關注到太多不重要的漏洞，因此定義了漏洞的修復優先順序。除了像 CVSS 提供的安全等級，騰訊安全還結合了漏洞的動態安全等級，也就是說現在是否有公開的漏洞利用 POC 披露，來定義該漏洞現在是否優先推薦使用者修復。這樣使用者可以去優先關注真正對研發環境有威脅的漏洞並進行修復。以上便是 WePack 的基本功能。
接下來我將用兩個案例來演示 WePack 的落地實踐。首先是在金融行業的落地實踐案例。該客戶有很強的管控規定，希望他的研發環境不能訪問外網，但是又希望能代理外網的一些開源元件，所以我們幫助使用者建立了一個網路隔離區，在其中部署 WePack。開源元件可以從這裡代理到網路隔離區的 WePack 系統中，並在此處被掃描，通過掃描的製品才能進入研發測試環境。同時客戶在其生產環境也部署了一個 WePack，與其他環境相隔離，通過我們提供的製品同步功能，使其在研發測試環境產生的可以被髮布的製品，能夠被推送至生產環境進行釋出。
第二個案例是在遊戲行業，該客戶的遊戲軟體包需要分發到多個地域，因此我們幫助他們在海外的多個節點部署了 WePack，通過製品同步的分發功能，他們生產的製品包可以被分發到多個 VPC 裡的 WePack，通過不同 VPC 的生產叢集去拉取製品進行跨地域部署。
以上便是兩個具體客戶的落地案例。關於 WePack 的未來規劃，主要分為兩個方面：首先在安全管控能力上，我們希望能提供給使用者更細粒度的許可權管控能力，能夠幫助使用者實現資源粒度的許可權控制。同時我們也會繼續深化安全能力合作，不斷提升製品安全檢測與管控能力。第二點是我們希望能夠將資訊收集和打通功能做得更加完善，讓 WePack 與企業的研發管理訴求相結合，中轉研發 - 構建 - 質檢 - 釋出資訊流。同時我們也會提升上下游工具和部署平臺相容能力，滿足企業的多樣化工具鏈與多種部署需求。
點選即可觀看 CIF 峰會回放
