破坏性&故障演练

目录

一、演练的背景

二、破坏性演练

三、演练的目的

四、演练怎么做

1、各种故障包括：

2、业务的响应包括：

3、举例说明

4、演练方式

5、演练的范围

---

一、演练的背景

         1、后台架构变得越来越错综复杂，即便排除自己所在的业务的故障，第三方服务的服务降级，故障，流量猛增等都可能随时危及到自己的服务，进而发生连带的故障。

        2、故障修复后，需要验证其是否完全修复，并且是否可能在其他地方发生。

       3、判断业务依赖是否合理，有无预案，告警是否合理(更多预案故事，请移步：浅谈预案)。

故障发生的具体例子：

依赖的第三方低优先级服务挂了，导致本服务高优先级的也挂了；

磁盘满、CPU猛增时是否有合理告警、业务影响如何；

集群中某一台集群挂了的影响；

缓存失败对DB影响；

下游超时、异常、限流对本服务的影响；

二、破坏性演练

当系统处于高压力情况下(如全链路压测场景下)，人为地创造一些问题，让系统处于不正常状态，如网络抖动、请求超时、线程block、CPU高等问题

三、演练的目的

让团队成员能够有问题时对问题心中有数，快速定位问题，解决问题；

100%验证已修复的问题是否真正修复了；

当前服务间的强弱依赖/服务架构/预案是否满足业务需要；

四、演练怎么做

方案：通过模拟注入各种故障(如：服务超时，fullGC,磁盘满等)，来观察业务的响应是否满足预期

1、各种故障包括：

1）服务方面故障：

• 接口不可用 ，接口失败
• 线程池满

2）中间件方面故障：

缓存方面——缓存被击穿；消息方面——消息阻塞，消息丢失

3）机器方面故障：

• 某机器load过高
• 某台机器CPU过高/一台机器CPU满载
• 某台机器fullGC
• 某机房全部挂掉

4）网络方面故障：

网络断掉

2、业务的响应包括：

1）故障中时，业务处理是否复核预期(如：处理缓慢)；

2）故障中时，预案是否正常开启(如：服务降级处理，自动重试，告警，消息自动重试，磁盘满时文件自动删除，CPU高时自动下线机器)

3）故障消失后，业务是否正常恢复，预案是否正常关闭等

3、举例说明

1）故障演练过程中，比较好的业务处理现象：

自动开启紧急预案，业务可缓慢处理；

核心监控正常告警；

技术人员快速发现、定位、解决问题；

当前不能解决问题，待故障恢复后，可手动/重试方案解决，不实际影响业务/用户；

服务/接口降级，不阻塞核心功能/大盘流量；

异步消息重试中；

2）故障恢复后，比较好的业务处理现象：

自动关闭紧急预案

业务处理恢复正常；

各告警关闭；

技术人员/业务人员快速处理完遗留问题；

4、演练方式

预期演练：有事先准备的演练，例如，故障注入方、故障业务方均已知故障的时间、范围、时长等，并做了上下游业务的周知；

突袭演练：无事先准备的演练，例如，故障的时间，范围都不知，故障注入方在不周知的情况下做演练，来评估业务方的响应情况

5、演练的范围

单接口；

单个应用；

级联多个应用；

单个业务；

全链路业务