读发布！设计与部署稳定的分布式系统（第2版）笔记33_混沌工程

1. 康威定律

1.1. 梅尔文·康威

1.1.1. Melvin Conway

1.1.2. 1968年

1.1.3. 在设计系统时，组织受制于其自身的沟通结构，这使得它设计的系统结构与沟通结构相一致。

1.1.3.1. 社会学现象

1.2. 要在系统内部或系统之间构建接口，两个人必须以某种方式沟通有关该接口的规范

1.2.1. 没有沟通，就无法建立接口

1.3. 如果系统不是用稳定性模式构建的，那么它可能采用了典型的紧耦合架构

1.3.1. 发生失效的总体概率，是其中任何一个组件发生失效的概率之和

1.4. 应用程序的某些组件是针对QA环境的网络拓扑结构进行设计的，而这与生产环境不匹配

2. 负载测试

2.1. 并发用户是无法衡量的

2.2. 不存在长久的用户连接，只存在随着请求的到达而形成的一系列离散的访问

2.3. 对于不再点击的用户和尚未点击的用户，服务器无法区分

2.3.1. 会在用户最后一次点击之后的几分钟内，保持活动状态

2.3.1.1. 意味着会话的持续时间绝对比用户的持续时间要长

2.3.2. 如果对会话进行计数，那么就会高估用户的数量

2.4. 服务器会使用超时

3. 会话

3.1. 会话是每台应用程序服务器的致命弱点

3.2. 每个会话都会消耗资源，主要是消耗内存

3.3. 启用会话复制功能后（该网站确实启用了），每个会话都会被序列化，并在每个页面请求后传输到会话备份服务器上

3.4. 意味着会话消耗了内存、CPU和网络带宽

4. 测试

4.1. 所有的测试脚本都是遵守规则的

4.2. 按照应用程序的使用方式对其进行了测试

4.3. 应用程序开发人员没有采取某种能够阻止恶劣情况蔓延的防护措施

5. 混沌工程

5.1. 混沌工程源于悖论，稳定的系统会变得脆弱

5.2. 混沌并不总是涉及软件中的故障，有时也出现在组织成员身上

5.2.1. 组织中的每一个人都是普通人，难免会犯错

5.2.2. 高可靠性组织也使用演习和模拟的方法，在人的方面寻找相同的系统性弱点

5.3. 基本的做法

5.3.1. 规划一段时间

5.3.2. 把一些人指定为在此期间“无行为能力”

5.3.3. 看业务是否可以继续照常开展

5.3.4. 僵尸来袭模拟

5.3.4.1. 能立即发现一些关键的过程在人们离开后无法完成

5.3.4.2. 也许存在一个需要特定角色的系统，而这个角色只有一个人来担任，或者另一个人掌握着关于如何配置虚拟交换机的关键信息

5.3.4.3. 当知道在无人参与的情况下，公司能让业务正常运作一整天时，可以创造一个有20%的“僵尸”存在的异常情况，增加系统的压力

5.4. 在分布式系统上进行实验的学科，旨在建立系统能够应对生产环境中的动荡状态的信心

5.5. 用来应对分布式系统，而且通常是应对大规模的系统

5.6. 由于规模问题，我们既无法在非生产环境中模拟上述问题，也不能通过单独测试组件来获得信心

5.7. 强调要从整个系统的视角看问题，它需要应对在单个组件中无法观察到的那些新冒出的属性

5.8. 系统

5.8.1. 由人员、技术和过程所组成的整个集合，而不仅仅是信息系统

5.9. 通过优化系统获得可用性，还要获得对来自恶劣和动荡的世界的干扰的容忍性，而不是在理想化的环境中追寻高吞吐量

5.10. “大众微型面包车”悖论

5.10.1. 你能学会修复经常坏的东西，但无法学会如何修复那些很少坏的东西

5.10.2. 意味着当很少坏的东西坏掉时，情况就会更加可怕

5.11. 在使组件更稳健与使整个系统更稳健这两者之间

5.11.1. Netflix公司并不是做“二选一”，而是选择了“全都要”

5.11.1.1. 运用稳定性模式，让单个实例更容易存活下来

5.11.1.2. 让这些失效发生得更频繁，使它们变成一种常态

5.11.1.2.1. 对很痛苦的事，要更频繁地做。

5.12. 集群服务应该不受实例失效的影响

5.13. 关掉实例是最基本和最直接的混沌注入，绝对能发现系统中的弱点

6. 调节器

6.1. 调节器的任务是消除变化，但这种变化正是系统工作质量信息的最终来源

6.2. 调节器做得越好，能够获得的有关如何改进系统的信息就越少

6.2.1. 在IT人员休假之前，你不知道对他们有多依赖

7. 爆炸半径

7.1. 指不良体验的严重程度，这涉及受影响的顾客数量及顾客体验被破坏的程度