在微服务环境中，谁应该拥有＆＃39;不再处于积极开发状态的服务？

Question

在典型的开发环境中，规模庞大的团队通常与大型项目保持一致。新功能是现有巨石的鞋子。该团队拥有巨石。尽管巨石的许多部分不再开发，但它们仍然由相关团队发布和拥有。如果有一个修复方案，很明显就是执行它的团队。

在微服务领域，构建了许多小型服务，典型的是1s和2s的小团队，一旦建成，可能不再需要更改。然后开发人员转向别的东西。该服务可能是许多应用程序的依赖项。没有特定的团队＆＃39;与服务相关联。

因此，当服务需要更改时，如何分配所有权？

Answer 1

有一种说法，我来自＆＃34;一只拥有太多主人的狗死于饥饿＆＃34;，这意味着，当每个人都有别人负责的事情时，即使人们同意，也没有人真正负责分担责任。

有很多方法可以解决你的情况，但在所有这些方面都应该有人负责。解决此问题的一些方法：

1. 一个人应该对项目负责。如果此人移动到新团队，他或她应该任命新的项目经理。如果这个人退出公司，剩下的工作人员应该选择其他人。
2. 定期检查谁负责每个项目。如果没有人负责，那就行动事实并指派某人。
3. 刚刚被任命为​​项目的每个人都必须检查他或她是否可以继续改进项目。例如，如果文档写得不好或缺乏，或者源代码太难阅读，那么新任命的人员应该在项目移交期间询问以前负责的人员。

没有灵丹妙药，但你可以遵循的原则可以避免将来的一些麻烦。

Answer 2

像@Akira说的那样。如果每个人都对一个微服务负责，那么没有人负责。

共同责任

每两周负责给定MS的团队将会改变。 因此，根据日期，您将拥有所有者。

根据他们所服务的产品对齐团队

每个团队都负责Product，这不是微服务。它是一组微服务，它们共同为业务带来价值。他们共同努力以满足特定领域的业务需求。您可以将Product理解为一个系统，该系统由很少的微服务一起构建。 这样的团队应该掌握有关整个系统的领域知识，并且应该更有效地支持MS，这些MS属于他们的产品。

创建新MS后创建和销毁的团队

这种管理有问题。如果MS不仅仅是另一个CMS，而是非常复杂的解决方案，它可能会变得更加成问题。编写MS的人应该负责支持它。如果他们要重视公司成为支持者，请带别人，但让他们沟通并向MS的创建者提问。否则MS迟早会变得混乱。

无论您选择什么，都要保持MS文档的最新状态。