混沌工程 - 软件系统高可用、弹性化的必由之路

有赞技术团队 2018-06-22 19 阅读

随着摩尔定律的终结，单机计算性能已达到了极限，然而，我们的软件系统不论是规模还是复杂度一直在增长，所以软件系统都不约而同的朝着分布式化方向发展。近年来，随着云服务、容器的出现，某些分布式系统也更容易微服务化。抛开这些形形色色的分布式技术，我们对系统可靠性的述求却是一致的：分布式系统需要高可用，即使出现了单点或集群故障，也希望系统具备自我恢复或优雅降级的弹性能力、容错能力。我们在合理的架构，高质量的代码，完善的测试等等方面做了很多努力，然而很多分布式系统仍旧达不到高可用、弹性化，为了尽可能发掘系统中存在的弱点，很多大型软件公司都引入了混沌工程，如国外的谷歌、网飞，国内的京东等等。哪些可以称之为系统弱点呢，比如

外部系统故障，导致内部系统连锁故障，我司即出现过因为七牛服务故障导致的内部故障
服务不可用时，不合适的降级方案
不合适的超时机制，导致请求错误时无限次重试

混沌工程的定义：

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

混沌工程的一般实施步骤

寻找一些系统正常运行状态下的可度量指标，作为基准的“稳定状态”
假设实验组和对照组都能继续保持这个“稳定状态”
对实验组进行事件注入，如服务器崩溃、硬盘故障、网络连接断开等等
比较实验组和对照组“稳定状态”的差异，推翻上述第2条的假设

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

混沌工程的理想原则：

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

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

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

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

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

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

3）在生产环境跑

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

4）持续集成

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

5）最小化影响范围

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

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

阶段一：分布式系统弹性化一般

以京东为例，他们会在双十一大促之前进行故障演练，将团队分为两组，一组作为故障的制造者，另外一组作为故障的解决者和响应者，来考察故障发生的时候，团队对故障的检测、响应、处理还有恢复能力。达到小的故障不需要人介入，大故障人工介入可以快速处理的目的。通过在大促之前的两个月期间密集的开展混沌工程，提高团队对大规模故障的容错能力。
以有赞为例，由于我们才刚刚开始，为了控制风险，起初只会在测试环境实施混沌工程，所以暂时没有可以参考的准确大盘数据，即合适的基准“稳定状态”。但也不是不可能，观察大盘数据可以认为反映的是系统宏观指标，从微观角度来讲，我们可以筛选出一批直接影响核心大盘数据（如注册量、下单量等）的接口，在对系统实施混沌后执行这些接口的场景化集成测试，通过观察测试结果来评估系统的可靠性，从而寻找系统弱点，这在测试环境是可行的。
此外，混沌工程可以认为是通用型异常不定时不定目标不定异常类型的自动化实现，如果抛开这层，手动对目标机器注入特定的一种或多种异常，并辅以对应的异常恢复手段，那我们就可以在通用异常测试中应用。