弥合 DevOps 和 NetOps 之间的鸿沟

如果你还没注意到，我们正在写一个系列文章，题为“弥合……之间的鸿沟”

这篇文章是关于如何弥合团队之间的分歧，最初我认为这是个陷阱。

我见过太多文章将 DevOps 团队和 NetOps 团队对立起来，几乎是在个人层面上。 这没有帮助——因为这与人或团队无关——而是与形成他们的限制和期望有关。 这些团队中的个人大多喜欢在工作中做同样的事情——很酷的事情。 我们都想做出一些让自己感到自豪、有用而且很酷的东西。

团队之间的差异以及决定我们工作日形态的因素是我们所做工作的界限和影响，以及我们可使用的工具。 DevOps 团队通常解决application或一组服务的问题。 NetOps 团队为一个企业解决问题，如果是云 NetOps 团队（是的，它们确实存在），则为数百个企业解决问题。 大多数网络团队至少有一只脚踏在物理世界中，因为实际上必须有某种东西将那些光子和电子从一个地方推到另一个地方。 大多数 DevOps 团队都在虚拟的世界中工作，享受着几乎即时创建和销毁资源的力量。 虽然开发和 DevOps 团队很高兴（并且非常正确地）将他们的代码和业务逻辑从底层架构的细节中抽象出来，但他们这样做是出于一种隐性的信任，即有人确保他们的 API 调用能够到达正确的地方。 每个人都希望快速行动，每个人都希望事情不会出错，或者当事情出错时能够轻松诊断和修复。 只是它们所居住的宇宙从内部看起来可能有点不同。

正是在这两种现实的边界上，麻烦才会出现。 显然，在许多组织中，不同团队的工作实践和 SLA 要求存在分歧。 尽管这种摩擦可能被视为新事物，但这是我们十多年来一直观察到的情况 - 仅仅是因为 F5 技术一直是application中心团队和基础设施中心团队之间的互连。 无论是后端服务器数量的变化还是application行为的变化，application架构的变化始终需要反映在application交付层，其中进行安全检查、内容路由或负载平衡。 现在，开发人员正在组织他们的工作流程以使其更具迭代性，这些变化发生得越来越快，因此症状变得更加明显。

这就是为什么这是一个如此激动人心的时刻。 因为从来没有像这样的机会来弥合这一鸿沟。 在 F5，我们一直在开发越来越多的工具，将我们超强健的企业级技术融入更灵活、自动化的工作流程中。 我们一直在向任何需要的人提供有关这些新工作方式的培训。 我们一直在改变内部的工作方式。

但跨越分歧的最好桥梁是建立在理解和共同经验之上的。 如果没有合作的坚实基础，支撑桥梁的工具和流程就无法维持。 这是我最期待与 NGINX 合作的地方——有机会跨越鸿沟，了解他们那边的情况，更重要的是，了解他们客户那边的流程分歧。 通过合作，我们可以帮助共同的客户促进所有参与提供安全、快速和创新applications的团队之间的更好理解。 当然，其中会有技术；毕竟，这是我们制造的。 但它将涵盖更广泛的用例，并由围绕 DevOps 和 NetOps 的更完整的愿景驱动，以满足我们最关注的群体——我们的客户和用户的需求。