跳到主要內容

Conda-Forge 營運風險

·5 分鐘閱讀
Christopher J. 'CJ' Wright
conda-forge/core 成員

最近我一直在思考營運風險(op. risk)。營運風險源自流程的失敗,例如遺失電子郵件,或自動化軟體系統無法正常運作。許多商業機構都有興趣盡可能降低營運風險,因為它是一種不會產生價值的風險,這與和投資相關的風險相反。這也是我在 Lab49 工作時會思考的事情,我在那裡擔任專注於金融機構的軟體工程顧問。我認為這與 Conda-Forge 也非常相似,即使我們不是商業機構。在這種情況下,我們承擔的風險不是潛在的收入損失,而是使用者和維護者因錯誤和糟糕的使用者體驗而產生的挫折感。在這篇文章中,我探討了 Conda-Forge 的三個主要營運風險來源:自動化、由上而下的控制和自助式結構。

Conda-forge 簡介

Conda-Forge 是一個生態系統和社群,圍繞著為 conda 套件管理器建置套件而發展起來。Conda-Forge 使用持續整合服務從名為 feedstocks 的 GitHub 儲存庫建置套件。這種結構使貢獻者團隊能夠透過基於 pull request 的工作流程來維護套件。在撰寫本文時,Conda-Forge 擁有超過 10000 個 feedstocks,每月運送超過 1.2 億個套件。

自助式結構

Conda-Forge 圍繞著自助式結構而建構,適用於 feedstock 生命週期的每個階段。新 feedstocks 的建立依賴於潛在的維護者向 staged-recipes 提交 PR。雖然語言特定的協助團隊和 staged-recipes 審閱者提供了一些協助和監督,但 PR 提交者在提出套件並引導其被接受方面發揮著最重要的作用。一旦 feedstock 被接受,維護工作就會被聯合管理,大部分維護工作由維護者執行,他們對 feedstock 擁有廣泛的權限和控制權。如果套件需要修復或更新,則鼓勵維護者和使用者開啟自己的 pull request。

這種結構可能會為盡可能降低營運風險帶來一些挑戰。最重要的挑戰是 feedstock 維護者和使用者之間脫節。雖然大多數維護者都是套件使用者,但我們的大多數使用者都不是維護者,也不太可能成為維護者。維護者和使用者之間的差距可能來自幾個方面,有些在我們的控制範圍內,有些則不在。例如,我們可以編寫更好的文件,降低入門門檻,但我們無法控制使用者的激勵結構如何看待 Conda-Forge 的貢獻。這在 Conda-Forge 組織結構中產生了代表性差距,非維護者使用者的問題和需求沒有傳達給維護者和核心團隊。

例如,我們是否滿足了將我們的二進位檔用作本地編譯程式碼的依賴項的開發人員的需求?再舉一個例子,學術界和政府實驗室中使用 Conda-Forge 的開發人員和科學家是否存在支援差距,他們可能沒有技能或能力來修復 feedstocks。我們對公共 GitHub 平台的依賴可能會阻止某些沒有存取權限的使用者提出他們的疑慮。由於這些使用者可能代表性不足,我們甚至不知道我們是否滿足了他們的需求,以及如何最好地提供幫助。

由上而下的控制

雖然 Conda-Forge 的大部分權限結構是聯合管理的,但某些重要部分是集中管理的,核心開發人員做出關鍵決策。通常,這些決策側重於生態系統的穩定性,例如要支援的語言版本。此外,Conda-Forge 基礎架構的維護和增強主要由核心開發人員執行。

然而,核心開發人員通常是經驗豐富的 feedstock 維護者、專業的 conda 使用者,並且已經認同 Conda-Forge 生態系統和使命。這意味著決策的制定可能沒有考慮到新使用者或維護者,或者對 Conda-Forge 方法持懷疑態度的潛在使用者的觀點。

例如,關於應用程式二進位介面 pin 的決策通常由核心團隊制定,儘管這些變更對下游維護者有影響。大多數維護者可能不知道這些 pin 是什麼、它們是如何變更的以及這如何影響他們的 feedstocks。

自動化

自動化已被有效地用於使 Conda-Forge 成為可能。各種機器人和網路服務使 Conda-Forge 能夠達到目前的規模,提供來自執行建置、版本升級和檢查 feedstock 品質的幫助和支援。然而,這種自動化帶來了自身的營運風險,並放大了現有的營運風險。

自動化往往在我們最不期望的時候失敗,而且我們常常缺乏修復它的能力。2018 年 1 月 Travis-CI 停機事件就是一個很好的例子,當時我們用於 macOS 建置的 CI 服務的容量減少,然後完全停機,導致建置排隊數天。最近,Azure 上的平行建置數量突然減少,導致類似的建置佇列。自動化可能會導致問題,因為它使使用者能夠在沒有所有必要資訊的情況下做出決策。雖然許多 feedstocks 對其套件進行了有效的 smoke 測試,但 autotick 機器人目前不檢查新的依賴項,這可能會導致遺失或不正確的套件元數據。

結論

總體而言,Conda-Forge 在營運風險管理方面做得很好。最重要的是,Conda-Forge 的透明開源性質使我們能夠透過與社群互動來正面解決這些問題。