Chaos Monkey模型
模型
实验目标
混沌工程是一种通过实验探究的方式来让我们理解系统行为的方法。通过设计和执行实验，混沌工程让我们了解特定的系统，帮我们发现系统中潜在的、可以导致灾难的或让我们的用户受损的脆弱环节，推动我们解决这些存在的问题。混沌工程、故障注入和故障测试在侧重点和工具集的使用上有一些重叠。混沌工程是发现新信息的实践过程，而故障注入则是基于一个特定的条件、变量的验证方法。
实施混沌工程的前提条件包括系统是否已经具备一定的弹性来应对真实环境的一些异常事件，例如服务异常、网络闪断或瞬间延迟提高；配套监控系统来判断系统当前的各项状态；考验软件工程师的优化能力。
设计实验细节
建立稳定状态的假设
通过选择指标，来确定系统是否处于健康稳定状态。这些指标获取的延迟越低越好而且要考虑和底层架构的关系，例如：系统吞吐率、错误率、99%以上的延迟。在 Netflix，SPS 也随事件波动，但是有一个稳定的模式。
我们的假设是，实验措施不会使系统行为偏离稳定状态，还可以定期执行演习，目的是验证在进行这类故障恢复的时候，SPS 不会偏离稳定状态。即使出现偏离稳定状态的行为，我们也可以测量出这个偏差。例如，发现访问 Redis 时有超时报错的情况，确保系统并不会被缓存访问超时影响。下图是 SPS 图表信息：
设定实验范围
在这里，我们应该要理解两个原则“在生产环境中运行实验“和“最小化爆炸半径“。在生产环境中执行实验之前，应该现在测试环境中试一试。一旦进入生产环境，就一定要从最少的用户流量开始尝试。例如，如果要验证系统在缓存超时会怎么做，可以先用一个测试客户端来调用生产环境的服务，并只针对这个客户端引入缓存超时。
混沌工程师的一项专业职责就是要理解和降低生产风险，可以为实验设计良好的系统，以阻止大规模的生产事故，将受影响的用户数量降到最少。不幸的是，我们经常运行本来只会影响一小部分用户的测试，却由于级联故障无意中影响到了更多的用户。在这些情况下，我们不得不立即中断实验。虽然我们绝不想发生这种情况，但随时遏制和停止实验的能力是必备的，这可以避免造成更大的危机。我们的实验通过很多方法来探寻故障会造成的未知的和不可预见的影响，所以关键在于如何让这些薄弱环节曝光出来而不会因意外造成更大规模的故障。我们称之为“最小化爆炸半径”。
对于此类实验，你需要用定义好的成功指标来过滤所有被影响的用户，以防实验的影响被生产环境的噪声掩盖。小规模扩散实验的优势在于，它不会触及生产环境的阈值，例如断路器的阈值，这样你便可以验证每一个单一请求的超时和预案。这可以验证系统对瞬时异常的弹性。我们强烈建议实施自动终止实验，尤其是在定期自动执行实验的情况下。关于弄清楚如何构建一个可以实时监控我们感兴趣的指标，并可以随时实施混沌工程实验的系统，这完全依赖于自己独特的系统构造，。为了尽可能高效地应对实验发生不可预料的情况，我们要避免在高风险的时间段运行实验。例如，我们只在所有人都在办公室工作的时间段运行实验。如果实验的工具和仪器本身就会对定义好的指标产生影响，那么整个混沌工程的目的就被破坏了。我们要的是建立对系统弹性的信心，记住每次只检验一个可控的故障。
识别出要监控的指标
尽可能用指标来验证假设。例如，假设是，即使主数据库出现故障，所有服务也都能正常进行。运行实验前清晰定义什么是正常，可以用一个明确的业务指标，比如“每秒订单数”，“响应时间”，“响应错误率”，明确指标合理数值范围。可以预先设定好阈值，例如失败请求占比不能找过 5%。如无法准确定义稳定状态，则使用多个指标的阈值联合进行对照
- 业务性指标：价值最大，探测难度最大-Netflix SPS 业务指标
- 应用层指标：健康状况
- 基础设施指标：较易获取，只反映基础设施的运行状况
- 执行实验
在执行实验的过程中，要盯住那些指标，因为你可能随时需要终止实验。随时终止实验的能力异常关键，因为现在是直接在生产环境中运行实验，随时都可能对系统造成过度危害，进而影响外部用户的使用。例如对于一个电子商务网站，你一定要密切关注用户是否能够正常结算。要确保有足够的报警机制，能实时获悉这些关键指标是不是掉到了阈值以下，确保有告警机制，能实时获悉这些关键指标是否超过阈值。
分析实验结果并扩大实验范围
用选定假设来制定的指标数据来验证假设是否成立，是否具有足够的弹性。扩大实验范围的目的是进一步暴露小范围实验无法发现的一些问题。例如，微服务架构中存在少量的超时或许不会有什么问题，但超过一定比例就可能会导致系统整体瘫痪。
自动化实验
当今系统的复杂性意味着，我们无法先验地知道，生产环境的哪些变动会改变混沌工程实验的结果。基于这个原因，我们必须假设所有变动都会改变实验结果。在共享的状态、缓存、动态配置管理、持续交付、自动伸缩和对时间敏感的代码等因素的作用下，生产环境实际上处在一个无时不变的状态。这导致的结果就是，对实验结果的信心是随着时间而衰减的。
在理想情况下，实验应该随着每次的变化而执行。设计混沌工程实验的挑战并非来自定位导致生产环境崩溃的原因，这些信息在故障跟踪中就有。我们真正想要做的是，找到那些本不应该让系统崩溃的事件的原因，包括那些还从未发生过的事件，然后持续不断地设计实验进行验证，保证这些事件永远不会导致系统崩溃。然而这是非常困难的。导致系统波动的原因非常多，我们不可能有足够的时间和资源穷举所有可能导致问题的事件及其组合。所以我们需要周期性自动化运行实验，持续从中获得更大的价值。
软件能力成熟度模型（CMM）
软件能力成熟度模型（CMM）是一种对软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述形成的标准。软件能力成熟度模型（CMM）给我们提供了一个评估当前混沌工程项目成熟度状态的途径。把当前项目的状态放在成熟度模型图上，你就可以据此设定想要达到的目标，也可以和其他项目的状态进行对比。如果你想要提升这个项目的状态，CMM 的坐标轴会给出明确的方向和建议——应该朝哪里努力。
CMM 的两个坐标轴分别是“熟练度”和“应用度”。缺乏熟练度的时候，实验会比较危险、不可靠，且有可能是无效的。缺乏应用度的时候，所做的实验就不会有什么意义和影响。要在适当的时候变换在两个不同维度上的投入，因为在任何一个时期，要发挥混沌工程项目的最大作用都需要在这两个维度上保持一定的平衡。
根据上表中的信息，给出基于架构抵御故障能力、试验指标设计、实验环境选择、实验自动化能力、实验工具使用、故障注入场景爆炸半径范围、环境恢复能力、实验结果整理的八个方面的可行性评估问卷。