《混沌工程》notes

译者序

• 系统可用性面临的两大挑战：软件系统自身复杂度的激增，开发者在引入复杂性的同时对风险的低估和忽视
• 混沌工程理论构建于塔勒布在《反脆弱》一书中所阐述的思想之上，即系统如何在不确定性中获益，让系统在每一次失败中获益，然后不断进化，这是混沌工程的核心思想

第一部分：混沌工程介绍

第一章：为什么需要混沌工程

• 混沌工程与故障注入、故障测试的不同之处在于，混沌工程是发现新信息的实践过程，混沌工程实验能够产生新的认知，而且通常还能开辟出一个更广袤的对复杂系统的认知空间
• 混沌工程实验的可能性是无限的，根据不同的分布式系统架构和不同的核心业务价值，实验可以千变万化
• 实时混沌工程的前提条件：其一要回答这样一个问题：你的系统是否已经具备一定的弹性来应对真实环境中的一些异常事件，像某个服务异常、网络闪断或瞬时延迟提高这样的事件。其二是配套监控系统，你需要它来判断系统当前的各项状态

第二章：管理复杂性

• 软件工程师通常会对三个方面进行优化：性能、可用性、容错能力、（可能还有第四个：新功能迭代的速度）
• 康威定律：任何组织所做的系统设计（广义的系统）的结构，将不可避免地复制这个组织信息沟通的组织结构。 — Melvin Conway, 1967
• “牛鞭效应” - 输入中的一点扰动便会触发一个自我强化的循环，最终导致输出结果的剧烈波动
• 在复杂系统中，每一个单一的微服务的行为都是合理的，只有在特定长接下这些行为的组合起来才会导致系统预料之外的行为。这一类交互的复杂性不是人力可以完全预料到的。期待架构师理解和发现这些预料之外的行为是不合理的。各种测试和集成测试也无能为力
• 混沌工程提供了可以让这些效应付出水面的工具，从而让我们建立对复杂分布式系统的信心

第二部分：混沌工程原则

• 实验 - 通过实验可以主动高效地发现系统的缺陷，由于复杂性的存在甚至有些缺陷只能通过实验发现
• 故障注入测试(FIT) - 实验的具体实施方式

第三章：建立稳定状态的假设 - 要能够准确判断系统的正常/非正常状态

• 将系统正常运行时的状态定义为系统的稳定状态
• 用业务指标来描述系统的稳定状态
• 进行混沌工程实验的时候，应该首先在心里对实验结果（系统稳定状态的变化趋势）有一个假设

第四章：用多样的现实世界事件做验证

• 在决定引入哪些事件的时候，应当估算这些事件发生的频率和影响范围，权衡引入他们的成本和复杂度
• 文化因素也是一种成本，譬如传统数据中心的文化中基础设施和系统的健壮性、稳定性高于一切，要频繁关闭节点会面临文化上的阻力
• 故障的影响范围和隔离范围被称为这个故障的故障域。发现和验证故障域以确保满足产品的可用性预期是工程师团队的责任
• 实施混沌工程时采用故障域的概念具有一定的乘数效应。譬如，为应对高负载而建立的动态扩缩容能力同时也可以应对单实例故障、资源耗尽等多种其他故障。
• 每个资源都会形成一个故障域，这个故障域包括所有对它的强依赖的部件
• 在对故障域有充分了解的情况下，只需要向系统注入那些频繁发生且影响较大的事件即可，无需穷举所有可能得事件
• 在做系统架构设计时就要考虑故障域，面向失败的架构设计

第五章：在生产环境中进行实验

• 要对生产环境的系统建立信心，所以当然需要在生产环境中进行实验
• 一些威胁只存在于生产环境中，因为它们依赖于系统的状态
• 生产环境中有难以模拟的真实用户的输入（各种奇怪的输入）
• 第三方系统，生产环境是你的系统和第三方系统进行真实交互的唯一场所
• 生产环境一直不断变更，测试环境无法模拟
• “外部有效性”：实验结果是否能概况我们真正感兴趣的情况？如果不在生产环境中进行实验得到实验结果，那么并不能认为在生产环境中也会得到同样的结果，所以所做的实验就是无效的
• 如果实在不能在生产环境中进行实验，也要尽可能地在离生产环境最近的环境中进行。离生产环境越近，外部有效性威胁就越少，对实验结果的信息就越足

第六章：自动化实验以持续运行

• 自动化是最长的杠杆
• 自动设计实验 - 一个值得关注的自动创建实验的研究是一项叫做正确路径驱动的故障注入（Lineage-Driven Fault Injection, LDFI）的技术

第七章：最小化爆炸半径

• 混沌工程实验应该只承受可以衡量的风险，并采取递进的方式，进行的每一步实验都在前一步的基础之上
• 随时遏制和终止实验的能力是必备的，在实验造成过多伤害时及时终止试验
• 强烈建议实施自动终止实验，尤其是在定期自动执行实验的情况下
• 避免在高风险的时间段运行实验
• 每次只检验一个可控的故障

第三部分：混沌工程实践

• 略