是否存在适合 NetOps 的最小可行部署？
网络自动化真的是全有或全无吗？
网络自动化（DevOps 生产流程的实践）已被相当一部分组织使用。 虽然只有很少一部分企业完全参与其中，但大多数企业（根据我们最新的application交付状况，占比为 77%）都在试行或在生产中部分使用自动化。
与 DevOps 紧密结合的概念之一（因此经常与 NetOps 相关）是“最小可行产品 (MVP)”的概念。
它是敏捷方法的一部分，用于加快开发周期并更快地将解决方案推向市场。 这正是我们在“网络”中迫切需要的东西。 您可能还记得之前博客中提到的 Appian 调查，该调查向我们提供了研究结果，表明 72% 的受访者对 IT 扩展以满足业务需求缺乏信心。
哎哟。 尽管 IT 领域广泛应用自动化，开发人员和业务利益相关者仍然对我们完成任务的能力缺乏信心。
因此，采用 DevOps 的工具、技术和方法来加快速度（通过更智能的扩展）并不是那么疯狂。 但在我们弄清楚如何将 MVP 应用于网络之前，我们必须了解它是什么。 因此，对于那些不熟悉 DevOps、Agile 或 MVP 的人来说，这里有一个来自敏捷联盟的简单定义：
最小可行产品 (MVP) 是精益创业的一个概念，强调学习在新产品开发中的影响。 Eric Ries 将 MVP 定义为新产品的某个版本，它允许团队以最少的努力收集有关客户的最大数量的经过验证的知识。 这种验证性学习体现为您的客户是否真正会购买您的产品。
MVP 理念背后的一个关键前提是，您生产出一种实际的产品（可能只不过是一个登录页面，或者是一种看似自动化的服务，但在幕后完全是手动的），您可以将其提供给客户并观察他们使用该产品或服务的实际行为。 观察人们对某种产品的实际行为比询问人们会做什么要可靠得多。
团队有效地使用 MVP 作为实验策略的核心部分。 他们假设他们的客户有需求，并且团队正在开发的产品可以满足该需求。 然后，团队向这些客户提供一些产品，以了解客户是否确实会使用该产品来满足这些需求。 根据从这次实验中获得的信息，团队继续、改变或取消产品的工作。
在本文中我指出，许多与 DevOps（及其相关技术和方法）相关的概念在应用于 NetOps 计划时并不总是能很好地转化。 实验并不是 IT 工程师、架构师或高管在讨论对网络进行更改时使用的术语。
爆炸半径，你看。 它规模庞大，而且掌控一切。 大多数组织对于运营风险的容忍度不高，这是有原因的。 停电会造成真金白银的损失，有时甚至还会造成失业。 网络实际上并不是一个进行实验的好地方。
但这并不意味着 NetOps 没有最小可行部署 (MVD)。
为 NetOps 定义 MVD
当今的生产管道由交换机、路由器、DNS 和多云路由 (GSLB) 等共享资源以及负载均衡器、WAF 和应用访问控制等每个应用程序的应用服务组成。
有趣的是，如果我们观察与共享资源相关的变化率，我们会发现它们相当名义上。 也就是说，它们的变化率较低。 这很好，因为他们对于干扰的容忍度也很低。 跳转到每个应用程序的资源，您会发现变化率更高，对中断的容忍度也更高。
毕竟，这是每个应用程序架构的好处之一 - 隔离数据路径，当出现问题时保护其他应用程序免受中断。
我们的研究告诉我们，沿着该数据路径平均有16 种不同的应用服务，用于交付和保护他们的应用。 其中一些（例如网络防火墙和 DNS）是共享资源。 其他人则不是，或者至少他们不需要这样。 它们今天可能部署在共享平台上，但如果你有充分的理由，它们可以构建到自己的数据路径中。
当然，这就是我要给你的。
好的理由是，如果您首先对与应用程序紧密耦合的应用服务采用每个应用程序架构，那么您可以有效地为应用开发 MVD。
正如我们对 MVP 的定义告诉我们的那样，“产品”（在我们的例子中是应用程序部署）不需要完全自动化。 如果我们以风险最高、容错率最低的资源必须继续手动配置（和验证）为前提，我们仍然会取得进展。 防火墙和 DNS 等核心服务的变化率非常低，因此我们可以假设手动方法不会对部署时间表产生重大影响。 如果我们使大部分每个应用应用的服务实现自动化，情况就更是如此，因为这样我们就可以腾出时间让操作员和工程师在必要时进行手动更改。
假设核心（共享）服务与每个应用程序的应用服务的比例约为一比三*，这意味着我们平均每个组织至少有四个共享资源需要手动管理，十二个每个应用程序的资源需要自动化。
查看广泛的应用服务列表（我们目前正在跟踪三十种不同的服务），我们会注意到其中一些服务对于交付或保护应用程序是必需的（DDoS、WAF、扩展负载均衡、应用程序访问），而其他一些服务则更多，可以说，是增强功能。 那将是应用服务，例如提高性能的加速选项或提高生产力的单点登录（SSO）。
因此，如果我们考虑实施 MVD，我们可能会采用敏捷方法并专注于对第一天交付和安全至关重要的应用服务。 这并不意味着我们会忽略这些增强，而只是意味着我们将首先关注关键的增强，并首先实现它们的自动化。 我们仍然可以手动管理那些能够提高生产力或性能的服务，但对于 MVD，我们希望集中精力于影响利润的服务。
敏捷网络的 MVD 方法
通过自动化来定义和交付 MVD 意味着我们的行动更快（我们更敏捷），并且让我们有机会在每次冲刺（以周为单位，而不是以季度为单位）中对自动化进行迭代以改进和扩展它，直到我们得到一个可靠、可持续的产品（自动化部署）。
采用基于 MVD 的自动化策略不仅需要致力于架构，还需要致力于专注于应用的方法和态度。 这是因为这种方法需要从运营角度和业务角度了解应用及其需求。 一个应用程序的 MVD 可能与另一个应用程序的 MVD 不匹配。 这就是从固定、手动网络过渡到敏捷（自动化）管道时每个应用程序的架构成为如此关键的组件的原因之一。
所以事实证明，对于 NetOps 来说，存在一个最小可行部署。 这意味着您可以采用敏捷方法实现网络自动化 - 如果您作为敏捷网络计划的一部分过渡到每个应用程序架构，那么该方法将无限快（和更安全）。
使（几乎）所有网络事务实现自动化。
*这完全是基于列表、我的经验和我的（强烈）意见的 SWAG。 您的里程和定义可能会有所不同。