NetOps 的 DevOps 在于规模
假设一名工程师可以在两小时内处理一个变更请求。 假设另一位工程师可以在 1.5 小时内处理该变更请求。 如果他们合作的话，需要多长时间才能处理两百个变更请求？
是的，答案显然是啤酒。
每个人都可能记得（带着不少恐惧和厌恶）数学课上臭名昭著的“火车”或“绘画”应用题，这些应用题旨在教我们分数关系。 事实上，这确实是他们的本意，尽管我们许多人从他们身上了解到了对绘画和火车旅行的厌恶。 还有很多模因。 我们不要忘记模因。
重点是，这种公式化测量正在成为数据中心，特别是网络的要求。 那是因为预算有限（我知道，对吧？ 这有多疯狂？），你只能雇佣 X 工程师来做 Y 工作。 在application世界中，快速和频繁的发布周期是游戏的名称，您可以雇用来实现及时发布的“X”的数量是有限的。
这就是为什么规模是网络中“devops”（又名“netops”）的主要驱动力。 通过将 DevOps 的运营原则应用于网络，人们相信 netops 可以实现必要的运营规模，使得“X”工程师能够按时、在预算约束内完成“Y”工作，即使 X 和 Y 之间的关系是指数级的（外行翻译：非常不平衡）。
变更请求问题是一个真实存在的问题；由一位网络工程师提出，他面临着越来越多的变更请求（定义为为application创建负载均衡器端点，将其添加到 DNS 并创建防火墙规则以允许访问），这些请求最终可能会导致现有人员不堪重负，同时增加完成时间。
当然，答案在于自动化，在于应用 DevOps 原则并提供自助服务界面，让其他工程师提出请求，然后这些请求记录在票务系统中并通过各种网络和application服务 API 执行。
采用自动化（以及编排，因为整个过程实际上也是自动化的）不仅允许现有工程师进行操作扩展，而且还使流程更快。 处理变更请求不再需要长达两个小时；现在只需五分钟。
是的，你没看错。 只需五分钟，而不是长达两个小时。
这是通过自动化和编排进行扩展的能力所带来的速度的显著提升。 虽然这不是一个雄心勃勃的“数据中心范围”项目，但它确实解决了工程师和application所有者经常遇到的一个特定痛点。 在这种情况下，每周显然多达 200 次。
这正是 Netops 应该如何在生产网络中实现自动化和编排。 找到那些可重复且被变更审查委员会认为是琐碎的任务（即它们被证明是非破坏性的并且大多数工程师可以在睡梦中完成）可以带来巨大的扩展机会，从而实现企业和application所有者告诉我们需要在网络中实现的速度。
挖掘那些可以以尽可能小的风险实现自动化的关键要素，可以让工程师们专注于那些尚不适合自动化的任务。 这种专注还意味着其他服务实施的速度更快，因为他们不再需要花费过多的时间在更简单、可重复的任务上。
我再怎么强调采用 CPR 方法进行网络自动化的重要性都不为过：一致、可预测和可重复的自动化将实现更高效的规模和更快的交付时间，同时减少因错误而造成中断的风险。 这就是所谓“模式 1”和“模式 2”运营模式的结合，其中可靠性和稳定性占主导地位，但灵活性仍然是可取的。 通过启用 CPR 方法实现网络自动化和编排，组织可以提高灵活性，同时大大降低破坏负责交付大量（平均约 200 个左右）其他applications的网络可靠性的风险。
数据中心网络由传统技术与新兴技术组成，通常采用需要泡泡糖和钓鱼线的 MacGyver 式技术结合在一起。 这些网络必须同时支持已生产了五十年的applications（大型机仍然存在）和基于刚刚淘汰的尿布技术（如容器）构建的新兴应用程序。 它必须可靠且安全地交付所有applications。 我们不能为了追求更新、更先进的applications所需的速度和频率而忽视这些标准。
但是，如果 netops 能够识别并随后自动执行那些非破坏性且被变更控制和其他审批者视为复选框的任务和服务交付选项，那么 netops 可以实现两者共存的平衡。
毕竟，当油漆工使用自动滚筒刷而不是手动刷子时，我们最喜欢的确定粉刷房屋时间的公式会发生巨大变化。
不要太担心改变网络，只需改变方程式。