──混沌工程的落地不仅仅是工具办法的落地也是一种文化和设计的落地
本文旨在通过根本介绍和分享声网的局部教训，帮忙大家理解混沌工程，进步业务服务可靠性。
00 前言
“什么是混沌工程？听起来很牛的样子。”
“混沌工程与咱们故障演练有什么区别？”
“是不是咱们通过了混沌测试就不会出问题？”
“这个场景咱们不太会遇到，因为客户没有这么操作的。”
下面的话是在咱们推动混沌工程的工作时，大家会说到的几个广泛问题。所以在探讨混沌工程 (Chaos Engineering) 之前，咱们须要晓得什么是“混沌工程”，要解决什么样的问题，如何保障服务的稳定性。
近些年来，咱们软件系统的规模及复杂度始终一直的增长，传统的大单体模式曾经无奈适应当初的迭代及部署，所以当初的软件系统更加偏向于倒退分布式的零碎。分布式系统解决了咱们单体架构期间迭代速度慢、技术债高、部署麻烦等问题，但同时也带来了新的挑战。依据 Google 2021 的 Devops 调研报告[1]，咱们能够看到越来越多的团队进行了上云的实际，而且也愈发重视软件交付经营的体验（software delivery and operational performance）。如何在分布式系统的疾速迭代下，保障系统的稳固高可用，曾经是近年来的热点与难点。
如上图，咱们能够看到一个典型的微服务零碎，一个具备服务边界、松耦合的服务构造。传统的测试方法的确能够在肯定水平上确保服务间的可用性。例如契约测试能够尽早发现更多的问题，在频繁迭代的零碎下保障服务间的可用性，但这实质上也是 服务调用方与提供方的一致性校验，只是在业务逻辑上做了更好的测试保障。对于微服务零碎的个性，例如高可用、服务依赖、分布式一致性等还是不足笼罩。现有的测试伎俩很难去辨认服务间的强弱依赖，也很难去验证高可用策略的齐备性，而混沌工程的呈现，给了咱们解决问题的思路以及办法。
01 概述
那什么是混沌工程呢？
混沌工程是在分布式系统上进行试验的学科，目标是建设对系统抵挡生产环境中失控条件的能力以及信念。混沌工程不是一项测试，有着明确的输入输出、是一个实践性的学科，用来察看零碎的薄弱点以进行改良。
咱们为什么须要混沌工程呢？
在事实世界中，故障无处不在。咱们在外部也对一部分应用服务进行了回顾与统计，发现后果与混沌工程实验室《2021 年中国混沌工程调查报告》[5]类似，这里援用混沌工程实验室的后果：
从中能够看到，变更类故障是引发重大事故的次要起因，线上机器也永远不会是 Stable 的状态。依据海恩法令，咱们能够得悉：每起严重事故背地，必然有 29 起轻微事变、300 起得逞征兆和 1000 个隐患。正当使用混沌工程可能很好的弱化以上问题，下图即为声网落地实际的后果。
混沌工程与咱们故障演练有什么区别？
故障演练能够看做混沌工程的一种具体实际。故障演练是通过向指标零碎注入实在可能产生的故障来观测零碎的稳定性，但注入的场景绝对是固定、已知的。混沌工程除了在其根底上提供了一些理论指导以外，还是一个发现新问题的实际过程，例如对某个区域进行服务重启等。
02 如何施行
在开始进行混沌工程之前，咱们要先确定咱们的零碎曾经有了一些高可用的个性，能够在局部异样的状况下持续失常工作。咱们能够依据混沌工程准则 [2] 中的根本实际准则进行如下试验：
1. 首先，用零碎在失常行为下的一些可测量的输入来定义“稳固状态”。
2. 其次，假如这个稳固状态在控制组和实验组都会持续保持稳定状态。
3. 而后，在实验组中引入反映真实世界事件的变量，如服务器解体、硬盘故障、网络连接断开等。
4. 最初，通过控制组和实验组之间的状态差别来反驳稳固状态的假说。
如果混沌工程施行下来发现两者状态统一，则根本认为是能够通过此故障的；如果状态不一，那咱们就找到了一个薄弱点，能够针对性地进步零碎的稳定性。
这其中蕴含两个关键点：
1. 如何产生故障
2. 如何观测故障
在混沌工程实际的相干文章中，议论最多的可能就是如何产生故障，市面上比拟风行的有 ChaosBlade[3]、Chaos Mesh[4] 等工具，工具的抉择是和理论业务状况密不可分的。依据 Google 的调研[1]，当初抉择混沌云计划进行部署的公司也越来越多，上述的繁多工具也肯定无奈满足所有的需要，所以如何满足本身业务需要可能会是局部团队比拟头痛的问题。就声网的教训来说，自研是不可避免的，从易用性上来说也须要提供一个平台去提供全能力的反对。做比空想更重要，先实现并验证场景，而后在业务中进行试验，后续再进行优化可能是更好的一条路。
很多文章比拟少提及的点就是 如何观测理论故障的产生，这反而是我认为最为重要的一个点。现如今，各公司根本都会有监控报警平台，但还是有很多状况在咱们的监控报警未响应时被用户所发现，即监控零碎未报警但用户先报障了。这才是咱们进行混沌工程最大的阻力——不能无效地发现问题。去解决此问题，在声网的实际过程中，咱们总结了几个可供参考的点：
1. 补足所有根底资源监控，并在试验过程察看所有根底资源是否会受影响。咱们已经就遇到过内核异样导致 slab memory 泄露的状况，这个问题就须要根底资源的监控来进行发现。
2. 欠缺业务 SLI(Service Level Indicator)指标。依据本身业务的特点以及客户关怀的点定义 SLI 指标来进行观测，例如 Netflix 就采纳 SPS（播放按钮的点击率）进行观测。指标的要求不肯定是恒定，能够有着某种变动的法则，但 指标肯定要容易测量以及统计周期短。测量的难度越高，阐明描述业务状态的伎俩越少，须要进行思考及改良；统计周期越长，越有可能会略掉两头问题的点。
03 演进及评估规范
上一章节次要介绍了混沌工程的一些办法以及思路，那咱们做了当前如何去评估，如何继续后退呢。从成熟度来看，咱们认为落地大略会分为几个阶段：
1. 单体试验阶段：本阶段次要是在单节点上进行故障的场景开发、验证以及在单节点的故障试验。
2. 故障施行工具化：本阶段会针对业务进行故障施行的开发以及在业务上进行试验，并初步进行自动化、工具化及集成进 CI/CD。
3. 故障施行平台化：本阶段会进行主动的故障演练，范畴也逐步从测试环境到生产环境，并且易用性大幅晋升。
4. 混沌价值产出：本阶段能够提供混沌工程的价值，如供客户去应用、进步客户本身服务的稳定性；应用、利用 AIOps 等伎俩进行一些异样的预警、监测，向着 0 故障不断前进。
下面讲了那么多，咱们最终还是要为缩小线上故障服务。如果不分明做的状况，无奈进行继续的改良，那就无奈真正的闭环，最终不孚众望，无奈真正落地。混沌工程可能帮忙咱们缩小可用性问题，发现业务隐患，但咱们很难用发现隐患的数量来掂量咱们的工作，这充斥不确定性。那么咱们联合本身状况定义了本人的评估规范：
评估伎俩
• 用户场景
混沌工程的最终受益者是稳固牢靠的用户体验。那在混沌工程成熟度不高的前提下（还未有信念在生产环境进行实际），在测试环境或者预公布环境中可能模仿线上场景的水平越高，咱们也越有信念保障上线的可用性。另一方面，用户应用场景是能够被感知的，咱们能够通过笼罩更多的用户应用场景，更好的发现问题，加强业务信念。所以咱们通过对测试场景占线上用户应用场景的比例来评估覆盖度，越高越好。
• 混沌场景
一指标的抉择是较为通用的，对于混沌工程，咱们肯定会设计比照试验，如何设计是有章法可循的。所以混沌工程的场景能够通过业界的通用故障，业务个性隐患以及业务历史故障来整体预估。咱们反对的场景越多，业务也越有信念。
• 服务指标
服务指标的起源能够是 SLO(Service Level Object)、SLI，在 Agora 咱们也选用 XLA（eXperience Level Agreement）。混沌工程须要与业务独特建设业务的指标，这一指标也是线上运维 & 混沌工程须要观测的指标。指标越欠缺，咱们在对业务进行测试时，也有了更加好评判的规范，也更有信念。
04 总结
从声网的建设初始就有了对可用性的投入，到当初曾经成为了外部的规范与体系（见下图）。
混沌工程不是万能药，是要联合公司的理论来进行设计和落地，对于可用性的投入也不仅仅是测试或者运维团队，更应该是从流程上、从设计上都进行思考，所以混沌工程的落地不仅仅是工具办法的落地，也是一种文化、设计的落地。
05 援用
[1] Accelerate State of DevOps 2021
https://services.google.com/fh/files/misc/state-of-devops-2021.pdf
[2] PRINCIPLES OF CHAOS ENGINEERING
https://principlesofchaos.org/
[3] ChaosBlade
https://github.com/chaosblade-io/chaosblade
[4] Chaos Mesh
https://github.com/chaos-mesh/chaos-mesh
[5] 混沌工程实验室: 中国混沌工程调查报告(2021 年)
http://www.caict.ac.cn/kxyj/qwfb/ztbg/202111/P020211115608682270800.pdf
Dev for Dev 专栏介绍
Dev for Dev（Developer for Developer）是声网 Agora 与 RTC 开发者社区独特发动的开发者互动翻新实际流动。透过工程师视角的技术分享、交换碰撞、我的项目共建等多种形式，汇聚开发者的力量，开掘和传递最具价值的技术内容和我的项目，全面开释技术的创造力。