网络自动化真的只能在“全有”和“全无”之间二选一吗？
网络自动化，即在生产管道中应用DevOps实践，已被相当一部分组织采用。尽管全面采用的组织寥寥无几，但大多数组织（根据我们最新的《应用交付现状》调查，这一比例为77%）正在试点或已在部分生产环境中使用自动化。
与DevOps密切相关，因而也常与NetOps相关联的概念之一，是最小可行产品（MVP）。
它是敏捷方法的一部分，用于缩短开发周期，推动解决方案更快上市。这正是“网络”领域迫切需要的。您可能还记得之前一篇博客中提到的Appian调查。该调查的研究结果令人警醒：72%的受访者对IT能否扩展以满足业务需求缺乏信心。
这可不妙。尽管自动化已在IT领域得到相当广泛的应用，开发人员和业务利益相关者仍然对我们完成任务的能力缺乏信心。
因此，采用DevOps的工具、技术和方法，通过更智能的扩展来加快进度，并非异想天开。但在弄清楚如何将MVP应用于网络之前，我们得先了解它是什么。对于不熟悉DevOps、敏捷开发或MVP的读者，以下是敏捷联盟给出的简明定义：
最小可行产品（MVP）是精益创业中的一个概念，强调学习对新产品开发的影响。Eric Ries将MVP定义为新产品的一个版本，团队可以用最少的投入，最大限度地获取经过验证的客户认知。这种经过验证的认知体现为客户是否会实际购买产品。
MVP理念的一个关键前提是，开发出一款实际产品（可能只是一个落地页，也可能是一项看似自动化、实际完全由人工在后台操作的服务），将其提供给客户，并观察客户使用该产品或服务时的实际行为。与询问人们会怎么做相比，观察他们实际如何使用产品要可靠得多。
团队将MVP作为实验策略的核心组成部分，以有效开展验证。他们假设客户存在某种需求，并且团队正在开发的产品能够满足这一需求。随后，团队向这些客户交付相应成果，以了解客户是否确实会使用该产品来满足这些需求。团队根据此次实验获得的信息，决定继续、调整或取消产品开发工作。
在本文中，我需要指出，许多与DevOps（及其相关技术和方法）有关的概念在应用于NetOps计划时并不总是适用。IT领域的工程师、架构师或高管在讨论网络变更时，通常不会使用“实验”一词。
这就是所谓的爆炸半径。它影响范围广，而且不容忽视。大多数组织对运营风险的容忍度都不高，这是有充分理由的。服务中断会造成实实在在的经济损失，有时甚至会让人丢掉工作。网络确实不适合用来做实验。
但这并不意味着NetOps没有最小可行部署（MVD）。
定义NetOps的MVD
当前的生产管道既包括交换机、路由器、DNS和多云路由（GSLB）等共享资源，也包括负载均衡器、WAF和应用访问控制等按应用配置的应用服务。
有趣的是，如果观察共享资源的变更频率，就会发现其变更幅度相当有限。也就是说，它们的变更频率较低。这是件好事，因为它们对中断的容忍度也较低。再来看每个应用的专属资源，就会发现其变更频率更高，对中断的容忍度也更高。
归根结底，这正是按应用架构的优势之一：通过隔离数据路径，避免在出现问题时影响其他应用。
我们的研究表明，组织平均会沿该数据路径使用16种不同的应用服务来交付和保护应用。其中一些服务（如网络防火墙和DNS）属于共享资源。其他服务则并非如此，或者至少并不需要共享。这些服务目前可能部署在共享平台上，但如果有充分理由，也可以为其设计独立的数据路径。
当然，这正是我接下来要介绍的。
充分的理由是，可以有效地为应用开发MVD，前提是首先对与该应用紧密耦合的应用服务采用按应用架构。
根据MVP的定义，“产品”（在本例中指应用部署）无需实现完全自动化。即使风险最高、容错能力最低的资源仍须手动配置（并验证），我们依然可以取得进展。防火墙和DNS等核心服务的变更频率很低，因此可以认为手动操作不会对部署进度产生显著影响。如果将大部分按应用部署的应用服务实现自动化，效果会更加明显，因为这样可以为运维人员和工程师腾出时间，以便在必要时进行手动更改。
假设核心（共享）服务与每个应用的应用服务之比约为1∶3*，则一般组织至少需要手动管理4项共享资源，并自动管理12项应用专属资源。
纵观种类繁多的应用服务（我们目前正在跟踪30种不同的服务），可以发现，其中一些是交付应用或保障应用安全所必需的，例如DDoS防护、WAF、用于扩展的负载均衡和应用访问；另一些则更像是所谓的增强功能，例如用于提升性能的加速选项，或用于提高工作效率的单点登录（SSO）。
因此，如果考虑实施MVD，我们可以采用敏捷方法，重点关注从第一天起对应用交付和安全至关重要的应用服务。这并不意味着忽略增强型服务，而是先聚焦关键服务并优先实现自动化。我们仍可手动管理那些有助于提高工作效率或性能的服务，但对于MVD，我们希望专注于影响利润的服务。
敏捷网络的MVD方法
以定义和交付MVD为目标推进自动化，意味着我们能够加快进度（更加敏捷），并有机会在每个冲刺周期（以周而非季度计）中迭代自动化方案，不断改进和扩展，直至形成稳定、可持续的产品（自动化部署）。
采用基于MVD的自动化策略，不仅需要坚持相应的架构，还需要秉持以应用为中心的方法和理念。这是因为，这种方法要求从运营和业务两个角度了解应用及其需求。不同应用的MVD可能并不相同。因此，在从固定的手动网络转向敏捷的自动化管道时，按应用构建的架构至关重要。
事实证明，NetOps也有最小可行部署。这意味着可以采用敏捷方法实现网络自动化。如果在敏捷网络计划中转向按应用架构，这一过程将大幅加快，同时也更加安全。
实现（几乎）所有网络事务的自动化。
*这完全是我根据这份列表、个人经验和（强烈的）主观看法做出的粗略估算。实际情况和定义可能因人而异。
关于作者
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服务。