重新想象支持：从Slack到SUBNET

我们在MinIO的处理方式有所不同。

在2014年成立之初，我们在构建产品时就对对象存储市场提出了所有质疑-认为它更像是数据公司，而不是存储公司。我们从头开始，使用工程第一原则，对细节的特别关注和对简单性的不懈追求，做到了这一点。

我们仔细注意了重要的功能。擦除代码，位腐检测，加密和WORM，连续复制，身份管理和全局联合。如果它使它变得更简单，更具可伸缩性或更适合企业使用，那么我们做到了并且做到了。

它已经付清了。现在，我们有近2.3亿名Docker拉手，超过1.67万名GitHub明星，390多名贡献者和Slack频道的4,800名成员。从S3网关到大型分布式生产实例，超过50％的财富100强企业在其组织内部运行MinIO。我们已在五大洲的生产环境中部署，支持数十个用例。

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

支持分为两个级别，即公共支持渠道和订阅SUBNET渠道。两者的基础都相同，但是经验可能会有所不同。

这篇文章涵盖了支持背后的哲学及其运作原理。

公众支持频道

公共支持集中在我们的公共Slack频道和我们的文档上。可以想象，那里没有SLA或响应保证，但是MinIO工程师及其更广泛的社区积极参与其中。有超过4,800个成员，如果您精通搜索，您的答案可能在那里。这里流量很大，其中大约一半是传入的帮助请求（这里和那里有一个关闭功能请求），另一半是对这些问题的响应。

如果没有，则可能在我们强大的文档中。它是全面的，组织良好的并且易于理解，使其与我工作过的其他任何地方都不同。我估计我们的文档将使我们的支持量减少30％或更多。

就是那样

我们的文档如此优秀的原因之一是我们过于关注简单性。简单的产品很容易解释。并且易于支持。

这是巨大的。

由于我们孜孜不倦地追求简单性，因此我们的社区或SUBNET订户都不会遇到垃圾问题。即使我们的开放源代码许可证意味着我们部署在无数种配置中，我们也不会花时间对由我们自己的软件引起的细节/角落情况进行故障排除。

这使我们在公共和私人订阅方面都走了一条不同的道路。  

子网支持

SUBNET是我们的订阅产品。它不仅是支持，而且支持是其中很大的一部分。它是为那些在MinIO上进行大规模生产部署并希望在快速拨号上具有存储，云本机应用程序和文件系统方面的一些最佳思想的企业而设计的。

在构建SUBNET支持系统时，我们采用与构建对象服务器本身相同的方法-我们质疑一切，仅构建必要的东西。购买现成的票务/支持系统会很容易-实际上有几十个，但是对于我们要实现的目标来说，这还没有解决。

我们的目标是建立一个实时通讯平台，专门致力于通过对话实现快速解决。  

我们调整了用于公共社区的模型-利用Slack及其对话界面。我们改进了响应能力，支持工具和关注度。我们还借鉴了MinIO参与的文化重点。在这个主要面向工程的组织中，人们具有强烈的集体责任感。结果是，每个人都对我们的客户的成功进行了深刻的投资。

在我们的模型中，我们不对客户开放或处理问题的方式施加规则或规定。如果您遇到了严重的问题，则无需花五分钟的时间来弄清楚如何与某人取得联系。您希望有人可以解决问题，并积极参与并专注于您的问题。答案是针对性的……编写代码的人就是回答您问题的人，因此探查问题和收集数据的数量大大减少了。

有时，问题不是很关键，但是您花了很多时间进行仔细思考，而您只需要一个人就可以摆脱您的想法，而且可用性和专业知识也很重要。我们努力为您的整个生态系统提供支持，因此我们可以建议针对您的环境实施MinIO的建议。

由于所有内容都是要进行对话，因此该模型可确保我们确切地了解您要解决的问题-在表格和时区的翻译中不会丢失任何内容。

其结果是建立了一个与行业所了解的系统不同的支持系统，但成功得多。我们可以用少数几个人做的事情，其他组织则可以做数百个。在十多年的支持中，我从未使用过这种直观而简单的系统。  

其他系统专注于管理和票证流程。他们要求您花费时间来管理故障单，这与您要实现的实际最终目标相去甚远。即使管理票证的工作量仅适中，您仍然会被迫进入一系列上下文切换，这使您无法集中精力处理需要关注的事情。MinIO方法的简单性确保即使是复杂的问题也能得到应有的关注。这有一个额外的好处，正是因为没有解决问题的工程师被迫进行上下文切换，这使得团队在解决问题上的效率大大提高。

我们的方法有其含义。

其中之一是所有问题始终无休止。因此，我们会精心挑选客户。由于我们是100％开放源代码，并且客户可以自行支持，因此我们对SUBNET进行结构设计和定价，以吸引那些大规模部署我们软件的客户。因此，SUBNET用户趋向于技术范围的更为复杂的一端。当您获得工程支持时，这将带来更高的“爱你的客户”指标，并为双方带来更好的体验。

另一个含义是，我们的方法会导致更深入的参与。与大多数模型不同，我们将查看您的代码，并为您提供最佳实现的建议。我们这样做是因为它可以帮助客户，并且我们对他们的成功深感兴趣。不应将其与服务或私有扩展开发相混淆-即使是七位数，我们也不会参与其中。

这种方法侧重于结果而非指标。客户是否解决了他/他的问题？他们满意吗？成果可带来出色的指标，但这些指标并非最终指标。这需要一些习惯于一些客户。他们（坦率地说，采购团队）重视SLA和周转保证。即使是当我们实施修复程序或推出新版本（再次，不是自定义）时，它们也就出现了，而这仅是传统组织的一小部分时间。

结果非常有希望。我们的平均响应时间不到一个小时，许多问题在不到5分钟的时间内得到关注。

同样，速度是一个指标，但它并不总是最佳指标。许多问题需要认真思考和深入参与-使它们正确是正确的度量标准，而不是使它们封闭而使它们返回其他地方。

业内某些人会声称我们的模型不可扩展，因为您需要一个庞大的支持组织。那些公司不会像我们一样坚持不懈地追求简单。我们的营销人员之所以在这里，是因为尽管对象存储或分布式系统的经验有限，他仍能够在不到10分钟的时间内使MinIO运行。他知道情况有所不同。

之所以能够扩展，是因为一切都与极简（简单）有关，而一切都是工程问题。随着我们的成长，我们将发展工程，而不是支持。集体所有权的基因将是我们在招聘中优化的东西。

我们对即将到来的事情感到非常兴奋。我们的发展轨迹意味着我们将面临新的挑战。这将使我们紧张并挑战我们，但我认为我们潜在的哲学，文化和对对话的承诺将使我们前进。

欢迎加入我们的Slack频道http://slack.minio.org.cn/questions，向我询问有关方法。我的名字是@MINIO。