什么是网络韧性？定义与现代架构

网络韧性是指组织预测、抵御中断并从中恢复和适应的能力，无论中断源于攻击、服务中断还是系统故障。随着组织对不同提供商的依赖日益加深，任何架构都无法完全避免故障。网络韧性的新方法（例如“反脆弱”韧性）不再只是围绕恢复进行设计，而是强调构建能够吸收中断、控制影响并不断演进以增强韧性的系统。这种方法倡导有意识且严谨的工程实践和主动策略，以应对不可避免的故障，确保性能可预测并具备适应性。

要点：

• 网络韧性以中断不可避免为前提，重点是在服务中断、网络攻击和提供商故障期间维持运营，而不只是预防中断或从中恢复。
• 应用韧性是实现网络韧性的起点，因为大多数业务中断最先表现为应用中断。
• 反脆弱架构旨在控制影响范围、实现依赖项多元化、支持策略驱动的自适应并持续改进，使系统在每次中断后变得更强，而不只是恢复正常。
• DORA和NIS2等监管框架正使网络韧性从最佳实践转变为许多全球企业必须遵守的法律要求。
• 弹性架构结合零信任访问控制、多云高可用性实践以及Web和API保护，以控制故障影响，并确保服务在真实攻击条件下持续运行。

什么是网络韧性？

过去，网络韧性侧重于在中断后恢复并回归正常运营。但当前的网络韧性策略认为，中断并非总能避免，而且在分布式系统中，恢复速度可能不够快。很多情况下，单点故障会在团队能够手动响应之前蔓延至依赖系统。如今，网络韧性策略力求预判各种潜在中断，并抵御中断、从中恢复并加以适应，从而帮助组织持续运营。

围绕反脆弱策略设计的现代架构有助于组织在网络安全事件发生后适应变化并实现发展。这种方法可最大限度地降低中断影响，支持实时调整，并总结经验教训，避免再次出现系统崩溃临界点。反脆弱策略还可在事件发生时限制影响范围，确保系统在中断期间的可用性，加快恢复速度，并为架构的长期优化提供洞察。

组织需要借助相应工具，将反脆弱韧性融入混合多云架构。智能流量管理、全面的安全防护和高级自动化是关键组成部分，可帮助团队设计出能够经受中断并在恢复后更加强韧的系统。F5解决方案旨在帮助企业保护关键应用、缩短停机时间，并将网络韧性转化为竞争优势。

网络韧性与网络安全的区别

网络安全和网络韧性是保护企业的两种互补但不同的方法。网络安全侧重于预防，旨在保护系统和数据免受网络攻击、未经授权的访问和数据泄露等威胁。防火墙、加密、访问控制和攻击检测工具均属于此类。这些主动防御机制旨在阻止威胁入侵。

网络韧性以威胁和中断必然会发生为前提，无论其原因是网络攻击、云服务提供商服务中断，还是分布式系统中的配置错误。网络韧性侧重于组织适应、承受这些事件并从中恢复的能力，同时尽可能降低其对用户和运营的整体影响。

网络韧性也不同于灾难恢复。灾难恢复策略规定了特定事件发生后恢复正常运营所需的步骤和基础设施。该策略通常旨在达到特定的恢复时间目标（RTO）和恢复点目标（RPO）。相比之下，网络韧性还包括在中断期间持续保持运营的目标。

从应用韧性入手

大多数业务中断都始于应用中断，因为应用是组织与其服务对象之间的主要接触点。当应用运行缓慢、发生故障或无法访问时，无论根本原因是什么，业务都会直接受到影响。因此，网络韧性策略应从应用层入手。
构建具有韧性的应用，需要组织重点关注五个相互关联的要素：

• 应用可用性：即使需求和条件发生变化，保持服务连续性也至关重要。
• 应用安全：团队不仅要保护周边网络边界，还必须保护应用层免遭利用。
• API韧性：提升应用韧性意味着保障连接应用、合作伙伴和AI智能体的API的性能与完整性。
• 流量韧性：智能路由和均衡流量对于防止单点故障影响用户体验至关重要。
• 运营可见性：团队需要利用遥测数据，在问题出现时及时发现，而不是等到客户报告后才发现。

这些要素必须协同工作。例如，缺少安全上下文的流量管理会产生盲区，而缺少流量情报的安全控制则无法实时调整。许多组织不再尝试使用单点产品分别管理这些要素，而是采用应用交付与安全平台（ADSP）。此类平台采用统一架构，集流量管理、安全、可观测性和自动化于一体，为实施反脆弱策略提供架构基础。

