应用层追求更全面、更便利、更快捷的服务，逆向推动技术层面系统越来越庞大，持续维护系统的难度与日俱增，故障的发生不可避免，如何保障业务持续的高可用性和稳定性成为了大家面临的挑战！
在稳定性保障能力建设方面，互联网公司的思考及实践已较为深入，从混沌工程到可观测性、从全链路压测到应用多活。相对而言大部分国内传统企业还处于大型机到分布式、云原生化改造的阶段，对稳定性保障能力建设的路径、障碍并不清晰，对稳定性保障技术价值仍不明。
针对可靠性测试的挑战，混沌工程在一定程度上给出了解法，但如何运用平台的工具进行可靠性测试实践？ 为此PerfMa混沌工程产品负责人叶青山先生，将从可靠性问题分析、可靠性测试方案、寻找可靠性分母、构建可靠性用例、可靠性用例执行等维度，全方位给大家演示如何推进企业系统稳定性能力建设。
可靠性问题分析
随着IT和互联网行业的快速发展，软件系统的复杂度逐步增加，分布式技术架构成为主流。微服务，数据库，缓存，对象存储，消息等各种分布式组件构建成复杂的分布式系统。大型的分布式系统会有成千上万的节点，这些节点在长期运行的时候，会不可避免的出现匿机、断网、磁盘损坏等各种故障。
分布式组件一般都面向故障进行相关的可靠性设计，通过主备、集群、镜像、哨兵等多种方式保障系组件的分布式可靠性，那么在实际部署运行环境，如何确保这些设计依然是有效的就会是一个具备一定挑战性的测试工作。
故障根因分类
目前主流的分布式系统的可靠性分析一般从设施层，数据层，操作系统&语言层，中间件层，服务层进行分层分析。
可靠性测试方案
可靠性测试方案三大步骤：
- 对业务系统进行可靠性风险分析，构建风险场景库
- 根据风险场景，构造可靠性用例
- 基于混沌工程进行可靠性用例执行
可靠性测试目标：提升SLA
可靠性测试分母
下图是一种风险场景分类，一般来说，每个中间件都会有对应的一类风险场景。
而且我们中间件在做风险分析的时候，会取决于它的一些部署架构，你的一些主从部署跟集群部署，或者你采用哨兵模式，他解析出来整个风险场景是都会有他自己的一些具体的风险项。所以我们这边也是大致做了一些分类，就是不同的中间件有自己的一些风险库
风险项模型
- 定义状态指标，状态指标是可以定衡量的一个系统都可以衡量的一个东西，最好是一个量化的。
- 正常运行状态，作为稳态的描述，我们定义了一个资源，指标是什么，范围区间是什么？那包括这个稳态如果被破坏以后，它可能产生什么样的风险和故障。
- 我们如何去保障稳态，它应该在什么范围内，用什么技术手段去保障它的运行
- 就是，我定义的一些稳态，一些技术上我的验证手段是什么 ，我怎么去这验证的更多是一些破坏性能，就是我如何破坏这个稳态，那混沌工程是一种手段，刚才我们说的一些压测或者人为破坏也好，手段不限，只要你把它能破坏掉就可以。
- 发现能力，风险巡检包括这个度量能力息息相关的。
- 应急能力，应急里面可能是定义了一些你的自愈能力的要求。
风险项巡检流程
一个风险项巡检的例子
假设支付结果页对广告投放是个弱依赖，那么在对下游广告投放服务进行故障注入后，整体的业务成功率没有变化，耗时增长。整个演练流程如下：
仿真环境需要具备：
- 和线上环境部署架构一致的业务系统
- 规则完善的监控系统
- 具备应急能力的运维平台
- 具备故障注入能力的混沌工程平台
具体执行步骤：
混沌工程介绍
混沌工程平台能力
- 混沌工程平台底层故障注入能力丰富
- 平台具备专家场景，便于测试团队人员快速落地。
- 可应用在可靠性测试，应急验证，攻防演练等多种场景。
可靠性测试未来展望
随着混沌工程理念在国内的发展，逐渐有测试团队进行引入和应用，但是整体还是偏工具使用，缺乏体系化和完善的方法论。目前来看，未来可以从以下一些方面进行发展。
相关可靠性测试体系的建立
基于混沌工程的可靠性测试，从用例设计，用例执行，故障注入，测试分析等方面看，目前还没有一个行业通用的标准和规范。随着行业的发展，相信相关的标准和规范也会产出。
可靠性测试平台的建设
对比功能测试，性能测试，行业内已经有很多成熟的工具平台提供。目前混沌工程的工具平台也比较多了，但是基于混沌工程的可靠性测试工具平台市场上还没有，相信在不久的将来，随着基于混沌工程的可靠性测试越来越多的落地实践，相关的工具平台必然会产出。
前端可靠性测试
移动互联网时代早已到来，但是目前主流的混沌工程还是偏服务端应用，从完整的技术链路来看，在前端进行可靠性测试也是一个发展方向。
