β

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

有赞技术团队 12 阅读
混沌工程 - 软件系统高可用、弹性化的必由之路

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

混沌工程的定义:

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

混沌工程的一般实施步骤

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

混沌工程的理想原则:

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

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

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

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

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

3)在生产环境跑

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

4)持续集成

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

5)最小化影响范围

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

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

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

阶段二:分布式系统弹性化成熟

有赞混沌工程的实现:

由于混沌工程主要是注入特定的事件并引起系统故障,既然是“干坏事”的,所以我们将其命名成了“威震天”(变形金刚中的反派Boss)。由于我们还处于第一阶段,所以故障的注入主要是人为控制,目前已实现的故障类型有:

参考文献
PRINCIPLES OF CHAOS ENGINEERING

我的其他博客
异步系统的两种测试方法

我的开源项目 —— 方便产品、开发、测试三方协同自测的管理工具
捉虫记

ps:
有赞测试组在持续招人中,大量岗位空缺,只要你来,就能帮你点亮全栈开发技能树,有意向换工作的同学可以发简历到 sunjun【@】youzan.com

作者:有赞技术团队
Thoughts, stories and ideas.

发表评论