2018 年application交付状况： NetOps 搭乘自动化列车

作为一名对编程语言和协议以及线路捕获同样热爱的 IT 博学者，自动化和编排所需的两者之间的界限变得模糊让我感到很兴奋。

四年来，我们一直在追踪application交付状况调查的受访者如何看待支持 API 的基础设施和相关技术。 在此期间，认为基础设施的可编程性很重要（5 分制中得分为 4 或 5 分）的人数比例几乎翻了一番。 2015 年，不到一半（40%）的人告诉我们这很重要。 今年，高达 74% 的人认为它很重要。

根据我们在 2017 年就该主题进行的调查结果，我们或许不应该对此感到惊讶。 在对 DevOps 和 NetOps 的看法的探索中，两个群体都一致认为生产流程的自动化非常重要。

但看法仅仅是意见而已。 实际用途又是另外一回事。

我们在今年的调查中发现，自动化渗透到了每个地区、每个行业以及各种规模的组织中。 虽然没有人达到 100%（并且可能不会），但生产中的自动化程度比人们意识到的要高得多。

事实上，25% 的受访者告诉我们，他们总是使用自动化来对生产进行重大改变。 60%有时会使用自动化来对生产进行微小改动。 事实上，总体而言，生产变化中更有可能使用自动化，而不是事件响应中的自动化。 超过四分之一（26%）的人表示他们从未使用自动化进行事件响应，只有 22% 的人告诉我们他们总是这样做。  在处理可能无法预测的事件时，情况的变化使得这种情况并不令人惊讶。 自动化在一定程度上依赖于一组明确定义的任务和步骤，将它们绑定到一个操作流程中。 这使得生产中的变化（无论大小）更适合这些流程的编纂。 事件响应？ 但事实并非如此。

看起来，各种类型、规模和行业的数据中心内部都在进行着大量的自动化操作。

您可能想知道他们使用什么来实现所有这些自动化。 在过去的几年中，我们在一个问题中集中讨论了很多工具、工具集和框架。 但这并不合理，因为随着自动化的真正普及，我们需要真正理解自动化的几个不同方面才能理解到底发生了什么：

1. 语言和工具集。 这些是 NetOps 和 IT 用于自动化命令和控制的工具。 其中包括 Ansible (20%) 和 Vagrant (5%) 等工具，以及 Puppet (19%) 和 Chef (16%) 等框架。 其中，明显的赢家是传统的 Python 脚本，39% 的受访者选择使用自己的脚本来实现 IT 自动化。

2. 网络自动化。 由于数据路径中平均有 16 种不同的应用服务，需要部署、配置和持续管理来支持应用的安全交付和扩展，大多数组织将转向思科 ACI（48%）、VMware（65%）和OpenStack （26%）等系统。 这三家公司同比去年都实现了可观的增长。 在 55% 的组织由于数字化转型努力而转向自动化和编排的环境中，这并不令人惊讶。

3. 容器编排环境 (COE)。 这些新兴技术继续掀起波澜，很明显，它们用于扩展容器化应用是不可避免的。 在我们所询问的问题中，Docker Swarm 占据领先地位，占受访者的 27%，其次是 Red Hat OpenShift，占 21%，Kubernetes 位居第三，占 16%。 只有 48% 的人告诉我们他们目前没有使用任何东西。

令我惊讶的是，每个组织中这些工具和框架的数量正在减少。 这意味着我们看到了对自动化工具和工具集的刻意使用，这无疑是一种标准化的战略努力。 越早采取措施越好，以免陷入混乱，IT 部门也难以承受应用程序开发人员多年来一直苦苦挣扎的技术和架构债务的重压。 事实上，50% 的受访者只使用单一的网络自动化框架。 其中，8%依赖思科 ACI，5%依赖 Open Stack，19%依赖 VMware。

这仍然是一个非常流动和不断发展的市场——如果我们可以称之为市场而不是运动的话。 DevOps 方法对生产的入侵和来自业务的压力使得 IT 的行动更快。 NetOps 正在采用并拥抱自动化及其所包含的一切。 随着 IT 继续其数字化转型之旅，我们期望看到自动化得到更广泛的应用，为企业提供坚实的数字化基础，以便构建新的应用程序并探索新的机遇。

如需了解有关数字化转型、多云、应用服务、安全性以及持续的 NetOps 转型的更多见解，欢迎获取我们的《2018 年应用交付状况》报告副本，并在 Twitter 上关注@f5networks和/或主题标签#soad18 。 请继续关注——我们将在即将发布的博客中提供更多见解（包括报告中未包含的数据和观点）。