背景

最近在做提升私有部署稳定性的事，做了服务性能压测、磁盘压测等工作，但依然不太敢相信服务的稳定性，主要是因为私有部署时，服务除了问题要进行 debug 实在是太难了，所以不论为稳定性付出多少努力都是有道理的。

要提升服务的稳定性，需要从两个维度下手：

• 服务本身的质量
• 基础设施的稳定性

前者，一般通过 手工测试、单元测试、接口测试、e2e测试、压测 四种方式保证，其中，手工测试是最常用的；单元测试需要推动业务方去做，比较难搞；接口测试也需要推动业务方去做，比较难搞； e2e 测试仍然需要推动业务方去搞；压测在私有部署中也需要，但整体来看需求不大(一般私有部署的用户量不大，性能不会成为问题)……

目前，我们有手工测试和基本的接口测试。

后者，可以通过 性能压测、稳定性测试、破坏性测试 等方式进行，其中，性能测试 是最常用的，俗称 压测，压测可以针对中间件，例如 数据库、缓存中间件、消息队列等等，也可以针对基础设施的，比如 负载、磁盘、网络。 稳定性测试 是指对业务系统进行整体性的不定负载、长时间运行，为了测试业务系统在长时间运行过程中是否有内存泄漏等其他问题。 破坏性测试 是指模拟对系统进行故障注入，测试系统在一定故障场景下能否继续提供服务，并最终自行恢复的能力。

本期，我们仅探讨破坏性测试的一种通用方案 – 混沌测试。

关于混沌测试

产生的背景： 服务(环境)越来越复杂，很难通过人工去判断会出现哪些问题、不会出现哪些问题，因此，服务的设计开始出现 面向失败的设计 (design for failure) 的理念。实践中，一般通过一系列故障注入工具工具，对运行中的服务进行故障注入，通过验证系统是否能持续提供服务来判断服务的稳定性。整体测试和验证的方案，我们称之为 混沌测试。

混沌测试的内容，可以参考 chaos-mesh

混沌测试的核心，是 ① 破坏性故障注入 ② 检查故障影响范围 ③ 检查是否能自行恢复

实践

在调研中，发现两款流行的混沌测试方案：

1. 由 Netflix 开源的 chaos-monkey
2. 由 TiDB 开源的 chaos-mesh

两款工具在能力上相差不大，但 chaos-monkey 需要和 spinnaker 结合，而 chaos-monkey 有开箱即用的控制面板，为了快速实验，选择 chaos-monkey 作为混沌测试的工具。

整体的搭建过程，可以参考 chao-mesh 官网

集群搭建可以参考 记一次k3s环境搭建记录 或者 网络受限环境k3s安装记录

测试

• todo

---

Wrinkles should merely indicate where smiles have been.
— Mark Twain