面向NetOps的DevOps旨在实现规模化

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

规模带来速度，速度成就成功。

假设一名工程师可以在2小时内处理一个变更请求，另一名工程师可以在1.5小时内处理同一个变更请求。如果两人协同工作，处理200个变更请求需要多长时间？

没错，答案显然是啤酒。

大家可能都还记得数学课上那些臭名昭著的“火车”或“刷墙”应用题（想起来仍不免心生恐惧和厌恶）。这些题原本是为了教我们理解分数关系，确实如此，尽管很多人最后只落得讨厌刷墙和坐火车，外加收获了一大堆网络梗。可别忘了那些梗。

关键在于，这类公式化衡量方法正逐渐成为数据中心的必需手段，尤其是在网络领域。这是因为预算有限（没想到吧？真是不可思议），只能聘用X名工程师来完成Y项工作。在应用快速、频繁发布已成常态的环境中，为确保按时发布，能够聘用的“X”数量是有限的。

正因如此，规模成为推动网络领域“devops”（又称“netops”）发展的主要因素。通过将DevOps的运维原则应用于网络，人们认为netops可以达到所需的运维规模，使“X”名工程师即使在X与Y呈指数关系（通俗地说：极不对等）的情况下，也能在预算范围内按时完成“Y”项工作。

变更请求问题确实存在。一位网络工程师提出了这个问题：他面临的变更请求越来越多（变更请求是指为应用创建负载均衡器端点、将其添加到DNS，并创建允许访问的防火墙规则），最终可能导致现有人员不堪重负，同时延长完成变更所需的时间。

解决之道自然是自动化：应用DevOps原则并提供自助服务界面，让其他工程师能够提交请求。这些请求随后会记录在工单系统中，并通过各种网络和应用服务API执行。

采用自动化（以及编排，因为整个流程实际上也实现了自动化）不仅让现有工程师能够扩大运维规模，还让流程变得更快。处理变更请求不再需要长达2小时，现在最快只需5分钟。

没错，您没有看错。从最长两小时缩短至五分钟。

这显著提升了速度，得益于通过自动化和编排实现的扩展能力。虽然这并非一个雄心勃勃的“覆盖整个数据中心”的项目，但它确实解决了工程师和应用所有者经常遇到的一个具体痛点。在本例中，这一问题每周发生的次数显然多达200次。

这正是网络运维团队在生产网络中推进自动化和编排时应采用的方法。找出那些可重复执行且被变更评审委员会视为简单的任务（即经验证不会造成中断，而且大多数工程师都能轻松完成），便有望获得显著的规模化机会，从而达到业务负责人和应用负责人都要求网络实现的速度。

找出那些可在尽可能降低中断风险的情况下实现自动化的环节，可以让工程师腾出精力，专注于尚不适合自动化的任务。由于不必再将大量时间花在更简单的重复性任务上，工程师也能更快地实施其他服务。

对于网络自动化而言，采用CPR方法至关重要，再怎么强调也不为过：一致、可预测且可重复的自动化有助于更高效地扩展规模并缩短交付时间，同时降低错误导致中断的风险。这种方法融合了所谓的“模式1”和“模式2”运营模式，既以可靠性和稳定性为重，又兼顾敏捷性。通过在网络自动化和编排中采用CPR方法，组织可以提高敏捷性，同时大幅降低影响网络可靠性的风险。毕竟，该网络还承担着交付大量其他应用的任务，平均约为200个。

数据中心网络由传统技术和新兴技术组成，往往依靠类似“百战天龙”式的临时手段勉强维系，就像用口香糖和钓鱼线拼凑起来一样。这些网络必须同时支持已投入生产近50年的应用（大型机至今仍在使用），以及基于尚处于起步阶段的技术（如容器）构建的新兴应用。网络必须可靠、安全地交付所有应用。不能为了满足更新、更亮眼的应用对速度和频率的要求，而忽视这些标准。

但如果网络运维团队能够识别出那些不会造成中断，且被变更控制团队和其他审批方视为例行审批事项的任务和服务交付选项，并随后对其进行大规模自动化，就能实现平衡，让两者共存。

毕竟，如果油漆工使用自动滚筒，而不是手动操作的刷子，我们常用的房屋粉刷工时计算公式就会发生显著变化。

不必过于担心如何改变网络，换个计算方式即可。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章