在当今由混合多云和AI驱动的环境中，传统韧性方法往往难以奏效。现代环境依赖企业无法控制的第三方服务（例如身份认证、路由或数据存储服务）。故障隔离和恢复工作因此各自为政、被动响应，使组织容易受到不断演变且可能反复出现的威胁。

反脆弱网络韧性带来了新的维度，可在中断发生后改进系统和架构。现代架构使企业能够统一安全、流量管理和灾难恢复，打造可自适应且能够抵御故障的环境，将事件转化为增强基础设施的机会。

从恢复迈向反脆弱网络韧性

传统韧性模型是为另一个时代设计的。在那个时代，故障仅限于局部，依赖关系明确，系统控制也更为简单。在这些传统环境中，灾难恢复计划界定了应急准备的范围。

混合多云架构从根本上改变了这一局面。现代应用依赖外部服务来提供身份认证、路由、内容交付、存储和治理，其中许多服务完全不受企业控制。当这些第三方提供商出现问题时，影响可能会迅速波及全球，进而影响关键应用和服务的性能。

由于分布式环境中的任何环节都可能发生故障，以恢复为中心的传统策略已无法满足需求。恢复策略假定外部服务会保持可用，或可“故障转移”到稳定环境。在现代应用交付环境中，这些假设已不再成立。现代韧性策略必须限制外部故障的影响范围，实时适应中断，并将经验教训融入未来的架构设计，以避免故障再次发生。

这一转变是反脆弱韧性的基石。反脆弱策略并不以让系统恢复到先前状态为目标，而是将中断视为一种正常运行状况，需要预见、控制并从中吸取经验。这些策略注重依赖项多元化、策略驱动的适应、渐进式改进和数据驱动的治理等架构实践。衡量成功的标准不仅包括系统恢复的速度，还包括对安全事件影响范围的控制、运营连续性，以及每次事件发生后的架构改进。

在这一模式下，韧性从被动恢复能力演变为持续改进机制。这种方法通过每次中断增强架构，并符合欧盟《数字运营韧性法案》（DORA）等新兴监管要求中关于“学习和演进”的规定。

韧性架构的关键属性

传统韧性模型诞生于系统较为简单、依赖关系较少的时代，当时故障基本局限在组织可控的环境内。在那种情况下，韧性意味着在事件发生后尽快恢复并重新开展运营。混合多云环境和AI的广泛应用正在改变这一现实。如今，身份、路由、内容交付、存储、DNS和治理等关键服务通常运行在外部平台上。由于依赖第三方解决方案，供应链中任何环节发生故障，都可能对现代企业造成全球性影响。

反脆弱韧性是面向复杂分布式环境的一种演进。它不再将故障视为例外，而是假定中断是正常的运行状态。反脆弱策略旨在事件发生期间及之后控制影响、适应变化并持续改进。这一转变通过一系列工程实践来实现，这些实践决定了架构在压力下的表现，包括：

• 爆炸半径控制：建立明确的信任边界和故障边界，防止某个区域、云或提供商发生的故障级联至整个系统。
• 依赖项多元化：为关键服务提供替代选项，避免任何单一提供商控制系统功能。这样可将冗余转化为灵活选择，而非简单复制。
• 策略驱动的自适应：以可根据实时状况动态响应的策略取代僵化配置，并随着故障发展调整路由、身份验证和可用性。
• 渐进式调整： 将事件转化为学习机会，通过小幅且可观察的改进来优化架构，在不影响系统稳定性的前提下增强韧性。
• 数据驱动的治理：以遥测数据、性能分析和流量行为为依据，而非主观假设，推动决策并持续优化设计。
• 运行时自动化：当发生全系统事件、人工响应速度难以及时时，确保立即启动自动响应。

这些实践相辅相成，使韧性建设从被动响应转变为持续改进的闭环，在每次中断中增强架构，并满足现代混合多云环境的要求。

网络韧性为何在当下至关重要（业务影响）

混合多云架构带来了新的复杂性，完全防范已不切实际。组织日益依赖第三方服务来提供身份认证、路由、存储、治理和内容交付，由此形成错综复杂的运营依赖关系。任何一项依赖出现故障，都可能立即在全球范围内引发连锁影响。这种相互关联性意味着，现代韧性不能仅依靠防范，还必须以持续中断为前提，并具备足够的适应能力，以便快速响应和恢复。

监管压力也在加速向更先进的韧性模式转变。诸如DORA和NIS2等框架明确要求组织，尤其是受到严格监管的行业中的组织，不仅要证明具备恢复能力，还要证明能够在中断期间保持业务连续性。这些强制性要求进一步凸显了采用工程化韧性实践的必要性，以最大限度降低系统性风险，并减少依赖关系的脆弱性。

