DevOps 构建大师也需要协作

如果您是父母（即使您不是，这里也不作评判），您可能已经观看过《乐高大电影》。 不止一次。

我认为任何考虑采用 DevOps 的企业都应该注意这一点。

严重地。

这是因为，我们学到的（众多）经验教训之一是，即使是大师级建造者，即特定领域的专家，也需要与其他人合作，才能拯救世界，将应用转移到所需的部署状态。 也就是说，生产不会因令人畏惧的手工流程技术而陷入停滞。

就个人而言，建筑大师不仅能够设想他们想要建造什么，还能设想建造它所需的所有复合部件。 在电影中，他们经常出色地完成这些任务，通过制造出可以粉碎、飞行、奔跑和射击的机器人来拯救世界。 但是当需要针对“更大”的局面采取行动时，他们不仅要建立个人创作，还要精心策划（看看我做了什么？）一系列事件来挫败邪恶坏人的阴谋，他们却做不到。 他们需要的是一个喜欢查阅说明并随身携带一份清单的人，清单上有所需的所有程序，可以让所有人都朝着同一个方向前进。

在我们的案例中，这个方向就是生产。

随着持续部署成为一种真正的可能性和 DevOps 的最终目标，它跨越了开发和“其他 IT 部分”之间的壁垒，因此非常有必要跨所有四个运营领域（即安全、存储、计算和网络）进行协调，以确保每组单独的服务和系统的主要构建者不是在真空中工作。

即使采用微服务（具有“本地代码且独立于其他服务”）的开发人员也知道，只有在有明确定义和记录的接口（API）与其他服务进行通信的情况下，这种思维方式和方法才有效。 这些接口不是（或不应该）在真空中开发的，不了解其他服务将如何调用它们。

在生产侧也是如此；所有四个运营领地都需要在某个时刻进行沟通，以使持续部署真正实现。 有一个总体规划；一组必须遵循的指令，即使关于如何构建每个单独的服务或一组服务的细节尚不清楚。 在某些时候，它们必须被协调成一个总体过程，以推动从生产流水线的一端到另一端的部署。

每个领域内的建筑师不能完全独立地工作。 他们需要协调、合作，并考虑如何将自己的部分融入到拯救当今业务所依赖的（应用程序）世界的宏伟计划中。

开始这样做的方法之一是绘制影响集的图表。 在阅读了最近一篇关于代码耦合的文章《程序耦合的 80% 规则》后，我想起了这一点，该文章着眼于安全性。 本文非常注重代码，并构建了针对开发人员的依赖图，但如果您将其提升一个层次（抽象化）并将函数/过程/方法视为生产中的系统，您就可以开始看到它可能如何有用。 了解应用部署对特定服务的依赖程度（或者甚至首先在域级别）可以提供一些有价值的见解，以了解需要多少跨团队协调才能完成工作，并能够制定实现该目标的计划。

最好的例子之一是，几乎一切都取决于核心网络服务的首先部署。 这不仅适用于应用及其依赖组件，也适用于提供应用程序的安全性和高阶（应用程序）服务。负载平衡、Web应用安全性甚至防火墙都依赖于网络属性来发挥作用。 了解 IT 内部不同团队（孤岛）管理的系统和服务之间的依赖关系（耦合因素），对于推动沟通和协作的需求，甚至实现类似的持续部署，大有裨益。

即使是建筑大师也必须了解他们的创作如何融入大局。 将开发技术和工具应用于日益自动化和基于代码的 IT 运营世界，将帮助他们更好地构建必要的接口，将他们的部分集成到持续部署的宏伟建设工作中。