正确认识混沌工程

混沌是一种模糊不清的状态。混沌工程描述一种在对企业 IT 模糊不清的认知环境下持续探索、通过对可能影响稳定性的因子的改变来检测其影响、并通过相应的方式来消除或降低影响，从而使系统面对异常时具备韧性的系统性工作。也就是需要不断地探索和深入了解存在的系统环境，在混沌的环境中开天辟地，随着认知的提升，使之达到一种清明。认知的提升是一个过程，所以不能对混沌工程有不切实际过高的期望，想当然的认为它可以无所不能。

混沌工程本质上是一种方法，一种探索系统不稳定性因素、提升系统抗脆弱性能力的方法。它并不能自动识别不稳定因素所带来的故障根因，需要借助于人的介入和经验知识并解决出现的故障。而这些经验和知识可以加入知识库，利用知识库实现智能运维。其实信息化这么多年我们对系统的认识已经积累了很多经验和知识，只是我们难以穷尽影响系统稳定性的因素。是因为想不到，所以需要不断的探索和实验。这也是混沌工程建议在生产环境进行实验的原因，因为同样的因素在不同的环境所带来的影响可能是不一样的。如同流感病毒对不同的人所感染的结果可能是不一样的。不过一旦感冒过一次，身体就具备了抗体，就具备了抵抗力。混沌工程就是要主动感染流感病毒（主动注入故障）等，测试系统的抵抗能力，发现系统的免疫弱点，采取合适的措施来增强免疫力，从而使系统面对病毒侵袭时不会一击而溃、更具有抵抗力和韧性。

混沌工程的目的是将系统运行过程中的不确定性逐步变为确定性，使之具备稳定性，通过对系统内不稳定因素的探索，根据实际情况采用高可用、备份、安全等手段增强可用性，提升抗脆弱性，也就使系统产生了抗体，在出现异常的时候具备韧性。比如说可以采用多活、主备切换、快速恢复、故障自愈等手段增强系统韧性。

混沌工程的难点其实就是对不确定性的探索。混沌工程实施的首要原则虽然是 “ 最小爆炸半径（影响范围） ” ，但往往由于认知有限，你可能无法知道水面下的深度是多少，可能难以控制爆炸半径，所以混沌工程的实施往往需要有丰富经验的专家的指导。混沌工程实施前期更多是咨询和评估也在于此。它和具体的场景相关，不同的场景、工具、架构等所需要设计的用例也是不一样的。不过一些通用性的用例还是非常有助于理解混沌工程的工作，比如说中国信息通讯研究院推出的“‘稳保计划’ -- 系统稳定性体检工程”就非常有助于认识和理解混沌工程，也可以在其指导下对现有系统稳定性进行评估。从而对现有系统的稳定性和免疫能力在心里有个底，然后根据实际情况进行加固和调整。

混沌工程是持续性的探索工作。它不是一个项目或几期项目能完成的，所以自身团队培养和自身能力的建设非常重要。知道的越多，知道自己不知道的就越多，需要探索的就越多。混沌工程就是持续探索未知，变未知为已知的过程中，就增强了系统的稳定性和韧性。也因此，混沌工程实施的时候需要专业的人员和团队。在确定实施混沌工程之前，最好先组建有一定经验、互补性的团队。有一定经验才不会面对实际系统异常时手足无措，互补则可以相互支持，这样更有利于快速定位问题和解决问题。

混沌工程多用于复杂的分布式系统之中。容器、微服务等云原生分布式环境往往是其大展身手的地方。在这样的云原生环境中往往微服务众多、层次关系繁杂、依赖链路复杂，特别如果架构设计不合理，导致整个系统的复杂度成数十倍几十倍增加，特别一些不加分析引入不必要的组件、补丁化集成等，无谓增加系统复杂性，失去对稳定性的控制，增加众多风险点和脆弱点，也使出现异常时定位困难。所以最初其起源于云平台，尝试通过探索系统脆弱性来采取措施增强其韧性。

混沌工程是个系统化、体系化的工作。之所以被称之为 “ 工程 ” ，就是因为其本身就是一个复杂系统。人、组织、技术、数据、基础设施、方法论等都是这个系统中的元素。面对复杂系统时需要将其解析为一个个相互联系的简单子系统，因此混沌工程是需要有个顶层的规划和设计，然后进行细分。如果从某个子系统开始，可能面临着一些限制和无法管控的爆炸半径。复杂系统拆分也是进行混沌工程用例设计的前提，只有明确的场景才能设计出合理的用例。

混沌工程日常主要的工作就是混沌工程用例的开发。每个用例都意味着向一个新的领域的探索，前面可能是一马平川，也可能是悬崖绝壁，或者隐藏着陷阱等等。这可能需要去考虑将系统分层、分场景、分阶段。例如区分应用、数据、平台组件、基础设施资源、安全、架构层次等、例如区分简单场景的应用访问控制和复杂场景的应用访问控制、例如业务上线初期和积累一定量数据之后的阶段，可能都需要分别去对待。运行着的系统是在不断的变化之中，新加的节点空间可能随着时间的流逝被日志占满而导致不可用，也可能 file descriptors 达到设置值无法打开系统文件等等。每个组件、每个参数的设置都可能会存在着问题，所以需要不断的去设计用例、持续的去验证、持续的去发现问题、持续的去解决问题，才能持续的增强系统的韧性。

混沌工程平台主要是支持混沌工程用例的开发和管理，以及对验证结果的管理和辅助分析。有些用例是可以自动化来执行，但复杂的用例可能难以自动化，有时往往涉及多个层面，需要多个团队配合，所以需要一个相对顶层的规划和指导。混沌工程探索验证的结果可以作为知识库的内容，用于自动化或智能化测试和运维。

虽然混沌工程评估需要做一些测试，但混沌工程不是用于测试的，混沌工程演练用例也不是测试用例，不是用来测试系统是否有异常的，而是侧重于对影响系统稳定性因素的探索。混沌工程和测试就如同没有导航和有导航的行路，其结果和效率是不一样的。混沌工程可以探索开发出很多新的路径，但可能需要花费很多时间；测试是对已知期望结果的验证，如同导航对已存在的路径进行路程设计，可以持续回归。虽然说混沌工程的一些用例可以作为测试用例，但用法和目的本质上是不同的。

混沌工程更多需要依靠经验，其前期落地更多是一种咨询性质的指导性实施，也是一个学习和提升认知的过程。在这个过程中尽可能找出影响某项业务指标的潜在因素，学会设计和开发混沌工程用例，掌握分析系统脆弱性的方法，以及掌握常见的系统脆弱性设计案例，用已知的知识和方式去探索未知的领域，在探索的过程不断的学习和提升。

抗脆弱性设计（韧性设计）是系统设计实施过程中一项重要工作，特别对于分布式系统，各个组件之间存在依赖关系和联系，一个关键组件的异常可能会带来系统性风险。混沌工程的知识和方法可以应用于系统的抗脆弱性设计之中，使系统在设计之初就具备相应的抗脆弱性意识，在实施完成之时就具备韧性和稳定性。

总的来说，混沌工程会越来越多的应用于分布式系统之中，特别越来越庞大、越来越复杂的云原生环境，需要借助混沌工程的方式来持续探索和减少脆弱的节点，持续增强抗脆弱性能力，从而适应和满足不同场景下的稳定性、韧性需求。