应用为关键的企业和消费者互动提供支持。用户期望服务不受底层提供商问题或恶意活动影响，始终保持可用，因此业务无法承受停机。每一分钟的中断都会影响品牌、收入和信任。

架构复杂性、监管义务和客户期望等因素相互交织，使网络韧性不仅成为技术重点，更成为业务发展的必然要求。

韧性网络战略的四大支柱

完善的网络韧性战略遵循一套生命周期方法，帮助组织做好准备，在各个阶段应对中断。该生命周期既符合传统风险管理原则，也融入现代反脆弱思维，使系统能够承受压力，并在压力中增强韧性。以下是构建现代网络韧性战略的四大支柱。

预判（威胁建模）

要实现有效的韧性，首先需要了解故障可能发生的位置。威胁建模可识别内部和外部的关键依赖关系，并评估中断、攻击、配置错误或提供商故障可能对系统造成的影响。通过预判干扰，团队可以定义信任边界、梳理爆炸半径所涉及的范围，并优先确定最需要投入工程资源的领域。

抵御故障（冗余和故障转移）

了解风险后，必须将架构设计为即使面临这些风险也能持续运行。这需要实现关键服务多元化、设置冗余执行路径，并制定相应策略，使系统能够随条件变化实时调整。要抵御中断，除了配备备份外，还需确保主要依赖项性能下降或发生故障时，备用路径仍然可用。

恢复（还原）

恢复可确保系统在中断后恢复正常运行。在现代环境中，这包括恢复服务可用性、重新平衡流量、重建信任边界，以及验证依赖系统是否已恢复稳定。更快速的自动化恢复可缩短停机时间，并有助于遏制级联影响。

演进（反脆弱反馈循环）

遥测数据、事件分析和实际性能观测结果会反馈到架构优化中。随着时间的推移，这一持续改进循环将增强系统、减少故障复发，并推动韧性建设从被动响应转向主动防范。

监管要求

对于许多全球性企业而言，网络韧性是一项法律要求，欧盟（EU）及其他主要市场通过风险管理法律对此作出强制规定。与构成网络韧性战略的最佳实践一样，这些法律旨在推动组织从事件发生后恢复，转向证明自身有能力在事件期间持续运营。

《数字运营韧性法案》 （DORA）适用于在欧盟运营的金融实体，以及这些实体所依赖的关键第三方信息和通信技术（ICT）提供商。DORA要求组织定期测试其ICT系统，管理整个供应链中的第三方ICT风险，并在规定时限内报告重大事件。

《网络与信息安全指令2》（NIS2）对欧盟境内更广泛的行业规定了类似义务。该指令要求采取风险管理措施、报告事件并落实供应链责任。

在美国，美国国家标准与技术研究院（NIST）网络安全框架（CSF）2.0是一项自愿采用但应用广泛的框架，旨在帮助组织改进网络安全风险管理。

这些框架进一步印证了网络韧性战略应采用的架构最佳实践。以控制影响范围、实现依赖项多元化和持续改进为目标构建的架构，可为组织满足DORA、NIS2和NIST CSF的共同要求奠定切实可行的基础。遵循这些框架不仅有助于组织保持韧性，还能证明其具备相应的韧性。

AI与智能体韧性

随着各组织采用生成式AI和智能体AI来自动化越来越多的运营工作，监管机构对技术风险的关注范围也在扩大。随着AI模型和自主智能体接管过去由人做出的决策，韧性也必须覆盖这些模型和智能体。各组织应将预判、抵御、恢复和演进的生命周期应用于AI系统。

团队尤其应重点关注：

• 模型API保护：团队必须保护向AI模型应用和用户开放的API。
• AI网关韧性：团队必须确保网关在负载下将请求路由到模型时保持可用性和性能。
• 提示词攻击遏制：限制提示词注入或对抗性输入在到达模型后的扩散范围。
• 模型故障转移：当主模型、提供商或区域不可用时，团队需要制定维持服务的策略。
• LLM可观测性：团队需要使用工具实时监控模型行为、延迟和输出质量。
• AI工作负载连续性：团队必须确保依赖AI的流程在发生中断时仍能继续运行，与传统应用保持一致。

技术领导者越来越需要将AI系统视为同样需要实施韧性实践的领域，而不是将其作为可免于这些实践的独立类别。

应用韧性蓝图

缩小故障影响范围、实现依赖项多元化以及支持策略驱动型自适应等原则，分别对应具体的工程实践。

零信任与动态速率限制

