云化带来了更优雅的架构、更灵活的调度、更完善的治理的同时，也带来更多新的复杂性。

故障越来越难定位，故障越来越不可预知的复杂的云化系统里如何生存下去？现在，一个很好的答案就是 - Chaos Engineering，中文里面叫做混沌工程。相比于我们成天担惊受怕系统会出现什么样的问题，还不如提前就模拟线上环境可能出现的各种情况，来看我们的系统是否能做到容错，仍然能继续对外提供服务。

混沌工程是一门新兴的技术学科，初衷是通过实验性的方法，让人们建立复杂分布式系统能够在生产中抵御突发事件能力的信心。——《Principles of Chaos Engineering》可以理解成：一种类似于【疫苗】保护人体的方法。

常规测试，测试场景和结果已知。混沌工程，验证尚未明确结果的场景。

08年Netflix决定把它的业务迁移到AWS上，从自身运维的角度考虑，它有很多担忧的地方。很长时间内有两套系统在同时运行，运维的复杂度更高了。Netflix的用户量已经达到了1亿，对应用稳定性依赖很高，如果出现故障对用户的影响非常大，甚至是致命的业务不断复杂，引入微服务架构，对应用的高可用性要求越来越高。生产环境非常复杂，是多样性的，很难在测试环境中完全模拟生产的状态。Netflix决心探索一种在生产环境验证应用高可用性的一种方法，这就是现在大家所熟知的混沌工程。

相较于初级的混沌工程产品，同创永益混沌工程演练平台拥有丰富的可扩展的故障库，除可为企业提供所有基础的，几乎涵盖所有的已知故障外，还支持自定义来扩展故障库。同时，在演练过程中，可为企业提供完善的业务保护方式，对演练环境快速进行恢复，同时提供业务沙盘功能，在充分模拟真实环境的隔离环境下进行演练，增强演练安全性。此外，基于内部故障演练经验，同创永益混沌工程故障演练平台提供丰富的预定义故障场景，涵盖基础服务、微服务治理、云原生容器编排、备份容灾等场景，企业用户可以轻松对场景进行扩展，或将历史实验沉淀为场景库。基于工作流引擎的场景编排，支持并行、串行的组合，以及定时自动执行的流程定义，演练过程灵活可控，可随时终止演练。对于企业而言，通过同创永益混沌工程演练平台，企业可验证系统稳定性，发现系统或应用的薄弱点；验证微服务的容错能力与防护手段；验证业务编排与配置是否合理；验证监控的发现能力及告警系统的有效性；验证灾备方案、应急预案的适用性和可用性等，让故障处理变被动为主动，业务系统更安全。

通过模拟物理机宕机，重启，节点网络异常等来验证基础设施主从切换，主从同步是否正常。通过模拟服务的不可用，服务间的网络通讯异常等来验证服务层的高可用。

通过模拟调用延迟、服务不可用、机器资源满载等，查看发生故障的节点或实例是否被自动隔离、下线，流量调度是否正确，预案是否有效，微服务的强弱依赖是否正常，同时观察系统整体的QPS或RT是否受影响。

通过模拟杀服务Pod、杀节点、增大Pod资源负载，观察系统服务可用性，验证副本配置、资源限制配置以及Pod下部署的容器是否合理。

除提供所有基础的，基本上涵盖所有的已知故障外，还支持自定义来扩展故障库。

提供完善的业务保护方式，对演练环境快速进行恢复，同时提供业务沙盘功能，在充分模拟真实环境的隔离环境下进行演练，增强演练安全性。

基于工作流引擎的场景编排，支持并行，串行的组合，以及定时自动执行的流程定义，演练过程灵活可控，可随时终止演练。

某银行目前也在进行IT架构转型，微服务化，容器化，云原生化。使用的自研的容器云，随着业务的逐步迁移，平台出现过瘫痪事件，从稳态到敏态的转型过程中，加强平台稳定性的需求迫在眉睫。

平台部门负责的Mysql，nacos，sentinel，sequence等组件在高负荷，故障发生时的高可用性，弹性，稳定性如何？存在着很高的不确定性。

随着应用逐步的迁移，由于应用的编排，资源限制，弹性伸缩配置等的配置在高负荷，故障发生时是否会导致平台的不稳定发生。在负荷高，故障发生的情况，应用的幂等性是否有效。怎么和区分是平台的问题，还是应用的问题，也是他们非常担忧的点。

该商业银行在进行新核心系统改造，微服务化，容器化，云原生化的过程中发现：如何在上生产前验证平台以及应用的稳定性？需寻找一种机制确保在 IT 架构转型过程中所有业务可以稳定对外提供服务。CNBR根据信通院发表的云原生构建的业务应用的能力成熟度评估模型，从基础平台、应用研发域、服务治理域等方面评估该银行云原生业务应用在弹性、高可用、自愈性、可观测性以及自动化等方面的云原生能力成熟度。