Question

分布式系统在高可用、弹性化，方面存在的弱点。哪些可以称之为系统弱点呢，比如

• 外部系统故障，导致内部系统连锁故障，如云服务故障导致的内部故障
• 服务不可用时，不合适的降级方案
• 不合适的超时机制，导致请求错误时无限次重试

混沌工程的定义：

通过观察分布式系统在受控的故障注入测试中的行为变化发掘系统弱点，并针对性的改进，从而提高系统可靠性，建立系统抵御失控条件的能力的信心。所以，混沌工程并不是一个新概念，常见的异地容灾测试也是混沌工程的一种应用。

混沌工程的一般实施步骤

1. 寻找一些系统正常运行状态下的可度量指标，作为基准的“稳定状态”

2. 假设实验组和对照组都能继续保持这个“稳定状态”

3. 对实验组进行事件注入，如服务器崩溃、硬盘故障、网络连接断开等等

4. 比较实验组和对照组“稳定状态”的差异

如果混沌工程实施下来两者的“稳定状态”一致，则可以认为系统应对这种故障是弹性的，从而对系统建立更多信心。相反的，如果两者的稳定状态不一致，那我们就找到了一个系统弱点，从而可以修复它，提高系统可靠性。

混沌工程的理想原则：

1）根据“稳定状态下系统的特征”做一个假设

以电商下单为例，下单系统可能包含了商品服务，交易服务，支付服务，“假设”不是着眼于各个“螺丝钉”服务的具体状态，而是着眼于整个下单系统正常运作下的外部状态，如下单量、成交金额、系统吞吐量、延时、错误率等等，这些指标一般会有大盘监控，而且除非遇到促销活动，这些指标曲线一般不会大起大落，其变化趋势是可以预期的。但是有一点需要特别注意，某些问题虽然不会怎么影响大盘数据（如缓存失效、一个CDN节点失效等等），但是我们仍旧需要监控系统中各个节点的微观指标（如CPU、IO等）以期发现这类问题（缓存失效可能导致Mysql集群压力增大，CPU/IO等压力变大）。

2）事件是现实世界真的可能发生的

任何可能影响系统稳定状态的都可以作为事件，常见的，如

• 故障类：像服务器宕机、断网等硬件故障，像七牛等外部服务不可用的软件故障
• 非故障事件：像流量激增

我们还可以分析曾经引起系统故障的事件的种类和频次，针对性的排列优先级，并实施这些事件，避免系统再次出现这种故障。

3）在生产环境跑

一般只有生产环境的指标是可预测的，如新用户日注册量，用户日下单量。而且，由于测试环境和生产环境不可能一模一样，为了真实反映系统的可靠性，一般推荐在生产环境实施混沌工程。

4）持续集成

互联网软件每天都在更新，所以像跑持续集成一样实施混沌工程具有现实意义。

5）最小化影响范围

根据第3条，混沌工程可能导致线上功能不可用，甚至造成资损，所以在以找出系统弱点为目的的前提下，需要最小化故障影响范围，并且当出现严重问题时可以迅速恢复，即故障是可控的。鉴于此，有时候可以引入A/B测试，最小化影响范围。

上面是最理想情况下的混沌工程，现实中我们需要根据现有软件成熟度有阶段的实施混沌。

在初步阶段，故障的注入主要是人为控制，目前已实现的故障类型有：

• CPU高负载
• 磁盘高负载：频繁读写磁盘
• 磁盘空间不足
• 优雅的下线应用：使用应用的stop脚本平滑的停止应用
• 通过kill进程直接停止应用，可能造成数据不一致
• 网络恶化：随机改变一些包数据，使数据内容不正确
• 网络延迟：将包延迟一个特定范围的时间
• 网络丢包：构造一个tcp不会完全失败的丢包率
• 网络黑洞：忽略来自某个ip的包
• 外部服务不可达：将外部服务的域名指向本地环回地址或将访问外部服务的端口的OUTPUT数据包丢弃