【美文速记20190814】混沌工程提高系统可靠性
1.为什么需要混沌工程
建造一个系统，无论该系统的具体功能是什么，我们都需要保证系统的稳定性，但是如何知道系统是否处于稳定状态呢？通常，团队可以通过单元测试、集成测试和性能测试等手段进行验证。但是，无论这些测试写的多好，我们认为都远远不够，因为错误可以在任何时间发生，尤其是对分布式系统而言，此时就需要引入混沌工程（Chaos Engineering）。
2.什么是混沌工程
混沌工程也是一个工程学科，这就意味着需要做实验，通过设计进行混沌实验，观察系统对各类故障的真实反映，以此来完善保证系统的稳定性。
开始混沌工程之前，这一切的前提是确保系统是容错的。假设系统是典型的单点架构，只要单点损坏，整个系统就崩溃了，没法验证混沌工程的效果，因此系统必须能够支持容错，然后通过不断的故障引入来验证系统容错性。
混沌工程要表达的意思，系统中引入了一只猴子（Chaos Monkey），试想一只猴子在系统里面，平时是安安静静的，什么事情都不做，突然一天发疯开始在系统里到处捣乱，作为工程师，要干的一件事情就是逮住这只猴子，让它别捣乱。
3.混沌工程步骤
第一步，需要定义系统稳态，通常情况下，可以通过 metrics 或者客户端指标定义系统，比如 QPS、延迟等，只要这些指标没有太大波动，就可以认为系统是稳定的；
第二步，定义系统稳态后，我们分为实验组和对照组进行实验，假设无论对实验组做任何操作，整个系统都可以继续维持稳定状态；
第三步，引进现实生活中的变量，也就是模拟现实世界可能发生的错误故障，比如硬件故障，网络延迟隔离等到实验组中；
第四步，比较实验组和对照组前后稳定状态的差异，是否可以满足预期。如果前后保持一致，则可以认为系统对该故障的有容错能力；反之，如果两者的稳定状态不一致，那就找到了一个系统弱点，从而可以修复它，提高系统可靠性。
4.混沌工程实践原则
第一个原则是构建系统稳态的假设；
第二个原则是引入现实环境的变量事件；
第三个原则是在生产环境中运行实验，此处需要注意任何在生产环境进行的操作都是有风险的，因此需要提前与相关部门进行沟通，以免因为疏忽导致业务挂掉不可用；
第四个原则是持续自动化运行实验，如果全部通过手工方式实现，效率将非常低；
第五个原则是要控制好“爆炸半径”，在进行混沌实验时一定要注意受影响的范围，如果没有预估好，很容易导致所有的用户都没法使用，这是很严重的问题。
5.PingCAP 在 TiDB 实践混沌工程
针对 TiDB 进行混沌工程实践，重点关注两个大方向：一是发现错误；二是注入错误。
5.1发现错误
我们采用的是比较原始的三种方法分析系统状态：Metrics、Log 和 Tracing。
（1）基于Metrics 的历史，然后进行比较，就可以基本判断出数据是否正常。当然，我们也会通过机器学习的方式进行更精确的判断。如下工具为“监控告警工具prometheus（普罗米修斯）”，Metrics指标为QPS
（2）基于Log分析，采用了业界比较主流的开源方案，比如 FluentBit 或 Promtail，将这些数据导入 ES 或 LOKI 进行相关分析。
（3）基于Tracing分析，采用的是业界通用的主流方案 OpenTracing。建议只有当 Log 或者 Metrics 没办法解决问题时，才不得已使用 Tracing，因为开启 Tracing 会对整个系统的性能产生一定影响。
5.2注入错误
分布式系统主要关心两个问题：网络和文件系统的故障。因为是分布式的，所以一定绕不开网络问题；因为需要进行数据存储，因此要考虑文件系统。
（1） 网络进行错误注入，通常情况下有三种模型：
如上图所示，第一种是 Complete，两个节点之间的网络完全不通；第二种是 Simplex，A 能给 B 发送消息，但是 B 不能给 A 回复消息；第三种是 Partial，A 和 B 完全不通，但是 A 和 B 能够通过另一个节点也就是 C 进行互动。
（2）文件系统错误注入
在 TiDB 里面，我们也会经常将电源拔掉，手工触发断电、断网等情况，以考察系统是否可以维持稳定。
参考文档：
