混沌工程实践指南-进程假死

前些年，某银行核心系统服务中断4小时20分钟，事件经过是这样的：当日上午11时，某全国性股份制银行数据库故障导致核心系统服务中断，全国范围内所有业务无法办理，至15点20分业务恢复正常，影响业务时间4小时20分钟。
停机事件发生后，银行立即联系数据库厂商赶赴现场服务，厂商技术工程师大约在1小时内到达现场，分析是所采用的数据库出现逻辑错误，产生“长事务”，之后数据库开始回滚，造成数据库进程挂起不能正常运行。之后寻找数据库恢复点，经历3个多小时，在15:20分数据库重启回复正常。
因为此事该行得到以下两个方面的经验教训：
1）行政处罚。对分管行长及科技部总经理实施行内纪律处分和降级。
2）暂停了该行业务准入，时间超过半年。
通常 大多数系统失效 表现为，没彻底崩溃，那些进程一直在执行，但什么也做不了，这是因为可用于处理事务的线程被阻塞，等待着一些不可能得到的结果。
导致进程假死的常见因素有:
1） 应用本身程序的问题， 比如死锁，java进程不断fullgc,进程夯住，都可能导致进程假死
2） 数据库负载太高，已经超出服务的极限。 或者逻辑错误，造成进程挂起服务中断
实验场景：
验证当进程实例hang时，此交易的容错能力，系统应具备防止因故障导致整体失效风险能力，具备保持业务的连续性能力。

步骤描述：
1、按照混合模型的比例，以被测系统最大处理能力的80%的负载压力，发起背景压力，待系统稳定运行5分钟后。
2、模拟部分进程实例挂起。模拟进程状态为终止状态

故障注入过程：
1、blade create process stop –process pid –timeout 30(设置进程挂起30秒)
2、故障注入期间；查看TCP状态，发现大量异常状态；tcp连接处于close_wait状态

3 、 故障消除后，处理能力重新恢复正常 blade destroy id,TCP连接恢复正常

4、系统交易逐渐恢复
![]

故障注入手段:
模拟进程假死 kill -19 pid ,或者采用混沌工程工具chaosblade ，注入命令为 ：blade create process stop –process pid

故障表现（重点对业务交易的影响）：
1、故障注入期间交易失败率100%。
2、故障影响时长与故障注入时长一致
3、对整体交易吞吐量有明显影响。
4、故障节点无自动隔离
5、故障解除后恢复时长快速恢复，恢复程度95%

故障影响评估：
1、影响范围主要为渠道类系统
2、故障严重等级中
3、故障发生概率评估；比较易出现

针对性优化建议：
1）无论资源是否可用，所有可能引起线程阻塞的资源池都必须有一个超时时间，以确保调用线程最终会解除阻塞。
2）一旦调用多次失效，调用方重试次数超过阈值时要及时断路。
3）故障节点要能自动隔离。

附录
进程崩溃和主机崩溃的差别
TCP 异常断开连接时，比如断电（主机崩溃）和进程假死 如果客户端主机崩溃了，服务端是 无法感知到的 ，在加上服务端没有开启 TCP keepalive，又没有数据交互的情况下， 服务端的 TCP 连接将会一直处于 ESTABLISHED 连接状态*，直到服务端重启进程。 在没有使用 TCP 保活机制，且双方不传输数据的情况下，一方的 TCP 连接处在 ESTABLISHED 状态时，并不代表另一方的 TCP 连接还一定是正常的。
使用 kill -9 来模拟进程崩溃的情况，发现在 kill 掉进程后，服务端会发送 FIN 报文，与客户端进行四次挥手。 所以，即使没有开启 TCP keepalive，且双方也没有数据交互的情况下，如果其中一方的进程发生了崩溃，这个过程操作系统是可以感知的到的，于是就会发送 FIN 报文给对方，然后与对方进行 TCP 四次挥手告别。