因为一次惨痛的炸服事故，我开始找一些运维相关的书籍来看，其中这本书吸引了我的注意，因为我在寻找的并不是一本liunx系统指南或者命令大全，而是一种可以提高系统稳定性的思维。
《混沌工程》这本书不长，我大概用了1个小时就将其读完了，其中提到的许多思想颇具启发性。
不是第一次读netflix这家公司分享的内容了，之前还读过这家公司首席HR写的《网飞文化手册》，同样收获颇多，这家公司还挺有料的。
以下是读书笔记
混沌工程是一门新兴的学科，它的初衷是通过实验性的方法，让人们建立复杂分布式系统能够在生产中抵御突发事件能力的信心。
在一个复杂的分布式系统中，我们单靠人力并不能够完全阻止这些故障发生，而应该致力于在这些异常行为被触发之前，尽可能多地识别出会导致这些异常的、在系统中脆弱的、易出故障的环节。当我们识别出这些风险时，就可以有针对性地对系统进行加固、防范，从而避免故障发生时所带来的的严重后果。我们能够在不断打造更具弹性系统的同时，建立对运行高可用分布式系统的信心。
在判断你的团队是否已经准备好实施混沌工程之前，你需要回答这样一个问题：你的系统是否已经具备一定的弹性来应对真实环境中的一些 异常事件，像某个服务异常、网络闪断或瞬间延迟提高这样的事件。
实施混沌工程的另一个前提条件是配套监控系统，你需要用它来判断系统当前的各项状态。如果无法对系统行为进行观察，你就无法从实验中得到有效的结论。
在Netflix，并没有制度要求工程师一定要按照某种规定在构建所有东西。相反的是，高效的领导者会在工程师之间建立一种强有力的一致规约或原则，让工程师在自己的领域里找到解决问题的最好办法。
在业务正常进行期间，混乱猴子会伪随机地关闭生产环境中正在运行的节点，而且关闭的频率比正常节点发生故障的频率还要高很多。
混乱猴子的美妙之处就在于此，它尽可能地将服务节点失效带来的痛苦提前，同时让所有工程师在构建一个具有足够弹性应对失败的系统上，达成一个一致的目标。
康威定律：任何组织所做的系统设计（广义的系统）的结构，将不可避免地复制这个组织信息沟通的组织结构。
上述例子中最重要的一个特征是每一个单一的微服务的行为都是合理的，只有在特定场景下这些行为组合起来才会导致系统预料之外的行为。这一类交互的复杂性不是人力可以完全预料到的。
有各种开源工具和商业工具可以帮助我们采集系统方方面面的数据：CPU负载、内存使用情况、网络I/O以及各类时序信息，例如需要多长时间来响应一个Web请求，或者各类数据库的查询耗时。
所以通常来说，让你的系统有能力抓取业务级别的指标比抓取系统级别的指标更难。然而花精力来采集业务级别的指标是值得的，因为它们才能够真实地反映系统的健康情况。
这些指标获取的延迟越低越好；那些在月底算出来的业务指标和系统今天的健康状况毫无关系。
在我们这个行业里，在生产环境中进行软件验证的想法通常都会被嘲笑。“我们要在生产环境中验证。”这句话更像是黑色幽默，它可以被翻译成：“我们在发布之前不打算完整的验证这些代码”
如果你的系统部署在像AWS或Azure这样的云服务中，那么大量的你所依赖的、又不完全了解的外部服务的存在就是显而易见的。但即使你的系统全都运行在自己的数据中心上，你也会发现在生产环境中系统还是会依赖其他的外部服务，例如DNS、SMTP、NTP等。就算这些服务都是自己部署的，它们也经常会需要和不受你控制的外部服务进行交互。
如果服务提供了一个WebUI ,那么用户使用的浏览器就变成了系统的一部分，但它不受你控制。
如果你不愿意在生产环境中进行混沌工程试验的原因是，对系统在注入事件时的反映缺乏信心，那么这可能是你的系统还不够成熟以应对混沌工程的信号。
为了保障将来不会遭受大规模中断，冒一点可控的风险是值得的。
自动化是最长的杠杆。
在理想情况下，实验应该随着每次的变化而执行，这有点像混沌金丝雀。当发现新的风险时，操作人员如果相当确定风险的根源是即将发布的新代码，那么他就可以选择是否阻止发布新版本并优先修复缺陷。
在每年一次的演习中进行问题调查就很难，需要完全从零开始检查，而且很难确定这个潜在的问题在生产环境中存在多久了。
1986年4月26日，人类历史上最严重的核事故之一发生在乌克兰的切尔诺贝利核电站。具有讽刺意味的是，灾难是由于一次弹性演习导致的：一次验证冷却机泵冗余电源的演习。
设计混沌工程试验的细节
- 选定假设
- 选定实验的范围
- 识别出要监控的目标
- 在组织中沟通到位
- 执行实验
- 分析实验结果
- 扩大实验范围
- 自动化实验
熟练地使用混沌工程
- 在开发流程中的每个环节以及所有环境中运行试验
- 设计、执行和终止实验完全自动化
- 将实验框架和A/B测试以及其他测试工具集成，以减少噪声干扰
- 可以注入如对系统的不同使用模式、返回结果和状态的更高等类型的事件
- 实验具有动态可调整的范围以寻找系统拐点
- 实验结果可以用来预测收入损失
- 对实验结果的分析可以用来做容量规划
- 实验结果可以用来区分服务实际的关键程度
如文化般使用系统工程
- 对所有关键服务进行高频的混沌工程实验
- 对多数非关键服务进行高频率的混沌工程试验
- 混沌工程实验是工程师入职流程的一部分
- 所有系统组件都默认要参与混沌工程试验，不参与的话需要进行特殊说明