NetOps 在自动化竞赛中（几乎）与 DevOps 相遇
人们普遍认为，在自动化部署流程（也就是我们现在所说的生产）的竞赛中，NetOps 远远落后于 DevOps。
这种看法很重要，因为缺乏自动化（以及 NetOps 实现自动化的意愿）通常被认为是采用公共云的主要驱动因素。 它还在一定程度上负责诸如容器之类的新兴技术，这些技术有意将越来越多的网络和application服务拉入生态系统，以便它们可以被抽象出来，直到它们是否在生产中实现自动化不再重要。
当我们上次对那些身处战壕的人进行民意调查时，我们发现这一引述基本属实。 事实上，65% 的 DevOps 告诉我们，缺乏对部署管道的访问和自动化是他们绕过 IT 寻找其他解决方案（例如云和容器）的一个因素。
但认为 NetOps 未参与自动化竞赛的看法并不完全准确。 事实上，NetOps 似乎正在比 DevOps 占据优势地位。
F5 和 RedHat 最近进行了一项调查，当 NetOps 遇见 DevOps，以下这些数据可能会让人感到惊讶： 网络自动化的现状。 我们对 DevOps、NetOps 和安全专家进行了调查，询问了与 DevOps 及其自动化实践相关的各种主题。 我们特别询问的一件事是他们使用自动化在部署（生产）管道的四个关键组件中部署基础设施组件的情况：
- 应用基础设施。 这些是applications运行所需的服务器、系统、中间件和平台。
- application服务。 这些服务包括负载平衡和缓存、HTTP 路由和 Ingress 控制。
- 网络。 这是所有管道的基础。 每个应用程序和应用服务都需要网络中的路由和交换功能。
- 安全。 安全服务包括 WAF 和身份、访问控制和机器人防护。
我们发现，在部署管道的这些组件自动化竞赛中，DevOps 平均领先于 NetOps。 但我们也注意到，NetOps 也并没有落后太多。 我们进一步注意到，服务距离application越远，使用自动化来部署该服务的可能性就越小。
这种差异无疑仍然是两组人之间一些摩擦的原因。 我们注意到，有相同比例的 DevOps（43%）表示部署频率“足够好”和“不够频繁”。 NetOps 的意见分歧也很大，31% 的人认为部署频率“足够好”，30% 的人认为频率没有达到预期。
这与我们之前的调查结果相差甚远，在之前的调查中，仅有 18％ 的 NetOps 希望加快部署速度。
但自动化需要时间和精力。 但挑战依然存在。 DevOps 应该记住，当前的工具和工具集生态系统是面向开发人员和应用基础设施的。 在培育 NetOps 生态系统方面几乎没有采取任何行动。 当没有太多的集成方式来帮助您将部署管道难题的各个组件拼凑在一起时，很难保持连续性。
这就是真正的问题所在。 DevOps 如此成功的原因之一是它主要由开发人员组成。 生活和呼吸都离不开代码的开发人员。 他们知道如何整合需要整合的内容。 NetOps 不一定具备那套技能。 部署管道主要由通过协议集成的设备和系统组成。 定义明确、基于 RFC 的协议不需要基于代码的集成，因为它们的设计目的就不是如此。
对于 NetOps 来说，这是一个全新的挑战；他们尚未做好准备或具备相应的技能来应对这一挑战。 也就是说，只有三分之一多一点（38%）的 DevOps 将“跨供应商/设备的工具集集成”视为网络自动化的挑战。 另一方面，近一半（47%）的 NetOps 认为缺乏集成是一个问题，仅次于缺乏自动化知识（49%）。
数据显示，尽管自动化本身存在挑战，但 NetOps 并不像某些人认为的那样落后。 网络自动化为 NetOps 和安全提供了大量机会，可以将自己插入日益主导应用程序开发和部署的连续管道中。
有关NetOps Meets DevOps 的更多详细信息和分析： 网络自动化的现状，请务必今天获取您的副本！