曹付江，中国移动磐基混沌工程团队GO架构师
首先，我们要明确的是：混沌工程本身原则就是通过不断试错的方法来管理风险。实践证明，避免失败的最好办法就是经常失败。通过主动破坏自身环境，来发现系统的弱点。频繁的故障演练使开发团队能从问题中学习经验，从而对服务集群的稳定性有更高的重视。
由于演练对象和演练配置的差异，在生产环境进行试验可能会对生产环境造成不确定的影响，但混沌工程师的责任和义务是确保这些后续影响最小化且被考虑的范围。
对于实验方案和目标进行充分的讨论和验证是减少用户影响和破坏重要的手段。但是从实际的实施角度看，最好还是通过一些措施去最小化影响。因此，可以考虑以下方面尽可能保障生产环境的演练不被破坏：
一、管理方面
1.1、演练人员要做到熟练使用，了解清楚具体某个实验的配置/参数的作用，做到有的放矢；
1.2、生产环境故障注入前，先在测试或者沙盒环境验证和测试, 评估该故障对上下游的影响范围，做到心中有数；
1.3、选择合适的时间段进行演练：故障注入时间应选择空闲时段；
1.4、针对可能破坏的演练，提前做好备份计划和容灾预案，以防不时之需。对真实的业务场景进行混沌演练，就需要对业务场景的相关服务和调用关系进行链路梳理，一般需要根据实际业务场景，画出系统交互图，通过链路串联、数据追踪、和上下游确认等方式整理链路图，方便出现问题利于排查定位；
1.5、混沌演练之前，一定要好可行性评估，评估可以演练的服务部署环境、演练工具的成熟度、演练场景的爆炸半径等，然后决策演练场景，进行实践操作。
二、技术方面
混沌实验通过很多方法来探寻故障会造成的未知的、不可预见的影响，关键在于如何让这些薄弱环节曝光出来而不会意外造成更大规模的故障。我们称之为最小化“爆炸半径”。由于混沌工程实验可能会给业务系统带来风险，所以对于爆炸半径的控制要始终贯穿于整个实验过程：
2.1、针对所有的故障注入对象，通过matcher匹配器参数，筛选到故障注入点：实现Node、Pod、Container，host等最小化实验对象以及namespace的隔离；
2.2、具备筛选实验流量的能力，比如配置的network policy实施流量挡板控制，生产实验数据导流；
2.3、数据层面
① 数据特殊标记： 针对标记的数据进行实验，实验后按规则及时恢复； ② 数据范围控制： 先只作用于很少的用户之上，当自动化实验成功之后，运行小规模的扩散实验，再进行小规模的集中实验，最后就是大规模无自定义路由的实验。扩大实验范围的目的是进一步暴露小范围实验无法发现的一些问题。
2.4、实施监控系统稳态指标变化，如果发现稳态指标超过指定的阈值，影响较大，系统支持立刻终止混沌实验，以确保演练的安全。
2.5、把混沌工程看作是为了揭示系统的弱点而进行的实验，实验中可分为「控制组」和「实验组」：
- • 控制组：保持“稳定状态”，对照变化的实验组；
- • 实验组：引入一些“故障变量”，如服务器重启、硬盘IO负载高、网络连接延迟，cpu高负载等等
通过这两组之间的稳定状态的差异来验证系统对故障的容错能力。注入故障后破坏稳定状态的难度越大，我们对系统的信心就越强。
举例如下：验证系统故障容错恢复能力
① 设定系统故障容错的假设： API 服务调用 Gallery 服务，当 Gallery 不可用时，API 对 Gallery 的故障可优雅降级，不会导致系统不可用 ② 设定实验范围： 生产环境中，通过切小部分流量的方式，创建实验组、控制组环境 ③ 故障注入： API 调用 Gallery 的 rpc 请求注入中断故障 ④ 稳态验证： 通过 GetGallery 监控指标进行容错假设的验证，预期故障注入后：
- • 控制组：大量SuccessCount（请求成功数）
- • 实验组：大量FallbackSuccessCount（成功降级数），极少数FallbackFailureCount（降级失败数），表示 API 对 Gallery 的故障降级 fallback 生效
- • 在实验组注入故障后，监控指标能快速恢复至预期，可以认为系统是具备故障容错恢复能力的，否则就存在弱点。
2.6、结合使用监控报警、日志排查等平台工具实时收集服务器在混沌演练运行期间的性能状态，错误信息，如系统层面的 CPU、内存等使用情况，观察方法的响应时间、成功率等指标，一方面验证在混沌场景执行期间系统状态是否达到预期的效果，同时记录演练期间发生的问题，记录现场，另一方面通过监控发现有风险问题进行人工干预，立刻终止演练。
三、以中移磐基CMChaos混沌平台生产环境落地过程予以分析讲解
首先，可以把故障分成五种类型：机房问题、中间件问题、机器问题、应用问题、依赖问题。
其次，从应用架构的层次来看的这五类问题，从上往下看，出问题的概率越来越小，但是影响却正好相反，是越来越大的。比如，机房层网络挂掉或者大规模的机器实体机被中断，这些情况出现的概率很小，但只要出现一个就意味着是非常大规模的影响，而且它恢复时长相对会比较长。我们之所以要去看这样的结构和层次，其实这跟我们的混沌工程实践路线是有关系的。
刚开始做混沌工程是要考虑性价比的，即先去解决我们认为最重要的事情。对企业来说，可以优先做机房层和中间件层，因为这些问题当中，中间件和基础设施出问题的概率较高，影响也大。所以这里引出来一个点：混沌工程的实践路线到底应该怎么去落实。
2021.1-2021.4 基础设施演练： 比如上面提到的机房设备、网络设备，虚机等。这种基础设施的演练，适合稳定性保障非常弱的时期，在这里出的问题影响面往往比较大，所以做基础设施演练的收益就会比较明显。
2021.5-2021.8 中间件层演练： 中间件这些基础公用的产品组件。这种对象的演练，也适合稳定性保障非常弱的时期，中间件作为公共设施出的问题影响面也会较大，所以做中间件演练的收益也会比较明显。
2021.9-2021.11 应用层演练： 这个阶段实践的主要对象是应用的各类进程问题。当大规模的故障已经得到了基本保障，但是应用状态频出，此时就可以考虑落地应用演练了。
2021.12-2022.6 依赖层演练： 主要针对系统所有的外部依赖，如 HTTP 接口或者 RPC 接口等，即使应用本身没有问题，但是依赖的资源出现问题时系统也会被拖垮。此时，就需要做服务治理的问题预防。当然，如果服务治理从来没出现过任何问题，这个可能价值就不会那么大。
2022.7-2022.9 攻防演练（红蓝对抗）： 前面的演练都是针对系统的，攻防演练的对象主要是开发、质量保障、运维或者SRE等人员。当混沌工程的系列工具和机制已经相对完善，但是人员在应急情况下的处理能力还是不足的时候就可以做攻防演练了。
以上是中移磐基混沌工程生产环境实践落地路线，也非常推荐大家按照这种路线来做，从性价比由高往低的方式去推进。
关于中国移动磐基CMChaos混沌工程团队
中国移动磐基CMChaos混沌工程团队是一支专注于云原生混沌工程体系化建设和信创创新产品探索的团队。通过深度定制研发的CMChaos混沌工程平台，满足各行业复杂业务场景的需求，在信通院的评估中获得《混沌工程成熟度》标准认可，在应用成效度和组织建设度方面为最高级别卓越级；同时通过不懈努力，团队为ChaosBlade阿里开源社区认证的最高级别贡献者Maintainer。
CMChaos混沌工程平台不仅仅是一种技术工具，更是一种管理工具，其核心目标是确保业务连续性。通过该平台，企业能够降低成本、提高效率，助力数字化转型实施，并为我国云计算产业高质量发展提供坚实技术保障。
