受团队结构影响的application服务部署计划

开发人员确实有所不同。 从角色和职责到在组织结构中的位置，开发人员经常是“格格不入的群体”。 你甚至不能将它们纳入“IT”一词中，因为开发团队在 IT 的一部分和业务的一部分之间摇摆不定。

即使 DevOps 作为一种文化转变开始扎根，大多数组织在功能上仍然被组织成不那么被亲切地称为 IT 孤岛的状态。 在我们的2019 年应用服务状况研究中，我们发现近一半的受访者（46％）仍然以“单一功能团队”的形式组织，例如“网络”、“服务器”、“存储”和“安全”。 超过三分之一（37％）的人在联合作战团队中工作，更适合采用和应用 DevOps 原则和方法进行应用交付和部署。 只有 15% 的人在基于业务部门或公司产品的小型跨职能团队中工作。

结构很重要，因为它在一定程度上决定了您的目的和优先事项。 这反过来又决定了衡量成功的标准。 孤立的组织意味着孤立的指标。 我们可以在去年夏天的NetOps 和 DevOps 调查中看到这一点。 我们发现，基于结构对团队的衡量方式存在显著差异。 例如，所有团队类型和角色中最常见的指标是：

1. 网络正常运行时间 (60%)
2. application正常运行时间 (56%)
3. 流程优化（40%）
4. 平均解决时间（39%）

但是，当我们将其分解并查看基于团队类型的指标时，我们会发现协作性更强 - 也就是。 类似于 DevOps——团队结构，优先级发生变化。 

现在，衡量您的标准与应用服务有何关系？ 事实上，相当多。

如果您主要关注的是网络正常运行时间，那么您将朝着这个目标努力并部署实现该目标的服务。 应用正常运行时间也一样。 如果这是您的首要任务，那么您将比那些按部署频率进行衡量的人们更加重视可用性服务。

在我们的研究中，我们可以看到大量“单一职能团队”受访者群体对应用服务部署计划的影响。 当我们根据应用服务为应用提供的功能对其进行分类时，这一点更加明显——安全性、性能、身份/访问、可用性和移动性。 

这些结果反映了单一职能团队指标的影响。 开发人员主要关注可用性（通常包括特定的性能目标），并计划部署那些支持可用性和性能的应用服务。 同样，NetOps 专注于那些通过优化、扩展和保护应用应用所依赖的网络协议来支持网络正常运行时间的应用服务。 

团队结构很重要。 不仅因为需要鼓励更具协作性的文化，还因为它影响决策的方式——包括技术选择。 不同的目标会导致摩擦和挫折。 这就是我们看到传统上由 NetOps 部署和运营的应用服务（如负载均衡）被 DevOps 接管并作为应用的一部分进行部署的原因之一。 因为在具有单一功能团队结构的组织中，应用正常运行时间是开发人员的优先事项，但不是 NetOps 的优先事项。

为了真正利用 DevOps，团队结构（以及衡量标准）必须转向更具协作性的模式，而不再是传统的单一功能团队。

因为孤岛属于农场，而不属于 IT。