混合云和多云架构从根本上改变了韧性的考量方式。如今，应用横跨多个地区、服务提供商、SaaS平台、内容分发网络（CDN）、身份服务和边缘环境。这种广泛覆盖带来了敏捷性和规模优势，但也会引入系统性风险敞口。
但对于负责管理数字化业务所依赖的技术和基础设施的团队而言，问题已不再是中断是否会发生，而是底层架构能否通过工程设计控制中断影响、在中断期间灵活适应，并从中得到改进。正因如此，反脆弱网络韧性具有了战略意义。
“具备网络韧性的架构不只是“恢复原状”，还能在应对中不断调整，并在下次面对冲击时展现出更强的韧性。”
第1部分介绍了让网络韧性具备反脆弱能力的实践。现在，让我们进一步了解如何将爆炸半径控制、策略驱动的适应、多元化和持续学习落实到各层级，转化为实时事件期间及之后可采取的具体行动。
从韧性走向反脆弱
“韧性架构”传统上是指能够经受住中断。反脆弱韧性则在这一概念的基础上更进一步。
反脆弱系统可在中断期间限制影响范围，并在中断发生过程中进行适应。这些韧性实践会将中断带来的经验教训融入未来的架构行为，从而降低类似中断再次发生的概率及其影响。
反脆弱设计并不将故障视为例外，而是将中断视为正常运行状态。要大规模落实反脆弱能力，企业需要一套结构化框架。反脆弱韧性的五层模型可提供这一框架。
反脆弱企业的五个层级
这些层级定义了必须在哪些方面构建韧性。反脆弱实践则定义了如何提升韧性。二者相辅相成，将中断转化为架构演进的动力。
1. 全局层级：在系统级故障扩散前加以遏制
全局层负责管理跨区域和跨环境的通用服务，包括DNS、身份、联合信任和全局流量管理。在这一层，反脆弱韧性体现为健康感知策略：当依赖项出现波动时，系统会在工单创建前自动调整路由。这种设计可限制故障影响范围（名称、身份验证和路由），并利用全局备用方案确保用户流程不受影响。
此处的故障尤其危险，因为这些服务位于各个工作负载之上。一旦全局路由或身份服务发生故障，所有依赖它们的服务都会同时受到影响。
此层级的反脆弱实践侧重于三个要素。爆炸半径控制通过明确界定信任边界和故障边界，防止某个区域、云或依赖项发生的故障不受控制地蔓延。策略驱动的自适应是指用可响应当前状态的策略取代硬编码配置。流量路由、身份验证和信任决策必须动态调整。此外，依赖项多元化要求为关键服务引入替代方案，并对可选方案进行管控，避免由单一提供商决定系统行为。
当系统承受压力时，全局层必须强制实施信任边界和故障边界，并遵循策略驱动的路由机制，避免提供商级故障演变为影响整个企业的事件。事件期间需要重点关注的指标包括：流量自动重新路由的速度、身份验证成功率的变化、DNS故障转移时间，以及由备用服务处理的请求占比。
目标是防止单一提供商或控制平面事件左右整个企业的行为。全局服务必须遏制故障，避免将其扩大。
2. 站点层：提供受控隔离和备用执行区域
站点层定义区域执行域：云区域、数据中心和边缘集群。
在传统模型中，各区域是彼此冗余的副本。在反脆弱架构中，各区域则被设计为相互隔离的区域。每个站点都成为一个边界明确的故障域，具备三方面的能力。
独立运行要求以适当方式构建站点，使其既能作为更大聚合网络的组成部分运行，也能作为独立节点运行，从而在发生中断时为用户保留一定程度的功能。
受控故障转移可减少“多米诺骨牌”效应，并降低一个站点的中断蔓延至其他站点的可能性。通过规定站点进行故障转移的方式和目标位置，整个网络可以承受中断带来的影响。
备用执行路径是另一组关键功能。它们会主动将流量从发生故障的提供商引导至独立的备用路径，使关键服务避开故障路径。
系统承受压力时，站点层必须帮助各站点充当边界明确的故障域。流量应逐步排空或重新托管到其他区域或提供商，且不产生连锁影响。此层需要跟踪的关键指标包括站点隔离的平均解决时间、跨提供商流量迁出时间，以及具备预先验证的备用路径的关键服务占比。
依赖项多元化在此层级至关重要，因为企业必须确保在某个区域、CDN路径或网络传输提供商性能下降时，有可行的替代方案可用。此层级可将系统性风险转化为可管理的局部中断。
3. 平台层：自动执行响应并支持工作负载可移植性
平台层包括Kubernetes集群、虚拟化环境以及承载工作负载的任何计算基础设施。在混合多云环境中，可移植性和自动化能力决定了适应过程的启动速度，因为发生系统性事件时，人工响应周期过长。
此层级的反脆弱实践侧重于运行时自动化，帮助韧性企业实现响应自动化，从而在事件升级前开始调整。
另一项关键实践是工作负载移动性，即在多个环境中部署应用，以确保连续性，并构建由冗余且多样化的工作负载组成的网络。
在承受压力时，平台层必须能够帮助系统自动扩缩容，同时实施断路器策略，并能在事件仍在发展时切换容量或安全态势。在这一层，系统首次自动执行操作所需的时间、每次事件的策略变更次数，以及具备第二执行环境的工作负载占比，都是需要跟踪的关键指标。
当运行状况信号恶化时，路由决策、扩缩容行为和安全态势必须自动调整。自动化可确保系统在事件升级前开始适应变化，而工作负载多元化可确保关键服务始终可用。此层级决定了中断是导致平稳降级，还是引发级联故障。
4. 应用层：在不影响用户体验的情况下承受中断
应用承载业务逻辑并为用户创造价值。在传统架构中，应用故障往往与基础设施故障同步发生。
反脆弱设计引入了渐进式适应机制，包括采用优雅降级，而非直接发生完全故障。即使服务的大部分功能因中断或其他干扰而离线，团队也可以通过限制其功能来防止灾难性故障。
在压力情况下确定功能优先级，是应用层的另一个关键要素。这样，即使无法提供完整体验，也能确保核心用户工作流保持可用，同时避免可选功能导致重要服务中断。
智能重试和断路器是具备上下文感知能力的策略，可让应用在依赖项发生故障时自适应响应，避免陷入盲目重试循环，导致负载增大并加速故障。
应用层必须帮助非核心功能卸载负载，以帮助确保核心工作流保持正常。客户端应适应上游行为的合理变化（例如DNS或身份服务变化），避免出现惊群效应。请务必监控部分中断期间的结账和登录成功情况、重试预算消耗量，以及断路器的开启和关闭频率。
应用必须能够适应上游行为的合理变化，并假定身份提供商、DNS响应或API可能会在不另行通知的情况下发生变化。在此层级，韧性的衡量标准是用户体验的连续性，而非基础设施的正常运行时间。
5. 管理层：将运营事件转化为治理和策略改进
管理层涵盖可观测性、编排、分析和治理。如果治理缺乏遥测数据支持，韧性将停滞不前。事件只会作为工单结案，而无法推动架构改进。
此层级的反脆弱实践关注多项因素，其中包括以观测结果为依据的治理，即利用遥测数据指导决策。以压力条件下捕获的实际行为取代设计假设，有助于提升韧性。
为确保持续验证，应持续测试韧性假设、安全控制措施和架构行为，而不能仅在定期审计期间或发生中断后进行测试。
以实际行为为依据推动策略演进：将运营数据（延迟、错误、故障转移事件等）反馈至治理和编排框架，用于更新和完善策略，使系统能够从实际事件而非预测或假设中学习。自动生成的合规材料可将运营事件转化为可验证、可供审计的信息，同时尽可能减少人工投入。
管理层确保遥测数据成为治理输入。IT事件会生成更新后的路由和分段策略，以及可供审计的工件。
关键指标包括从事件关闭到策略更新所需的时间、促使控制措施发生变更的事件占比，以及自动生成的审计工件数量。
韧性由此上升为战略能力。每次中断都会为优化路由策略提供依据，从而改进分段、收紧信任边界并强化自动化逻辑。
各层级如何协同工作
该模型的优势在于集成。
- The 全局层级限制系统性扩散
- The 站点层级将故障限制在指定区域内
- The 平台层可自动调整
- The 应用层可保持用户体验
- The 管理层确保每次中断都能增强系统韧性。
通过一体化设计，这些层级可消除实践割裂所造成的脆弱性。
韧性不再仅由网络运维、安全运维或云运维团队负责，而是成为一种与治理、架构和高管战略相协调的跨职能运营模式。
将韧性作为一项战略能力
混合应用环境或许反而导致风险以前所未有的规模集中。少数超大规模服务提供商支撑着全球关键基础设施。企业利用这些技术，可以受益于其提供的规模和性能，但过度依赖少数提供商也会带来不必要的脆弱性。完全消除对外部服务的依赖既不可行，也不可取。
目标是确保您的架构不会以提供商始终正常运行为前提，也不会任由故障不受控制地蔓延。
韧性架构不会将恢复视为终点，也不会重蹈同一故障模式。反脆弱网络韧性重新定义了中断的意义，使其从运营困扰转变为竞争优势。
反脆弱网络韧性重新定义了中断，将其从运营困扰转化为竞争优势，并为每一层提出具体实践。全局策略遏制影响扩散；站点实施隔离和流量重路由；平台自动切换至备用容量；应用以可控方式降级，确保核心流程持续运行；管理机制将事件转化为策略资产。以这种方式构建的架构不只是“恢复原状”，还会在运行中不断适应，并在下次中断时展现出更强的韧性。
如需从反脆弱视角进一步了解网络韧性，请阅读我们之前的博客文章《混合多云网络韧性新指南》，并查看我们的解决方案概述。
如果您希望深入了解如何开始在网络韧性战略中实施反脆弱方法，请参阅这份架构白皮书。
想与F5团队探讨韧性？联系我们！
关于作者
Griff Shelley是F5产品营销经理，专注于硬件、软件和SaaS应用交付解决方案。他热衷于以创新技术助力客户取得成功，负责推动全球和本地应用交付、云服务及AI数据流量基础设施领域的市场推广项目。在投身科技行业之前，他曾担任高等教育学业顾问，并获得Eastern Washington University和Auburn University的学位。
Griff Shelley 的更多博客文章
Colin Clauset是F5高级产品营销经理，专注于基于SaaS的应用交付解决方案。他负责分布式应用交付项目和服务的市场推广工作，尤其热衷于探索如何利用技术简化复杂流程，从而更好地满足IT专业人员的需求。加入F5之前，Colin曾从事咨询工作，因此在应对客户挑战时，他着眼于超越单一产品的整体解决方案。
Colin Clauset 的更多博客文章
Mark Menger是F5解决方案架构师，专注于AI和安全技术合作伙伴关系。他负责开发F5的AI参考架构，推动安全且可扩展的AI解决方案。Mark曾担任全球解决方案架构师和解决方案工程师，参与构建F5安全云架构，并共同开发其分布式四层架构。他是《Solving IT Complexity》的合著者，在应对IT挑战方面拥有丰富经验。此前，他曾担任应用开发人员和企业架构师，专注于现代应用、自动化，以及加快实现AI投资价值。
Mark Menger 的更多博客文章相关博客文章
WAF和API发现技术在保护智能体AI应用中的作用
智能体AI系统的功能和集成会在运行时快速变化。要以同样的速度保障其安全，需要通过API发现和Web应用防火墙（WAF）实施切实可行的控制措施。
