摘取自 腾讯区块链测试团队的混沌工程实践
［初衷］：做虚拟化方面的混沌工程实践有段时间了，也想看下其它产品混沌工程如何展开的。
一个产品(业务链)为什么要进行混沌工程演练
区块链是一种由多方共同维护，使用密码学保证传输和访问安全，能够实现数据一致存储、难以篡改、防止抵赖的记账技术，也称为分布式账本技术。
按照接入范围，区块链可分为公有链、联盟链和私有链。
目前国内最普遍使用的是联合行业或组织内成员搭建合作、共赢的联盟链。区块链服务建立在分布式系统之上，可能遇到的故障非常多，不仅仅是节点故障、各种网络故障、文件系统故障，甚至内核错误都时有发生。如果区块链服务不能很好地处理这些异常，那么服务的稳定性将遭到挑战，其后果也不堪设想。出于此考虑，腾讯金融科技区块链测试团队建立了适用于区块链领域的混沌工程实施框架。
［汇总一句话］区域链服务是建立在分布式系统之上，服务的稳定性可能存在不可预知的问题，需要混沌工程来解决。
混沌工程稳态假设：业务指标(如何判断区块链服务是否正常？)
区块链往往是个基于EDA架构的自运转系统，无请求时，也会有空块产出，而联盟链通常采用的是BFT类共识算法，该类算法支持3F+1容错，所以判断区块链的对外服务是否正常不能单一依据节点进程是否运行来给出，这里给出几个体现区块链服务是否正常的健康度指标，也就是混沌工程里提到的稳态指标。
1）节点数据一致性
区块链中的数据是经过共识节点交叉验证后存储上链的，所以正常预期是分布式的节点数据满足最终一致性，这些数据包括区块数据、交易数据、业务数据等。所以需要提供数据一致性校验工具。
2）并发场景下区块链服务的QPS/TPS
在稳定并发场景下，区块链对外服务的QPS、TPS应该保持稳定，如果注入一些网络延迟、或者CPU高负载等异常，会导致QPS/TPS波动起伏，不再稳定。
3）并发场景下区块链服务的响应时间(RT)
同样地，在稳定并发场景下，区块链对外服务的响应时间应该保持稳定，波动不大，注入异常后，会引起RT的波动，也会破坏系统稳态。
4）区块链在一段时间内的round切换频率
共识节点出现异常，导致发起的提案失败，会引发round值的切换，触发下一个节点发起共识，所以一个区块内round值越大，说明系统出现问题的概率越大。
5）区块链在一段时间内不同节点的高度差
区块链是一个自转系统，在无请求时，高度也会追加，正常情况下，不同节点在共识+同步的双重影响下，高度不会差距太大，如果出现不同节点高度差有变大的趋势，也预示着系统的稳态遭到破坏。
［收益的点］不同产品定义各自的业务指标，不同深度的指标，表示该产品对业务服务的精细化(SLA)，也表示该产品对其稳定性的决心。数据有多份，是检查多份间数据的一致性还是检查容错忍受范围内的数据一致性，拜占庭机制下只要大于一半以上的均是可以对外提供服务的。业务服务是并发场景下QPS/TPS，还是单场景下的，一个产品支持1亿万用户在线，只要少于1亿用户都是问题。一个产品客户端页面响应时间在2-5秒，只要影响这个响应时长的都是问题。拿虚拟化产品来说，业务是以支持1千用户创建虚机成功的指标为标准还是任意用户创建虚机的本次操作成功为标准。前者可能是某个时间段内，比如5分钟内1千用户创建虚机成功的指标，后者偏向于一次虚机创建是否成功。
混沌工程稳态假设(可观测性指标)
可观测性，在系统中是非常重要的一环。通常来说可观测性主要包含 Metrics（指标），Logging（日志）和 Tracing（追踪）。三者的关系如下图所示：
［自己一点经验］这三点都有，对于混沌工程的推进和问题定位收敛，起到事半功倍的作用，进行过混沌工程演练的人一定深有体会。
基于工作流的混沌工程实施框架
整个实施框架分为以下几部分：
BlockChain：被测区块链网络区域，搭建好的区块链网络分为共识域和同步域，每个区块链节点上都会部署相应的ChaosAgent。
Load/Test Script：压测脚本，用来对被测的区块链网络施加稳定的基准流量，这些流量用例包括合约执行、交易上链、交易查询等。
ChaosServer：负责接收指令请求，向具体的节点施加具体的异常场景，包括CPU、磁盘、网络、进程等。
Tools：配套工具集，包括部署、日志收集、数据分析等。
Scheduler：混沌场景调度器，将某个时间点向某个节点施加某个异常，以工作流的形式放入任务队列中，然后调度器按时取任务，然后向ChaosServer发送命令请求。
我们借助PipeLine搭建了区块链的DevOps研发流水线。流水线将开发自测、构建、覆盖率、质量红线、异常测试、混沌实验、自动化测试、报告收集等流程打通。
通过对区块链实施混沌实验，并将故障注入、实验分析、可观测性告警等流程自动化后，带来的收益也较为显著：
1）自动化实施混沌实验，可减少手工构造异常场景的时间成功。
2）模拟的故障场景丰富，可涵盖接近真实生产的异常条件。
3）结合系统可观测性的实现，可以实现分钟级问题发现和告警能力，并且累计发现Bug数十个，回归混沌场景数百次。
［感受］不同的评价纬度，也是其对混沌工程的看法。混沌工程的好坏不能以故障注入的时长为标准，某种意义上的还行。混沌演练工具也有发展阶段，如果在初期，也存在不稳定的情况，有可能还没有手工注入的时间短。
网友评论