微服务团队 - 如何处理 "infrastructure" 个团队？
Microservices teams - how to handle "infrastructure" teams?
所以我的问题更多地与团队本身有关，而不是与代码有关。
假设我们有几个 "services" 相关的团队，在这个概念中，2 个主要项目符号是：
- 团队应该是独立的——可以独自完成所有事情，可能找到可重用的代码，并编写他们需要的任何东西。
- 团队应该明确职责。
所以，当我考虑它时，它看起来有点像一个古老的概念，团队有 1 个产品，他们可以接触其他 "infrastructures?"
应该有专门的团队负责基础设施，对吧？就好像另一个团队在开发时接触了基础设施——他们可能做得不好，因为他们与那个区域没有联系。
因此，问题是：如果开发团队负责基础架构服务怎么办：
- 这与团队应该独立的说法有什么关系？如果他们需要基础设施的功能——他们需要让基础设施团队为他们开发吗？他们在内部开发吗？ （这打破了团队的重点，他们不是基础设施方面的专家）？也许他们以某种方式绕过了它——这也可能有问题。
- 基础设施服务团队通常关注什么？难道他们没有从其他开发团队那里得到他们的功能请求——这会使他们成为瓶颈，其他团队也会被卡住吗？
我想开始讨论它:)
根据我的经历，我的两点：
- 每个服务团队都应有权访问基础架构的特定部分。比如说在云的上下文中，访问分配给它的大量资源的租户。这将帮助团队根据他们的需要旋转 VM。
- Infra 团队应该在场调查和维护更高级别的基础设施，比如增加对租户的资源分配，使某种 OS 可用，调查服务故障等。
- 对于 CI/CD 等通用技术堆栈，系统维护和保养的责任将由基础设施团队承担。但是，添加任何侦听器都需要 'service team'。这样，服务团队只需在系统范围内出现中断且与日常更改无关时才需要联系基础设施团队。
所以我的问题更多地与团队本身有关，而不是与代码有关。
假设我们有几个 "services" 相关的团队，在这个概念中，2 个主要项目符号是：
- 团队应该是独立的——可以独自完成所有事情，可能找到可重用的代码，并编写他们需要的任何东西。
- 团队应该明确职责。
所以，当我考虑它时，它看起来有点像一个古老的概念，团队有 1 个产品，他们可以接触其他 "infrastructures?"
应该有专门的团队负责基础设施，对吧？就好像另一个团队在开发时接触了基础设施——他们可能做得不好，因为他们与那个区域没有联系。
因此，问题是：如果开发团队负责基础架构服务怎么办：
- 这与团队应该独立的说法有什么关系？如果他们需要基础设施的功能——他们需要让基础设施团队为他们开发吗？他们在内部开发吗？ （这打破了团队的重点，他们不是基础设施方面的专家）？也许他们以某种方式绕过了它——这也可能有问题。
- 基础设施服务团队通常关注什么？难道他们没有从其他开发团队那里得到他们的功能请求——这会使他们成为瓶颈，其他团队也会被卡住吗？
我想开始讨论它:)
根据我的经历，我的两点：
- 每个服务团队都应有权访问基础架构的特定部分。比如说在云的上下文中，访问分配给它的大量资源的租户。这将帮助团队根据他们的需要旋转 VM。
- Infra 团队应该在场调查和维护更高级别的基础设施，比如增加对租户的资源分配，使某种 OS 可用，调查服务故障等。
- 对于 CI/CD 等通用技术堆栈，系统维护和保养的责任将由基础设施团队承担。但是，添加任何侦听器都需要 'service team'。这样，服务团队只需在系统范围内出现中断且与日常更改无关时才需要联系基础设施团队。