以及来自2016 年秋季 NetDevOps 调查的其他洞察，该调查由NetworkToCode社区开展
NetworkToCode社区汇聚了众多热爱网络和代码的人。虽然这听起来有些老套，但早在网络自动化成为潮流（以及管理层的迫切要求）之前，他们就已经开始推动这项工作。
2016年秋季，该社区开展了一项调查，涵盖了广泛的问题，主题自然是网络和代码。原始调查结果（见上方链接）已公开。受在线调查工具本身的特性影响，生成的数据集往往难以分析，除非先对数据进行标准化处理，而这需要投入不少精力。幸运的是，亲爱的读者，我已经完成了这项工作，现在可以通过更直观、更丰富多彩的图表来分享相关洞察。
敏锐的读者会注意到，我长期以来一直倡导将通常所说的“DevOps”原则应用于网络。因此，我在深入研究这些数据时，自然将大量精力投入到了这方面。
在一个专注于代码和网络的群体中，大多数人对DevOps持积极态度，这并不令人意外。只有6.75%的人对DevOps“不感兴趣”，而25.74%的人表示已将其投入生产环境。其余大多数人即使尚未评估（28.27%），也至少正在考虑采用DevOps（39.24%）。
这项调查的出色设计者针对该主题提出了一些相当细致的问题，其中包括NetOps对基础设施即代码的看法。受访者对此的兴趣略低，近10%表示“不感兴趣”。有趣的是，只有19.35%的受访者称基础设施即代码“已投入生产”，但有54%的受访者表示使用自动化进行配置部署，另有66%会自动归档配置。只有一名NetOps人员正在实现配置管理自动化（而且我很确定，这不是那位自豪地使用vimdiff管理配置变更的NetOps人员）。
通常首先想到的问题是：“基础设施即代码究竟是什么？”这或许正是为什么很多人虽然认为自己主要还在“评估”或“考虑”，实际上却已经在“实践”。各位，定义疲劳确实存在。如今，如果没有明确的定义，就很难对这些转瞬即逝的术语得出结论（不过我们还是会这么做，毕竟这就是我们的工作，对吧？）。
那么，NetOps究竟在自动化哪些工作？are 我们一直强调，为确保数字化转型顺利推进、不受延误，他们需要实施自动化。但我们也知道，尤其是企业网络，并不适合随意尝试自动化。企业如今的整个业务都依赖这些关键网络。事实证明，NetOps已经实现了相当多的自动化。
配置生成、归档和部署是目前自动化程度较高的三项操作。数据收集和报告也呈现出加速发展的趋势。
事实上，除配置管理外（不过，确实有一家勇于尝试的网络运维团队实现了自动化），其他各项操作似乎都已在相当数量的受访组织中实现自动化。
当然，配置相关任务的自动化也引出了一个问题：这类任务多久执行一次，是否值得实现自动化？我认为（这可能与当前对此问题的看法相左），将变更部署到生产环境的频率越低，自动化实际上就越有价值。当然，人永远不会“忘记”如何骑自行车，但如果时隔数月甚至数年才再次骑上车，第一次重返车座可能会是一次痛苦且容易出错的经历。部署也是如此。不过，这个话题留待以后再谈。
事实表明，网络运维团队的部署相当频繁：近一半（50.92%）的团队每天会多次将小规模变更部署到生产环境，37.59%的团队每月会部署1至5次重大变更。虽然这远不及主要支持单一应用的互联网原生技术提供商（如Netflix、PayPal或Facebook）所宣称的“每天200次”，但对于平均支持200多个应用的企业而言，应用的推进速度仍然相当可观（数据来自我们自己的《应用交付现状》调查）。
最后，不禁让人好奇，他们是如何管理所有这些变更的？正如标题所说，确实有一位自豪的NetOps人员声称只使用vimdiff来管理变更。由于数据结构的限制，很难将这种做法与生产环境中的变更频率关联起来，但我非常想和这位NetOps人员聊聊。无论外界压力如何，此人都自豪地坚持使用适合自己的工具，堪称我的英雄。
其他NetOps依赖什么？事实证明，很多人都在使用Github，确切地说，占47%。另有相当一部分人（39%）使用Rancid/Oxidized。Rancid是一款用于管理配置备份的网络工具，请勿将其与1991年在美国加利福尼亚州伯克利成立的同名朋克摇滚乐队混淆。Oxidized也是一款用于管理配置备份的网络工具，通常被视为RANCID的替代方案。如果想进一步了解这些工具，可以查看专门讨论它们的subreddit社区。
令人担忧的是，有8%的受访者完全不跟踪配置变更。我曾在实验室里这么做过一次，结果弄出了一条严重不对称的跨网络链路：一个方向为100 Mbps，另一个方向只有1.5 Mbps。没错，大约11年前，我在格林贝的一间实验室里意外重现了现代有线宽带模式。遗憾的是，我没有因此获得版税；不过好消息是，我也没有收到抗议信。话说回来，如果无法按组织规模进行交叉分析，就很难理解这种做法背后的原因。有趣的是，11.91%的受访者管理着0至50台网络设备，因此可以合理推测，那8%的受访者所管理的设备数量尚在可控范围内，目前并未遇到问题。NetOps中占比最高的群体（38.63%）管理着1,000多台设备，另有28.23%管理着251至1,000台设备。因此可以说，大多数NetOps都要负责大量设备（几乎可以肯定是异构设备）。所以，跟踪配置变更不仅是维持网络持续稳定运行的必要措施，也是避免运维人员不堪重负的关键。
总的来说，我非常享受这次深入了解NetDevOps（他们对自己的称呼）领域的过程。虽然只是从宏观层面了解了大致情况，但也让我看到了他们使用的工具、重视的事项，以及他们所处的运营环境。
NetOps是IT组织的中坚力量。随着企业推进数字化转型，网络及负责保障其安全运行的运维人员将面临更大负担，而NetOps也日益肩负起确保一切正常运行的责任。
我认为，不可能将网络运维从传统模式整体彻底改造为更敏捷、类似DevOps的模式。与企业数字化转型一样，IT数字化转型也需要分阶段推进，同时注意不要干扰现有流程，以免影响业务正常运行。调查显示，转型显然正在发生。尽管这种转型可能并未冠以“DevOps”之名，也未完全符合纯粹主义者对DevOps的定义，但它无疑正在推动企业网络踏上自身的数字化转型之旅。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。