1. 高速前进的轮子才能保持平衡
1.1 C 端红利期已经过去
截至 2023 年 6 月，我国网民规模达 10.79 亿人，较 2022 年 12 月增长 1109 万人，互联网普及率达 76.4%。C 端人口红利期已过，上网时长也增长缓慢，各类存量场景下的应用增长空间已经不大。
在经历了 C 端的 easy 模式之后，很多公司适应不了 B 端的 hard 模式。C 端有足够的的人群，给我们打磨产品，足够多样的变现方式；但 B 端的用户根本不给我们实验的机会，上来就要求完美适用的产品，而软件产品为了控制边际成本，对非标品的支持与投入是非常有限的。拿着 C 端赚到的钱，投入到 B 端寻找新的增长点，这就是现在很多大厂正在做的事。
1.2 高楼已成，不再需要那么多工人
这是 2023 年有次出差和同事聊到的一个观点: 我们的平台已经建设成型，就像建好的一座高楼，需要的是少量物业人员，而不是大量的建筑工人。
我们的效能平台、业务服务，在从 0 到 1 开发时，会高价从外部挖专家、调动内部骨干积极建设；从 1 到 100 迭代时，会继续投入大量的机器资源、运维人力、高响应优先级；但从 100 到 110 呢？边际收益越来越低，即使投入大量的资源，也很难获得线性的收益。
平台已成，小修小补就能够满足需求。以前 2 个人维护一个产品，现在一个人维护 2 个产品。人员互备都不用了，给一挺机枪就想守住一片山头，根本没有敌人会来的预期。
1.3 增速放缓，稳定性问题凸显
在业务高速增长时，产品在不停迭代，线上有人盯着，能够及时发现、修复问题。但当业务增长放缓时，产品没有稳定的发版频率，相关人员责任心缺失，各种线上的小问题就会被忽略，而这些小问题的集中爆发就会导致真正的大事故。
反过来也是对的，一个大事故隐藏着很多小问题。一次不可用的事故，背后可能隐藏着很多的缺陷，比如，没有做好容灾、没有做好故障转移、没有做好限流、没有做好监控、没有做好告警等。如果每一点都能做好，没有短板，这个事故很有可能就不会发生。
2. 接下来将会面临真正的挑战
2023 年，我经历了很多次业务大小事故，包括上微博热搜的。
2.1 技术是否过硬
各不相同的 Golang 协程泄露事件。丢包，协程打爆；连不上数据库，协程打爆；CPU 不够了，协程打爆。
基础库老旧、版本多样，Golang 版本低，一个统一的应用框架也没有。
这些暴露出来的问题，在存量时代已经不容易解决。但线上问题不断，又不得不解决，考验我们技术功底的时候到了。
2.2 架构是否合理
各种服务调用错中复杂，缺少治理。人能够处理的复杂度是有限的，业务增长时，粗放式让业务自由选型，缺少统一的管理，服务调用关系没人能够梳理清楚。
各种跨集群调用、跨机房调用、内部调用走公网等乱象，几个服务互调把 QPS 量拉升几倍。
服务的就近调用，用户的就近访问，集群的单元化建设，这些以前被忽略的问题，现在都直接影响到了应用的稳定性。
2.3 稳定性是否可靠
增量没了，拿不到 90 分；想拿到 60 分及格躺平，却是要守住存量的稳定性。
事情往往就是这样，求乎上者得乎中，求乎中者得乎下。保持现状，就不是一件容易的事情。以前很多依靠人工处理的异常，现在人被裁了，处理的能力也就消失了。
但 SLA 还是要达标，这就需要我们去寻找新的方法，去保证稳定性。混沌工程实验就是一个很好的方法，通过主动制造可控的故障，来提升系统的稳定性。
3. 互联网应用具备混沌的特征
3.1 混沌学科的产生
在讲混沌之前，我们可以先思考一下混沌、混沌工程和我们线上服务之间的关联。
我们经常听到的故事是，一只在亚马逊河流中的蝴蝶，煽动了几下翅膀，就能在美国引起一场龙卷风。这个故事背后隐藏着一个重要的学科，那就混沌。
早在 20 世纪 60 年代，洛伦兹就发现了混沌现象。他是一个数学家，但是从事气象学研究，使用数学模型研究天气时发现，初始值的微小变化，会导致结果的巨大差异。对初值极其敏感，是判断为混沌状态的重要特征。之后，又经过十几年的发展和研究，才将初值敏感的特征命名为蝴蝶效应，被人们所熟知。
3.2 混沌工程的产生
而我们谈的混沌工程，实际上指的是来自 2008 年 Netflix 的工程实践。
在 Netflix 上云的过程中，他们发现了一个问题，上云之后，服务的稳定性会下降。原因在于，网络、机器、存储等，都是不可控的。
因此，他们开发了一个工具，叫做 Chaos Monkey，主动破坏云服务，来发现系统的弱点，从而提高系统的稳定性。目前，这是一个上万 star 的开源项目， https://github.com/Netflix/chaosmonkey 。
犹如一只进入了数据中心的猴子，他会随机破坏系统，你会发现系统的脆弱点，也会从故障中学习到处理经验。
3.3 微服务与混沌的关系
目前互联网应用以微服务为主，微服务的特点是，服务之间的依赖关系非常复杂。那么，微服务具不具备混沌的特征呢？
以下是我总结的异同点。
相同点:
- 复杂非线性连接
- 敏感依赖性，一个微服务的变化会影响关联的其他微服务，与混沌敏感依赖初始条件类似
- 可能产生巨大的累计误差，与蝴蝶效应类似
不同点:
- 不确定性，微服务 < 典型混沌系统
- 微服务强调独立性，而混沌系统强调互相依赖
计算机系统是确定性的系统，程序代码是提前编写好的，运行结果是有预期的。但现实中，计算机系统真的是确定的吗？不是的，磁盘损坏、内存位翻转、网络中断，程序运行的物理世界是不确定的。此外，微服务的资源并不是独占的，高密度的部署下，CPU、内存、网络等资源都是共享的，服务与服务之间也是相互影响的。这里将其统称为程序运行的环境因素。
从计算机系统 + 环境的角度看，我们的线上系统、微服务程序具备混沌的特征。
4. 进行混沌工程实验的必要性
4.1 提供新的 OKR 目标
没有列入 OKR ，就不是重要事项。我们想要稳住存量，不仅要熟知现有的系统问题，还要让现有的问题能通过 OKR 的方式，被看见，被认可。
上层有事项可列，下面有事情可干，这样才能够保证我们的工作有落地的路径。
4.2 护航 2.0 变革
存量不能只求 60 分，我们还是需要不断地尝试新的技术、新的架构。
在这个尝试的过程中，我们需要有一个保护机制，来确保我们的业务不受影响。混沌工程实验就是很好的破局方式，也是很好的验证方式。
对于存量架构，我们可以拿出混沌工程实验对其进行冲击，引导其进行演进，而不是一味地去维护。
4.3 应用所处的环境越来越复杂
我们所处的基础设施环境、软件架构越来越复杂，故障已经不可避免。
从经典的架构看，IaaS 层可能会有服务宕机、网络抖动；PaaS 层可能会有数据库宕机、负载不均、CPU 抢占；SaaS 层可能会遇到 OOM、CPU 限流、连不上数据库等故障。
应用及其运行环境复杂度已经远超个人能够全盘掌控的程度。我们与其等待故障，不如主动出击去制造故障。
4.4 复现故障的成本越来越高
“我怀疑是 CPU 不够”、“我怀疑是网络有问题”、 “我怀疑连不上数据库”、”我怀疑….“
当我们怀疑某个不确定性因素的时候，不用仅仅停留在猜想阶段，而是需要一次混沌工程实验。
一旦有了混沌实验的方法和工具作为支撑，我们就可以通过实验来验证我们的猜想，而不是盲目地去排查。
5. 混沌工程价值在哪里
5.1 沉淀故障处理的经验
事前有预案远比事后改进好很多。
常见的做法是，事故发生后，我们会进行事故复盘，总结出一些故障处理的经验，然后将其沉淀到故障处理手册中。但你可能会发现，下一次事故又是新的，之前的经验并不能完全套用。
这是因为事故处理的经验样本太少，系统太过复杂所致，而经常性的混沌实验，可以丰富故障处理的经验样本，让我们能够更好地应对未知的故障。
5.2 检验已有缺陷、发现未知缺陷
混沌工程能够揭露生产系统中未知的缺陷，提高系统的稳定性。
这里需要明确的一点是，如果已经确定混沌实验会出现问题，说明现有的系统并没有任何容错或者应对机制，那么这种实验也就没有任何意义。
如果基于认知边界进行划分，可以将缺陷分为两类:
- 已知缺陷，包括已经容忍的、已知但未修复的缺陷，比如单点、网络抖动等
- 未知缺陷，包括未知的、有认知偏差的缺陷，比如潜在的 Bug、自认为而与事实不符的缺陷等
对于认知边界内的缺陷，使用混沌实验，可以用于复现缺陷、辅助修复缺陷、检验缺陷得到修复。
对于认知边界外的缺陷，使用混沌实验，是探索性的。我们通过混沌实验，可以发现一些被忽略、被遗漏的缺陷。
5.3 提升应用的韧性
在研究各种混沌工程实践时，我还接触到一个有意思的概念，应用的韧性。
刚接触到这个概念时，总感觉很熟悉，但又很难说清楚。因此，我想了一个形象的比喻，如上图的不倒翁，应用可以左摇右摆，但是依然能保持平衡。这就要求，应用能够应对各种不稳定、不确定性、突发的状况时，能够自愈。经过短暂地波动之后，能够迅速地恢复平衡状态。
对应用不倒翁的定位，需要做以下的设计:
- 冗余设计
重要的中间件，两地三中心，允许其中至少一个断连
- 过载保护
当请求激增时，能够采用限流、拒绝服务等措施保护整体不受损
- 服务降级能力
在服务能力不够的情况下，能有有所取舍，保障重点服务不受影响
- 去中心化设计
不允许出现中心化的节点
这些具体的要求，对于我们的业务应用是有落地路径的。我们可以按照这个要求，去评估并改造我们的应用。
