在容灾项目实施过程中，往往要经历风险分析、应用关联分析、容灾架构设计、灾难恢复预案指定及演练等一系列重要的建设步骤和环节。其中，在风险分析环节，需要依据国家相关标准和规范，运用科学的方法全面识别用户数据中心信息系统自身的威胁及脆弱性，评估其一旦发生对业务系统可能造成的影响。同时，针对风险分析的结果提出相应的风险管控措施或建设性建议，以达到降低或消减风险的目的。
在风险分析过程中识别信息系统资产的重要性、面临的威胁、以及脆弱性是其中重要的步骤；
传统灾备环境中的资产及对应的威胁和脆弱性相对单一，往往以备份和存储为核心，同时结合数据库、应用集群和网络的切换完成容灾技术架构的构建，相关资产涉及机房、网络、服务器、存储和数据库等几项资产的脆弱性进行分析。
以往我们进行灾备项目实施时，都是对上述资产的预设场景进行分析，比如：
-
地震
-
火灾
-
操作失误
-
数据丢失或损坏造成的风险
-
系统/网络资源饱和风险
以机房级的故障场景为例，从 IDC 的维度上看，主要有机房入口网络故障、机房间网络故障以及机房掉电。如果精细化到应用层，又可以分为接入网关故障、业务应用故障以及数据库故障等，背后的故障原因可能是软件 BUG 或者部分硬件故障，比如机柜掉电、接入交换机故障等等。
但云环境下随着技术的迭代更新，敏态应用和DevOpS技术的快速演进，越来越多的分布式应用和云原生应用使用资源的技术栈不断涌现，导致系统的架构变得越来越层级化，微服务的出现导致彼此之间的调用和依赖关系越来与复杂。现代稳敏双态应用下的风险识别、IT环境应用和各类资源的关联和依赖分析，除了包括前述传统的灾难备份建设范围内的信息系统，以及所依赖的软件、硬件、网络、主机、存储、机房等基础环境外，往往还需要分析云环境下所依赖的各类云及其原生资源服务、如AZ（可用区）、Region（区域）失效风险，以及由于云服务化导致的应用依赖服务（日志服务、应用网关、各种PaaS平台、SaaS平台、容器等），比如：
• IaaS层服务：ECS、OSS、SLB、WAF、SDN…
• PaaS层服务：RDS、Redis、RocketMQ、PolarDB、Elasticsearch、MongoDB…
• SaaS层服务：语音服务、人脸识别、实人认证….
综上所述，现代敏态应用架构体系的变化，典型特点是：
• 分层架构，管理节点多
• 逐层关联，灾备建设复杂
• 应用由于敏态和DevOps的引入，变更和发布愈加频繁
云上应用的出现，通过服务化的方式，有力的保障了系统的扩展性，同时也造成系统的复杂度急剧上升，系统涉及的资产的数量和稳定的不确定性也随之增长。
应用的测试验收偏向于功能和自身非功能性的验证，如各类功能能否正常执行，用户高峰期的压力能否扛住。对于各类云上应用所依赖的资源发生的可能的故障，往往在SIT和UAT测试阶段很难穷举出来，也不是应用在上线前的测试验收阶段所关注的侧重点。
传统灾备的风险都是基于预设场景进行的风险分析及应对，但由于云化应用及微服务的引入，现实中的风险及故障往往更为复杂，单凭个人或组织的以往经验很难做到面面俱到。因此，这类故障因此也被称为不可预知的“黑天鹅”事件。“黑天鹅”事件的发生，往往没有对应的已知业务连续性预案去进行判断和解决。这些黑天鹅风险如果一旦发生，到底会有什么样的结果，有哪些是可以预料的，哪些是无法预料的则是混沌工程持续的探索和目标。
虽然预测不了“黑天鹅”什么时候会出现，但是可以利用混沌工程从故障中去寻求一些分类，并有针对性地对一类问题进行刺探和防御。比如现在的容灾架构就是一种灾难防御手段，它主要针对的是机房级的故障场景。混沌工程可以根据不同的系统架构和核心业务规则，让运维人员在复杂系统的认知层面上开辟出更具价值的风险应对空间。
混沌工程（Chaos Engineering），最初由 Netflix 提出来，目标是改变人们对软件系统缺陷和出现故障的不同视角和思维方式，既由故障的被动防御变为主动探索和进攻。混沌工程是一套基于在原来IT基础设施及应用资源上进行反复测试，找出系统及服务中存在风险的方法学。由于开发者的能力和认知水平也有边界，不可能所有的细节都可以预估到，系统很脆弱，各种潜在不可预期的突发事件在所难免，因此需要在异常触发之前，尽可能地去筛选出会导致出现有异常问题的、容易造成故障的、系统中明显裂痕的环节，就是混沌工程所肩负的意义，能让复杂系统中的混乱和不稳定性浮出水面，从而进行及时修复、加固和防患于未然，才能打造更具韧性的IT系统。
混沌工程提供了故障注入测试工具，可以注入各类失败场景，模拟系统由预料外的事件导致的问题，然后观察系统触发的可能的响应。比如通过模拟服务器宕机、重启、节点网络异常等来验证相关的基础设施及资源的主从切换，主从同步是否正常。通过模拟服务的不可用，服务间的网络通讯异常等来验证服务层的高可用。通过模拟调用延迟、服务不可用、机器资源满载等，查看发生故障的节点或实例是否被自动隔离、下线，流量调度是否正确，从而验证应用的强弱依赖是否正常，业务连续性的预案是否有效，同时观察系统整体的QPS是否受影响。
混沌工程最大的聚焦点是为了解决故障，快速地去事前发现可能的故障，快速地去解决故障。它与传统的容灾所谈的业务连续性不是矛盾的对立体，而是相辅相成的互补过程。换言之，混沌工程更偏向于对系统的高可用和很难预设的各类故障的应急响应的刺探；容灾的预设场景和计划则保障了灾难发生时，业务仍能持续在本地或者异地持续开展。
我们说混沌工程是对系统以模拟故障场景进行注入为起点进行的测试，并针对测试结果进行总结、分析评估、制定改进建议。这与容灾演练的预设故障场景演练有相似点，如下图所示：
1. 首先，混沌工程会调用注入异常来模拟失败部署发生的故障。而带来的影响应该要被隔离、限制在有限的范围内，既故障的故障域。由于混沌工程尽可能的需要接近真实生产环境进行故障注入，因此可以利用灾备环境进行仿真模拟，比在测试环境中可以获得更真实可信的数据结果
2. 一次故障注入后，对于混沌工程的演练应用分级是否合理，业务依赖是否合理、有无降级预案、服务降级后的处理效果、应用体验以及人员应急能力需要重新进行分析评估。混沌工程对应用系统中的每一个资源都有可能形成一个故障域，出现在对资源有强依赖部件之间，只要跟它有关系的，都有可能被影响到，只要注入故障的根因事件就会暴露出因为有些资源共享或者上下游调用而形成的故障域，从而形成新的应用及资源的关联关系分析
3. 根据评估分析结果，制定新的应急计划或者更新灾难恢复预案
4. 最终针对混沌工程结果，进入系统改进实施阶段，最终避免注入的故障再次发生或者故障域范围的扩大
混沌工程的引入，对于容灾和业务连续性是一种新的思想的介入，或者说是新的形式的补充。容灾的预设场景也会随着混沌工程的不断引入而变得越来越丰富。因此需要建立一种多元化的评价标准，结合应急处理流程、损害评估流程、灾难决策流程、灾难宣告流程、灾难恢复流程、重续运营管理流程等流程，综合评估实施混沌工程的价值与投资回报。
值得注意的是，混沌工程往往在生产环境中执行各种实验，这是与生产的稳定性要求是背道而驰的，因为用户和运维人员往往不希望打破线上的稳定状态。直接在生产环境做混沌工程测试，需要持谨慎态度，这是绝大多数用户的考虑点。因此在这种场景下，结合容灾的演练，在灾备环境中进行混沌工程的故障注入，一方面可以避免混沌工程测试导致的生产环境故障发生，另一方面还可以把容灾环境的各类资源有效地利用起来。
混沌工程的出现，和云尤其是公有云及大量云原生产生的各类服务密切相关。随着云服务渗透到各行各业，逐渐发展成为新的行业基础设施，对云应用的韧性和用户体验提出了更高要求，而混沌工程被验证可以有效检验云原生系统的韧性架构。通过混沌工程的故障演练，对业务系统进行平台、中间件、应用等各层次的丰富的故障注入演练，可以帮助企业发现更多未知的影响业务稳定性的隐患与问题，保障业务连续性的最终目标。同时，随着云上应用规模的不断扩大以及分布式系统的不断升级，可以在混沌工程的基础上，继续完善各种故障场景的研发，来满足系统日益增长的韧性需求。