要限制故障或攻击的蔓延范围，首先需要减少整个环境中的隐式信任。零信任架构（ZTA）不会在会话开始后授予广泛访问权限，而是对每个用户、设备和服务进行持续验证。ZTA应与动态API速率限制结合使用，后者根据行为而非固定阈值实时限制请求速率。借助ZTA和动态API速率限制，团队可以在受损的凭据或失控的集成影响更广泛的系统之前将其遏制。

多云负载均衡和双活故障转移

即使个别提供商、区域或路径发生中断，混合多云架构也必须确保服务持续可用。智能流量路由可在故障发生时将请求绕过故障点，而全局服务器负载均衡（GSLB）可将这种智能扩展到分布在不同地理位置的数据中心和云区域。借助这些功能，单个位置发生中断不会导致整个服务不可用。同时，双活故障转移配置让多个环境同时运行，而不是让其中一个环境闲置作为备份，从而进一步缩短中断期间的切换时间并降低相关风险。

Web和API保护

应用及其API持续面临分布式拒绝服务（DDoS）攻击、机器人流量和API滥用。要增强韧性，应采用云端DDoS防护等解决方案，在攻击到达组织的基础设施之前将其吸收。这些解决方案必须能够大规模应对威胁，同时不降低应用或API性能。

这些工程实践相互配合，将网络韧性的概念支柱转化为可部署的架构，从而控制故障、确保服务在不同提供商之间保持可用，并在实际攻击条件下保护应用和API层。

F5如何助力提升网络韧性

F5将流量管理、安全和自动化整合到单一平台中，而非提供彼此独立的单点产品，帮助组织构建反脆弱架构。

F5 BIG-IP 和F5 Distributed Cloud提供智能流量路由和多云高可用性，帮助应用在云服务提供商或区域发生中断时保持运行。为缩小此类中断的影响范围，F5提供强大的零信任和Web应用及API保护解决方案，可限制隐式信任，在失陷凭据扩散前将其遏制，并抵御DDoS和机器人攻击，同时避免应用性能下降。随着组织将韧性扩展到AI系统，F5 AI Gateway 支持AI和智能体韧性所需的模型故障转移和提示词攻击遏制。

常见问题（FAQ）

网络韧性是否属于风险管理的一部分？

是。网络韧性在传统风险管理实践的基础上进一步拓展，认识到无论是攻击、服务中断还是依赖项故障造成的业务中断都不可避免。它不再仅仅着眼于降低中断发生的可能性，而是强调组织在故障期间持续运营并以尽可能小的影响恢复的能力。

零信任与网络韧性有何关系？

零信任原则通过实施持续验证和最小权限访问来增强网络韧性。零信任最大限度地减少用户、系统和服务之间的隐式信任，有助于遏制安全事件，并在发生故障或安全失陷时缩小影响范围。

BCP与网络韧性有何区别？

业务连续性规划（BCP）侧重于在事件发生后恢复关键运营。网络韧性的范围更广：它以故障必然会发生为前提，优先确保服务在中断期间持续运行，同时不断改进系统行为。

网络韧性是否适用于混合多云环境？

是的。现代应用依赖多个云服务提供商和第三方服务，因此中断发生得更频繁，也更难预测。即使外部组件发生故障，网络韧性也能确保业务连续性。

自动化能否提升网络韧性？

是的。自动化可缩短中断或攻击期间的人工响应时间。自动执行运行状况检查、路由决策和修复操作，使系统能够在问题升级前及时调整，尤其是在故障状况的发展速度超过人工响应速度时。

网络韧性是否只与网络攻击有关？

不是。网络攻击固然是一个主要问题，但许多中断源于配置错误、服务提供商服务中断和依赖项故障。网络韧性涵盖所有这些情形，确保在更广泛的运营环境中保持业务连续性。

网络韧性与传统网络安全和灾难恢复有何不同？

网络安全侧重于预防，在未经授权的访问和攻击发生前保护系统、网络和数据。灾难恢复则是被动响应，即在特定中断事件发生后恢复运营和数据。网络韧性以中断不可避免为前提，侧重于组织在事件期间持续运营的能力。它还融入了持续改进机制，使架构在每次中断后得到增强，而不只是恢复到之前的状态。

现代网络韧性生命周期的四大支柱是什么？

现代网络韧性生命周期包含四大支柱：预判、抵御、恢复和演进。预判利用威胁建模识别关键依赖关系，并确定可能发生故障的位置。抵御在架构中构建冗余和故障转移机制，确保主要依赖项性能下降时系统仍能继续运行。恢复通过自动化流程恢复正常运行，缩短中断后的停机时间。演进将遥测数据和事件分析结果反馈到架构中，使系统在每次中断后都比之前更具韧性。