Chaos Mesh® 在腾讯——腾讯互娱混沌工程实践

Posted 2021-06-08 TiDB_PingCAP

本篇文章整理自腾讯互娱高级工程师吴召军在 PingCAP Infra Meetup 上的演讲实录，欢迎点击【阅读原文】查看视频回放，后台回复 “135” 即可获取本期 PPT 链接。

本文首先介绍了腾讯互娱面临的复杂的技术场景，然后介绍了腾讯互娱混沌工程团队基于 Chaos Mesh 打造的云原生混沌工程平台，最后分享腾讯互娱近半年混沌工程实践取得的收益。

腾讯互娱运营活动每天的访问人次超过 100 亿次，高峰的 QPS 超过 100 万，每天活动代码发布更新超过 500 次，数据量也超过 200 TB。面对海量的用户请求和快捷的版本发布迭代速度，如何才能又快又稳地保障服务的运营？腾讯互娱活动运营团队给出的解决方案是 DevOps 和云原生。

以前活动的发布都是运维人员来操作，随着活动量快速增长，出现了明显的瓶颈。为了解决这个问题，腾讯互娱设计了一条从代码到生产环境的流水线。现在，活动开发只要把代码提交到仓库，触发代码提交，运营平台就会自动编译构建生成镜像，并且自动把镜像部署到腾讯云 TKE。从代码完成到生产环境发布完成只需 5 分钟，并且全程都是开发自助完成。

如今，腾讯互娱运营活动基本上所有的服务都是跑在腾讯云 TKE。受益于云原生的技术红利，服务的弹性伸缩，包括服务扩容、缩容的速度非常快，几分钟时间就可以从单副本扩展到一百个副本。

为了更加敏捷的迭代，开发团队会把一个大型的、难以维护的服务拆分为很多的小服务进行独立运营。小服务代码量少，逻辑较为简单，所以交接、学习的成本比较低。这种微服务的组织方式逐渐成为大势所趋，但是随着小服务越来越多，服务间的调用关系也越来越复杂。所以这带来一个新的问题：一个小服务的异常可能拖垮整条链路，带来连锁反应。

不同开发对容错能力的处理也不一样，有些服务的容错能力特别好，降级能力也比较完善，但是有些服务就不一定了。还有的告警不及时，故障定位的工具不完善，导致一些故障处理起来比较麻烦。

那如何解决这个问题呢？腾讯游戏混沌工程团队给出的答案是：把 PingCAP 开源的 Chaos Mesh 在腾讯云 TKE 落地，用以解决当前服务故障频率高、质量控制挑战大的问题。

混沌工程是 10 年前 Netflix 提出一个概念，Gartner 预计，到 2023 年，将有 40% 的组织把混沌工程实践作为 DevOps 的一部分，而这将使得故障停机时间减少 20%。

业内对混沌工程的定义是通过主动注入故障，以期提前发现潜在问题，迭代改进架构和运维方式，最终实现业务韧性。换个更熟悉的说法就是：故障演练。

几乎每一个技术团队都会去做故障演练，一个服务在上线之前，会测试主备切换是不是生效，容灾能力是不是能通过。比如说会把一个 Master 节点关机，看服务能不能自动的切换到 Slave 节点，这些其实就是早期的混沌工程。

混沌工程的雏形就是故障演练，但是故障演练并不等于混沌工程，混沌工程是在故障演练的基础上扩展出来的新技术，主要体现在出现了专业的混沌工程工具，如 PingCAP 开源的 Chaos Mesh 等产品，以及相关理论体系的建立。

一年前，腾讯互娱正式启动了混沌工程项目。如何在 K8S 场景下去做混沌工程？当时通过选型对比发现 Chaos Mesh 这个产品相对于其他的产品来说有非常多的优势，功能明显要比其他产品要多，代码是开源的，不需要额外开发做适配等。并且它本身也是 CNCF 的一个项目，在更新、迭代速度这一块具备较为明显的优势。

为了充分的发挥 Chaos Mesh 的优势，腾讯互娱混沌工程团队把它集成到现有的运营平台，在每个 TKE 集群都部署了 Chaos Mesh，通过Chaos Mesh提供的dashboard API 来创建、执行、销毁实验，同时基于当前运营平台的能力来观测实验效果，权限上也与现有的运营平台进行了对接。

从架构图上来看，Chaos Mesh 是腾讯互娱整个混沌工程体系的核心引擎，它提供了最基础的故障注入能力，包括 pod 、容器、网络、IO 等故障注入。在这个基础之上封装了包括红蓝对抗、故障演练、故障编排、故障观测等等一整套的混沌工程能力体系。

