2025年发生的多起备受关注的云和互联网基础设施事件提醒全球各地的团队：中断不可避免，而且其根源往往超出任何单一提供商或组织架构的范围。当主要云区域发生故障或全球流量平台运行异常时，依赖这些服务的应用会同时大规模出现故障，无论SLA承诺了多少个9的可用性。
这些事件凸显出一种结构性错位：许多企业仍以被动恢复的方式制定故障应对计划，而现代分布式系统的故障发生迅速、影响遍及全球，并且会跨越任何单一团队都无法独立负责的边界。现在的问题不再是“发生中断时该怎么办”，而是“在中断期间及之后，架构如何响应、调整并改进？”
混合多云环境中的韧性意味着什么
传统上，韧性策略侧重于恢复正常状态，包括灾难恢复计划、备用站点，以及恢复时间目标和恢复点目标（RTO/RPO）。这种思路假定故障仅限于局部，依赖关系已知，控制边界清晰。混合多云环境打破了这些假设：身份、路由、存储和数据分发通常由第三方负责，一旦发生故障，影响会立即波及全球。
“网络韧性的反脆弱方法将恢复的范畴从“恢复原状”拓展为“恢复原状、快速学习并不断增强”，使中断成为推动架构演进的动力，而非运营负担。”
网络韧性的“反脆弱”方法重新定义了韧性，将其视为一种可在压力下增强的能力。这种能力包括预见中断、限制影响范围、实时适应，并利用异常状况下的遥测数据优化架构，从而减轻后续类似事件造成的影响，甚至避免影响。衡量成效的标准包括：中断对系统的影响有多小，系统在中断期间的适应速度有多快，以及架构如何随之演进。
这种方法会带来一些非常明确的成效：爆炸半径更小且可控；依赖项性能下降时可用性更高；系统已预先做好适应准备，因此恢复时间更短；能够自动响应异常状况；韧性由自身架构保障，而非依赖外部服务，因此对外部服务更有信心。归根结底，采用“反脆弱”方法提升网络韧性，将恢复的范畴从“恢复原状”扩展到“恢复原状、快速学习并增强韧性”，使中断成为推动架构演进的动力，而非运营负担。
被动、孤立的策略为何会失败
有四种模式会使传统策略在混合多云环境中变得脆弱。首先，需要认识到外部依赖项的故障会影响全球。身份认证或路由中断会同时影响所有依赖这些外部依赖项的服务。此外，许多架构的故障隔离能力未能同步提升，导致跨云连接缺少遏制故障的边界，无法避免故障影响并行服务。
此外，许多环境中的韧性实践彼此割裂。灾难恢复、流量管理、身份管理和数据治理各自独立运行，但中断并不会局限于这些边界。
最后，请注意，恢复是一种被动响应。团队可以恢复服务，但并非总能（或有能力）从根本上防止问题再次发生。
当今的混合多云环境需要具备这样的韧性：不被动应对、不形成孤岛，也不依赖第三方提供商始终保持正常运行。
增强网络韧性策略反脆弱性的五项实践
网络韧性的反脆弱方法包含一系列可嵌入整个技术栈的工程实践，使系统在压力下仍能呈现可预测的行为：
- 故障影响范围控制。明确划定信任边界和故障边界，防止某个区域、云或依赖项发生的故障不受控制地扩散。
- 依赖项多元化。 为关键服务创建可行的替代方案。冗余不只是简单复制，而是提供可控的选择空间，避免由单一提供商决定系统行为。
- 策略驱动的自适应。使用可响应当前状态的策略取代静态配置，尤其是在路由、身份验证和信任方面。
- 渐进式调整。 通过小规模、可观测的架构增量，在不影响系统稳定性的前提下增强韧性。
- 基于观测信息的治理和运行时自动化。利用遥测数据指导决策并实现响应自动化，以便在事件升级前开始调整。
网络韧性由谁负责？（提示：每个人）
在混合云和多云应用交付中，无论是安全、网络、云运营职能还是服务提供商，任何一方都无法独自确保韧性。要真正实现韧性，需要采用协调一致的运营模式，使内部责任与外部依赖关系相匹配，并减少事件期间的职责不清。
这也有助于遵守欧盟《数字运营韧性法案》（DORA）等监管框架。该法案要求金融机构具备数字运营韧性，同时也有助于与ISO/IEC 27001）保持一致。该标准是全球广泛认可的信息安全管理体系标准。两者都强调学习、演进和验证运营健康状况。DORA明确要求机构不能只关注可用性，还应在中断后持续改进（“学习和演进”），将韧性与治理和自动化联系起来，而非仅仅关注恢复。
反脆弱企业架构的五个层级
为大规模推广这些实践，我们建议采用一个共享的概念框架：五层架构。每一层既是技术层，也是责任域，韧性会在其中形成，也可能在其中失效。
第一层是全局层，通过控制影响范围和基于策略的路由来管理外部控制边界和信任边界。接下来，该架构的站点层通过依赖项多元化和故障转移域来定义区域执行区和隔离区。平台层提供计算和数据执行能力，并支持运行时自动化和工作负载迁移；应用层则承载业务逻辑和用户体验，以支持渐进式适应和优雅降级。
最后，管理层集中提供可观测性、治理和编排能力，支持基于遥测数据持续优化策略。
将各层级与实践付诸应用
每个层级和实践在理论上都很理想，但要充分发挥反脆弱韧性策略的作用，就需要准确了解它们如何协同构建反脆弱架构。
在全局层面，爆炸半径控制和策略驱动的路由有助于在系统级故障扩散前将其限制住，从而尽可能降低对任何互联系统的影响。
在站点层面，实现依赖项多元化并提供故障转移域，有助于隔离中断，并通过备用执行区域确保业务连续性。
在平台层，运行时自动化和工作负载移动性可帮助系统快速适应各种中断。借助自动响应，系统可立即应对服务中断；工作负载移动性则支持将应用部署到多个环境中，以确保连续性。
在应用层，渐进式适应和优雅降级有助于缓冲各种中断，避免用户体验完全崩溃。即使发生部分故障，应用仍可继续运行，并将对最终用户的影响降至较低水平。
管理层的关键要求包括制定以遥测数据为依据的策略，这是将运营事件转化为治理和策略改进的最终成果。从中断事件中吸取经验可形成反馈闭环，从而根据历史数据优化策略，持续增强反脆弱能力。
这些层级和实践相辅相成，将中断转化为推动架构持续演进的动力，而不是让架构一次次回到原点。
这一理念的发展方向
这篇博文只是系列内容的一部分。该系列包括文章、架构和演示，将介绍反脆弱网络韧性策略五个层级中的模式、故障模式、指标和实施说明。
建议从上述列表中选择一项实践，将其作为冲刺目标或季度目标进行探索。请注意，反脆弱网络韧性策略并非一蹴而就，而是通过微小且可衡量的改变逐步形成。立即行动，快速学习，让下一次中断成为检验架构是否日益强韧的契机。
如需从反脆弱视角进一步了解网络韧性，请务必阅读我们的解决方案概述。
如果您希望深入了解如何开始在网络韧性策略中实施反脆弱方法，请参阅这份架构白皮书。
关于作者
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）实施切实可行的控制措施。
