混沌工程实践：Slack的灾难剧场演练提升容错能力

很不幸，一切都没有按计划进行。仅仅希望系统在极端情况下能够可靠地运行，并不是一个好策略。必须要期望系统会失效，设计时要时刻考虑失效场景，并不断验证设计，使得系统在发生失效时仍然有效。在银行业务领域，设计可观测性和审计追踪功能的能力与设计可定制化实验的能力一样重要。

针对那些认为计算机可以并且应该能长期持久运行的思维方式而设计的系统，要想用混沌工程进行改造是一项异常艰巨的任务。以上思维设计出的复杂系统更无法适应底层计算机极端不稳定的状态。这样的系统在最佳条件下可以表现良好，但一旦发生事故，服务会迅速降级，有时甚至会出现灾难性的后果。随着规模的扩大，以及对系统提出能完成更多、速度更快和性能更可靠的开发要求，混沌必将来临。此时系统已经出现疲于应付的状态，没有时间重写。

旧系统的混沌工程改造，要有不同的策略。在旧时代，使用备用计算机被视为资源浪费，更有可能假设单个计算机的使用寿命会很长。这个简单的假设时许多不具有容错性的系统的设计核心。当今新设计的系统很可能会假设单个计算机会频繁地切换运行与停机状态。实例替换是现代的系统采用的强大策略，具备容错能力，以及类似蓝绿部署的稳念运维模式。在有数据存储的系统中，实例替换为自动和频繁测试备份能否被还原提供了能力和动力。

在旧系统进行混沌实验，首先，让备用容量保持在线。当一台或几台计算机出现故障时，可以使用备用容量来满足因故障而无法处理的请求。一旦备用容量可用，可以考虑将出现故障的计算机从服务中移除。

灾难剧场挖掘了各种过去处理问题的权宜之计，重新找回对各种系统故障的恐惧，并承担各种系统故障的风险。在引入受控的故障时，首要目标是发现生产系统中的漏洞。我们要寻找有关可用性、正确性、可控性、可观测性、安全性方面的漏洞。

灾难剧场是一系列持续进行的演练。灾难剧场不是一个探索性的过程。当引入少量以前没有或很少经历过的故障时，规划是关键。将所有专家和感兴趣的人聚集在同一房间或同一视频会议中有助于缓解混乱，并把灾难剧场计划传播给更多人。

每次灾难剧场的演练都始于构思。更准确地说，是始于担忧。有了担忧，并能有一位或多位熟悉相关系统的专家的帮助，就可以请一位经验丰富的主持人来指导大家完成混沌工程演练的全过程。两位主持人结对进行演练，在同一个房间或同一个视频会议中为演练做准备。

1、选择要引入故障的服务器或服务，识别其故障模式，确定模拟该故障模式的策略。

2、调查在开发和生产环境中的服务器或服务，评估能在开发环境中模拟上述故障的信心度，并做记录。

3、确定系统稳态假说中能检测到故障的告警、仪表盘、日志和指标。如果无法确定，那么考虑仍然引入该故障，并反向进行上述检测。

4、识别应能缓解故障影响的冗余和自动补救机制，以及应对故障时要查阅的执行手册。

5、邀请所有相关人员参加此次活动，尤其是那些在活动期间值班待命的工程师，并宣布演练开始。

尽力使每次演练都能使整个公司最大限度地认识灾难剧场。让所有人明白，在灾难剧场中投入时间可以使系统更可靠，并使人们对开发环境满怀信心。

指定一个记录员，在聊天频道中做笔记，每条消息自动加上时间戳。如果在演练过程中发生任何令人不适的计划偏离，或让客户遭受意料之外的影响，那么就中止演练。在不超过事故响应阈值的情况下学到东西。

1、确信所有人都能接受录音，尽可能一开始就对视频会议录音。

2、回顾准备工作，并根据需要进行修改。

3、在频道中宣布开发环境的灾难剧场开演。

4、在开发环境引入故障，并记录其时刻。

5、搜集告警、并检查仪表盘、日志和指标，并记录其时刻。

6、视情况给自动补救机制一些时间来触发，并记录触发时刻。

7、在必要情况下，遵循执行手册以恢复开发环境中的服务，并记录其时刻及所需的偏离计划的行为。

8、决定是否继续在生产环境进行灾难剧场演练。如果不进行，则宣布演练结束。

9、在频道中宣布生产环境的灾难
剧场演练开始。

10、在生产环境引入故障，并记录其时刻。

11、搜集告警、并检查仪表盘、日志和指标，并记录其时刻。

12、视情况给自动补救机制一些时间来触发，并记录触发时刻。

13、在必要情况下，遵循执行手册以恢复生产环境中的服务，并记录其时刻及所需的偏离计划的行为。

14、在频道中宣布演练结束。

15、做汇报。

16、分发录音。

汇报:

何时检测出故障?何时恢复服务?

是否有用户注意到故障出现?我们怎么知道这一点?我们如何才能让用户注意不到故障发生?

哪些手工工作本应交由计算机来完成?

哪些是我们的盲区?

我们的仪表盘和文档在哪里出现了错误?

我们需要更频繁地操练哪些内容?

如果演练的故障意外发生了，值班工程师应如何处理?

灾难剧场是一个令人信服的激励因素，是组织在容错能力上的投资。