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