(12)稳定性全系列(放火&降级)

提前“放火”—注入一些弱化故障，看系统反应，方便针对性做措施

混沌工程(故障测试有一定重合度)：生成“新信息”实践，事件发生后产生行为（不像故障测试只关心结果），不断去调整系统，使系统更具弹性，更加可控。

一、降级预案：

1、自动：定好策略，降级工具（例如 https://github.com/didi/sds）理想占80%

2、手动：业务开关、系统开关、服务降级、切流等操作

    定期随机停掉一台交换机，看网络设施是否足够容错。

能使用线上环境：不能在线上或类线上环境放火，没有实际价值

完善监控与告警机制：基本指标和行为，报警系统来保障及时发现异常

可预估燃烧半径：对业务和系统影响控制在预期范围之内（如发单接口avg耗时涨幅不超过20%、发单量波动<2%），先“放小火”，逐渐加大马力

有对应的降级预案：在具体实施时，我们要对放火的内容进行归类和沉淀，每种放火我们要提前想好对应的降级预案是什么以及预案的触发条件。初步的降级预案是放火的前提条件，而放火最终也会促进降级预案的不断完善和进化，这是一个良性循环。

二、方案实施

1. 选择放火事件

    存储放火：包括Redis、MongoDB、ES、MySQL等错误量和耗时的放火。

    依赖服务放火：包括下游调用超时、抛异常等。

    消息放火：主要是针对MQ的放火，包括减少Consumer、增加Producer发送耗时等。

    服务器放火：主要包括CPU、内存等服务器资源放火。

    网络放火：主要包括网络带宽、网络节点的放火，例如前面提到的盲测。

如选择依赖服务放火，即线上通过经纬度反查城市ID服务耗时比平常翻一倍

2.开始放火

阿里开源防火工具ChaosBlade

右侧：业务系统集群，每个模块安装放火Agent接收和实施放火指令，并收集必要数据，放火Agent如何实施放火指令呢？答案就在ChaosBlade中，内部实际上是使用JVM agent的注入能力（参见：https://blog.csdn.net/manzhizhen/article/details/100178857）；

左侧：放火平台提供操作功能及数据大盘。从Dubbo注册中心取服务拓扑，为放火平台更通用，有dubbo-fire模块进行服务拓扑适配和转化等，还提供缓存功能

一旦达到终止放火条件（例如影响超过预先阈值），停止放火。

3.复盘

记录系统在放火过程中表现、对业务影响、预案效果等，讨论分析，是不是想要的？怎么做能让紧急事件对系统和业务指标影响更小？

把所有放火演练沉淀下来，和历史的线上事故一样，反复研究和学习

https://blog.csdn.net/manzhizhen/article/details/104673043