重新构想支持：从 Slack 到 SUBNET

在 MinIO，我们做事方式与众不同。

2014 年我们开始创业时，在构建产品过程中，我们对对象存储市场的一切都提出了质疑，更像一家数据公司而非存储公司。我们从零开始，运用工程第一性原理、非凡的注重细节和对简单性的不懈追求。

我们认真关注了 重要的功能。擦除码、位腐蚀检测、加密和 WORM、持续复制、身份管理和全局联合。如果它能简化操作、提高可扩展性或增强企业级功能，我们就会努力实现，而且要做好。

这些努力已经取得成效。我们现在的 Docker 拉取次数近 2.3 亿，GitHub 星标数超过 16,700 个，有 390 多名贡献者和 4,800 名 Slack 频道成员。超过 50% 的财富 100 强企业在其组织内部使用 MinIO，配置范围从 S3 网关到大型分布式生产实例。我们在五大洲的生产环境中部署 MinIO，支持数十种用例。

这意味着我们必须支持五大洲的生产环境部署和数十种用例。

支持有两个层级：公共支持频道 和 订阅 SUBNET 频道。两者的基础相同，但体验会有所不同，这正如人们所期望的。

本文将介绍支持背后的理念以及支持机制。

公共支持频道

公共支持以我们的公共 Slack 频道和 文档 为中心。可以想象，这里没有 SLA 或响应保证，但 MinIO 工程师及其更广泛的社区会积极参与。这里有 4,800 多名成员，如果您擅长搜索，您的答案可能就在这里。这里有大量的流量，大约一半是传入的帮助请求（偶尔会有一些功能请求），另一半是对这些问题的回复。

如果不是，那么它很可能在我们强大的文档中。它内容全面、组织良好、易于理解，这与我在其他地方工作过的任何地方都不一样。我估计我们的文档减少了 30% 或更多 的支持量。

它真的很好。

我们的文档如此出色的原因之一是我们高度注重简单性。简单易懂的产品易于支持。

这非常重要。

由于我们对简单性的不懈追求，我们没有垃圾问题需要为我们的社区或 SUBNET 订阅者跟踪。我们不会花费时间排查由我们自己的软件引起的细枝末节/边缘情况，即使我们的开源许可证意味着我们在 无数配置中部署。

这让我们能够在公共方面和私有订阅方面走上不同的道路。

SUBNET 支持

SUBNET 是我们的订阅产品。它不仅仅是支持，但支持是其中很大的一部分。它专为在 MinIO 上拥有大型生产部署的企业设计，这些企业希望获得存储、云原生应用程序和文件系统领域顶尖人才的安心服务。

在构建我们的 SUBNET 支持系统时，我们采用了与构建对象服务器相同的做法，我们质疑一切，只构建必要的组件。购买现成的票务/支持系统很容易，实际上有几十种这样的系统，但这些系统并不能解决我们试图实现的目标。

我们的目标是通过对话实现快速解决问题的实时通信平台。

我们采用了在公共社区中使用的模型，利用 Slack 及其对话界面。我们改进了响应速度、支持工具和专注程度。我们还借鉴了 MinIO 在参与方面强调的文化。这个以工程为主导的组织有着强烈的集体责任感。结果是，每个人都深深地投入到客户的成功中。

在我们的模型中，我们不会对客户如何打开或处理问题施加规则或规定。如果您正处于一个关键问题中，您没有五分钟时间去弄清楚如何与某人取得联系。您希望能够解决问题的人能够随时提供帮助，并专注于您的问题。答案是有针对性的……编写代码的人是回答您问题的人，因此减少了许多探究性问题和数据收集工作。

有时，问题并不关键，但您已经花了很多时间思考它，您只是需要有人与您交流想法，同样，可用性和专业知识很重要。我们努力支持您的整个生态系统，因此我们可以推荐特定于您的环境的 MinIO 实施影响。

由于一切都是对话，该模型确保我们完全理解您要解决的问题，没有任何内容会在表格和时区之间丢失。

结果是一个与业界所知截然不同的支持系统，但要成功得多。我们用少数人就能做到的事情，其他组织则需要数百人才能做到。我在支持领域工作了十多年，我从未使用过如此直观和简单的系统。

其他系统专注于管理和票务流程。它们要求您花费时间管理票务，这会占用您完成实际目标的时间。即使管理票务的工作量只是中等，您仍然被迫进行一系列上下文切换，这会分散您对需要专注的內容的注意力。MinIO 方法的简单性确保了问题，即使是复杂问题，也能够获得应有的关注。这也有一个额外的好处，它使团队在解决问题方面更加高效，因为解决问题的工程师不必被迫进行上下文切换。

我们的方法有其影响。

其中之一是所有人都始终参与所有问题。因此，我们谨慎选择客户。由于我们是 100% 开源，客户可以自行支持，因此我们构建和定价 SUBNET 以吸引那些大规模部署我们软件的客户。因此，SUBNET 订阅者往往属于技术领域比较成熟的一端。当工程是您的支持时，这将带来更高的“热爱客户”指标，为双方带来更好的体验。

另一个影响是我们的方法导致更深度的参与。与大多数模型不同，我们会查看您的代码，我们会就最佳实施方式向您提供建议。我们这样做是因为它对客户有帮助，我们致力于他们的成功。这不能与服务或私有扩展开发混淆，我们不会参与其中，即使是七位数的金额也不行。

这种方法侧重于结果而非指标。客户是否解决了她的问题？是否令他们满意？结果会带来良好的指标，但这些并不是最终目标。对于一些客户来说，这需要一些时间来适应。他们（说实话，是采购团队）重视 SLA 和周转保证。即使他们也开始明白，我们可以在传统组织所需时间的几分之一的时间内实施修复或发布新版本（同样，不是定制的）。

结果非常令人鼓舞。我们的平均响应时间不到一个小时，许多问题在不到 5 分钟内就得到了关注。

同样，速度是一个指标，但它并不总是最好的指标。许多问题需要仔细思考和深入参与，让它们正确解决才是正确的指标，而不是让它们关闭以便它们在其他地方出现。

业内有些人会声称我们的模型不可扩展，您需要随着发展壮大而建立一个庞大的支持组织。这些公司不像我们一样坚持简单性。我们的营销人员在这里是因为他能够在不到十分钟的时间内将 MinIO 运行起来，尽管他对对象存储或分布式系统没有太多经验。他知道这与众不同。

这可以扩展，因为一切都与极简主义（简单性）有关，一切都是工程问题。随着我们的发展，我们将发展工程，而不是支持。集体所有权基因将是我们招聘中优化的内容。

我们对未来充满期待。我们的增长轨迹意味着我们将面临新的挑战。它将考验我们，挑战我们，但我认为我们潜在的理念、文化和对对话的承诺将引领我们前进。

欢迎加入我们的 Slack 频道，向我询问有关该方法的问题。我的用户名是 @Eco。