跳到主要内容

Conda-Forge 运营风险

·5 分钟阅读
Christopher J. 'CJ' Wright
Christopher J. 'CJ' Wright
conda-forge/core 成员

最近我一直在思考运营风险（op. risk）。运营风险源于流程的失败，例如遗漏的电子邮件，或自动化软件系统无法正常运行。许多商业机构对最小化运营风险很感兴趣，因为它是一种不产生价值的风险，与投资相关的风险相反。这也是我在Lab49担任软件工程顾问，专注于金融机构的工作中思考的问题。我认为这对于 Conda-Forge 也有一个很好的类比，即使我们不是商业机构。在这种情况下，我们承担的风险不是潜在的收入损失，而是用户和维护者因错误和糟糕的用户体验而产生的挫败感。在这篇文章中，我将探讨 Conda-Forge 运营风险的三个主要来源：自动化、自上而下的控制和自助服务结构。

Conda-forge 简介​

Conda-Forge 是一个围绕为 conda 软件包管理器构建软件包而发展起来的生态系统和社区。Conda-Forge 使用持续集成服务从名为 feedstock 的 GitHub 仓库构建软件包。这种结构使贡献者团队能够通过基于拉取请求的工作流程来维护软件包。在撰写本文时，Conda-Forge 拥有超过 10000 个 feedstock，每月交付超过 1.2 亿个软件包。

自助服务结构​

Conda-Forge 围绕每个 feedstock 生命周期阶段的自助服务结构构建。新 feedstock 的创建依赖于潜在的维护者向 staged-recipes 提交 PR。虽然特定语言的帮助团队和 staged-recipes 审查员提供了一些协助和监督，但 PR 提交者在提议软件包并引导其被接受方面起着最重要的作用。一旦 feedstock 被接受，维护工作就会联合起来，大部分维护工作由维护者执行，他们对 feedstock 拥有广泛的权限和控制权。如果软件包需要修复或更新，鼓励维护者和用户打开他们自己的拉取请求。

这种结构可能会给最小化运营风险带来一些挑战。最重要的挑战是 feedstock 维护者和用户之间的脱节。虽然大多数维护者是软件包用户，但我们的大多数用户不是维护者，并且不太可能成为维护者。维护者和用户之间的差距可能来自几个方面，有些在我们控制之下，有些则不然。例如，我们可以编写更好的文档，降低入门门槛，但我们无法控制用户的激励结构如何评估 Conda-Forge 的贡献。这在 Conda-Forge 组织结构中产生了一个代表性差距，非维护者用户的问题和需求无法传达给维护者和核心团队。

例如，我们是否满足了开发人员使用我们的二进制文件作为本地编译代码的依赖项的需求。再例如，在学术和政府实验室中使用 Conda-Forge 的开发人员和科学家是否存在支持方面的差距，他们可能没有技能或能力来修复 feedstock。我们对公共 GitHub 平台的依赖可能会阻止一些没有访问权限的用户提出他们的担忧。由于这些用户可能代表性不足，我们甚至不知道我们是否满足了他们的需求以及如何最好地提供帮助。

自上而下的控制​

虽然 Conda-Forge 的大部分权限结构是联合的，但某些重要部分是集中的，核心开发人员做出关键决策。通常，这些决策侧重于生态系统的稳定性，例如支持哪些语言版本。此外，Conda-Forge 基础设施的维护和增强主要由核心开发人员执行。

然而，核心开发人员通常是经验丰富的 feedstock 维护者、conda 专家用户，并且已经融入了 Conda-Forge 生态系统和使命。这意味着在做出决策时可能缺乏新用户或维护者，或者对 Conda-Forge 方法持怀疑态度的潜在用户的观点。

例如，关于应用程序二进制接口引脚的决策通常由核心团队做出，尽管这些更改会对下游维护者产生影响。大多数维护者可能不知道这些引脚是什么，它们是如何更改的，以及这如何影响他们的 feedstock。

自动化​

自动化已被非常有效地用于使 Conda-Forge 成为可能。各种机器人和 Web 服务使 Conda-Forge 能够达到目前的规模，从运行构建、版本升级和检查 feedstock 质量等方面提供帮助和支持。然而，这种自动化带来了自身的运营风险，并放大了现有的运营风险。

自动化往往在我们最不期望的时候失败，而且我们常常缺乏修复它的能力。2018 年 1 月的 Travis-CI 宕机就是一个很好的例子，我们用于 macOS 构建的 CI 服务经历了容量下降，然后完全宕机，导致构建排队数天。最近，Azure 上的并行构建数量突然减少，导致类似的构建队列。自动化可能会导致问题，因为它使使用者能够在没有所有必要信息的情况下做出决策。虽然许多 feedstock 对其软件包进行了有效的冒烟测试，但 autotick 机器人目前不检查新的依赖项，这可能会导致软件包元数据丢失或不正确。

结论​

总的来说，Conda-Forge 在运营风险管理方面做得很好。最重要的是，Conda-Forge 透明的开源性质使我们能够通过与社区互动来正面解决这些问题。