共计 3294 个字符，预计需要花费 9 分钟才能阅读完成。
本篇文章整顿自腾讯互娱高级工程师吴召军在 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 倍以上，这就是做混沌工程最大的收益。