腾讯互娱混沌工程团队在使用 Chaos Mesh 的过程中，也跟社区进行了非常多的互动。吴召军提到，他们给 Chaos Mesh 社区提了非常多的使用反馈和需求，然后这些反馈的 bug 很快就会被修复，许多需求在下一个版本里面就会体现出来，这让他们的印象深刻。最开始用混沌工程的时候，Chaos Mesh 有一些文档不是很完善，使用时甚至需要连蒙带猜。但是到了现在这个版本，文档已经非常丰富、非常全面，这一块他们感觉到进步非常的大。

业界对混沌工程实践落地上，有一套较为完善的理论体系，吴召军总结了五个环节。首先是要有个方便好用的做实验的平台，这个平台能够去编排，下发实验、执行实验。然后就是在平台做实验计划需要能有效控制风险，实验执行过程中需要能实时观测到实验稳态指标，实验发现了问题需要有跟进优化，问题已经解决之后要及时提交验证和处理。形成一个完整的迭代闭环。腾讯互娱混沌工程团队也是基于这个理论来实施建设混沌实验平台。

这里就举一个在腾讯互娱团队内部的平台执行实验的例子，这里是实验编排环节，这里的编排同时支持并行的和串行的，可以在一次实验里把所有需要执行的故障全部都编排好，多个服务并行去执行混沌实验。

吴召军举了一个腾讯互娱经常做的一个实验：测试服务在 CPU 高负载下的表现。他们会先编排实验，然后下发执行，观测相关服务的表现。通过运营平台立马就可以看到服务的曲线：包括 QPS、延时、响应成功率等等这些业务指标。然后实验完成之后平台还可以输出实验报告，判断做这些实验之后是不是能够符合预期，并得出实验结论。

在腾讯互娱有业务方提出希望可以在版本更新后都要都跑一遍混沌工程的套餐。于是混沌工程团队就把 Chaos Mesh 集成在发布流水线里面，在用户编排发布的时候就可以把混沌演练这个环节插入进去，这样每一次发布都可以直接看得到混沌实验的执行效果。

有时需要针对某一个账号做混沌演练，要有效的控制爆炸半径，只能影响这个账号。腾讯互娱的做法是在网关层劫持流量，并在网关层下发实验。可以针对一个特定的账号下发延迟故障，观测这个账号的表现，实验可以做到精细化控制。

另外，混沌工程团队发现即使提供了便捷的混沌实验平台，让开发同学自己左右手互搏也是很枯燥的，很难持久执行。为了将混沌工程落地，腾讯互娱设计了红蓝对抗的玩法，运维同学会经常性的选择某些服务发起混沌实验，检验开发同学的服务是否具备容错能力，并把演练结果公示出来。开发同学为了避免出现服务漏洞被广而告之，会非常积极的去提前做混沌实验，提前解决掉隐患，形成比较好的良性循环。

在微服务的场景下，服务间的依赖关系梳理非常关键，非核心服务不能拖垮主服务，混沌工程可以非常方便检验强弱依赖关系，给被调服务注入故障，观察主调服务的指标表现，可以直观便捷地获得依赖强弱关系。主动给被调的服务去注入故障，延时超过三秒或者五秒，观察主调服务的 QPS 或延迟抖动。主调服务抖动，说明它们之间的依赖是比较强的依赖，可以根据场景、具体情况做一些优化。

同时，腾讯互娱现在还在使用混沌工程训练故障诊断机器人。当服务变复杂之后，故障的概率会变得更大。腾讯互娱现在想做的是，通过混沌工程的方式在现网或者在特定环境做大规模演练，从而训练出一个故障诊断的模型来帮助定位故障。

腾讯互娱这边落地云原生混沌工程有半年左右，事实上混沌工程已经在腾讯互娱内部几乎所有的团队都推开了。现在腾讯互娱平均每周混沌演练的次数超过了 150 次，提前发现问题数超过 100 个，每周发起演练总人数超过 50 人。

一般来说，故障演练需要手写脚本，比如做一个网络丢包 5% 的故障演练，熟悉的人可能很快把这个脚本写出来，如果不熟悉的话，可能要花很多时间去调试。混沌工程的优势就体现在：只需要把这些故障在平台上做简单的拖拉拽的编排，不需要要编写、调试脚本，就能下发实验并实时观测实验效果。 故障演练这件事情的成本降低了，效率大大提高。

从腾讯互娱的统计数据来看，通过混沌工程与传统的故障演练进行对比，混沌工程的效率至少提升了 10 倍以上，这就是做混沌工程最大的收益。