共计 5620 个字符，预计需要花费 15 分钟才能阅读完成。
一分钟精髓速览
越来越多企业正在通过故障注入和演练的形式晋升系统可靠性，这其中金融行业的利用较为非凡。一方面其可靠性要求比非涉账类零碎更高；另一方面金融行业有更加严格的监管要求，如客户、账目等信息都有严格束缚。加之金融零碎较其余行业零碎更加宏大、繁冗，所以金融行业落地混沌工程和故障演练等工作需尤为审慎、谨严。
本文介绍了中国人寿故障演练的我的项目背景、指标思路、技术计划等，分享其在预知故障和升高不确定性危险方面的实际功效。
作者介绍
中国人寿研发核心高级工程师——刘玢
TakinTalks 社区专家团成员。领有多年开发和运维教训，专一高可用畛域，目前负责中国人寿混沌工程等多项高可用动作的布局和落地施行，对于构建高可用零碎具备深刻的了解和实践经验。
舒适揭示：本文约 4600 字，预计破费 9 分钟浏览。
后盾回复“交换”进入读者交换群；回复“0426”获取课件材料；
背景
在最近六七年工夫里，中国人寿对原来烟囱式的架构做了继续革新。对诸如长险、短险、万能险等等独立零碎中的相似性能，做了横向的专业化拆分、微服务拆分。新架构在带来效率晋升的同时，也带来了更多不确定性危险，如微服务数量的指数级增长、架构越来越简单、问题定位难度加大等等。
从 2022 年安全事件及生产危险起因剖析看，中国人寿安全事件及生产危险次要包含非版本类变更引发、第三方或硬件故障、版本或历史缺点、生产长事务或者海量数据引发等，其中非版本类变更引发、第三方或硬件故障两项总和超过 50%。
一方面，微服务增多导致版本翻倍增长，带来了更多的变更危险；另一方面，“1min-10min-30min”的故障解决要求也是不小的挑战。总体上，因为不足抓手导致咱们对性能、平安、兼容性、可维护性等多方面都不足品质信念。
基于此，中国人寿高可用工程规划了一系列稳保能力，并于 2022 年开始落地基于混沌工程的故障演练。囿于金融行业生产环境的特殊性，目前中国人寿已率先实现了在故障演练在测试环境和准生产环境的落地。
明天我将次要围绕中国人寿故障演练的我的项目背景、指标思路、技术计划等，分享其在预知故障和升高不确定性危险方面的实际功效。
一、故障演练想要达成哪些指标？
1.1 故障演练指标
故障演练的指标次要分为两块，业务指标和技术指标。
通过基于混沌工程平台的故障演练能力建设和演练施行，从开发、测试、运维、灾备各个领域帮忙各零碎发现和解决潜在问题，进步零碎稳定性和可用性，加强团队合作能力和故障排除能力。
1.1.1 业务指标
事先（从架构设计角度）：加强业务可用性，预防事变产生；
事中（从零碎运维角度）：进步故障发现能力和告警能力；
预先（从故障处理角度）：晋升应急处理时效，升高故障影响范畴和时长。
1.1.2 技术指标
开发畛域：去除架构设计单点，验证零碎容错能力；
测试畛域：生产故障回归测试，极限场景测试；
运维畛域：验证监控发现能力和告警有效性，验证应急预案有效性，缩短故障处理工夫；
灾备畛域：验证灾备切换预案的适用性和有效性。
1.2 落地思路
第一个是平安优先。先从测试环境演练动手，再缓缓过渡到生产环境，稳固平安优先。
第二个是分步施行。先做一些简略的场景，而后再做简单的场景，稳步推动。同时，先引入开源工具，再增强自主掌控，一直晋升故障演练零碎撑持能力。
第三个是增强协同。故障演练和做容量布局、灰度、在线压测等都有很大的不同，大多数时候业务团队会认为故障演练将毁坏其零碎程序而冲突不配合。因而，协同沟通以及混沌理念宣传十分重要。
二、技术计划如何抉择？
2.1 平台性能布局
技术选型是整个我的项目落地最重要的一块。咱们将性能布局分成了五局部，试验配置、试验治理、平安管控、监控整合、故障注入。后面两局部各家都大同小异，这里将重点分享前面三个性能布局背景。
1）平安管控
这部分布局咱们破费了最多的精力和工夫。在做混沌工程时，大家首先都会关注如何建设零碎稳态，如何管制爆炸半径等，而金融行业零碎的平安管控尤为重要，所以咱们花了大量工夫，与诸如阿里等一线公司做交换和调研，借鉴胜利的教训。具体实现过程我将在前面开展。
2）监控整合
咱们要把原有的监控能力做整合，来适应混沌平台的需要。中国人寿做过很多监控能力的建设，如机房监控、主机监控、网络监控、数据库监控、服务链路监控等等，原来的监控平台对这些监控能力都做了接入，但为了告警不便和避免误报，很多监控数据都做了抽样，比方按分钟做一个统计数据再整合起来。如果间接给混沌平台来应用，会导致时效性有余或者故障被覆盖。因而，咱们须要从新做监控能力的整合。
3）故障注入
故障注入能力可能是大多数人关注的重点。咱们布局的故障注入能力包含根底故障（如 CPU 资源、网络资源、磁盘、过程、内存）、JVM 类故障、网络申请类故障、消息中间件故障、K8S 引擎故障、Cattle 引擎故障等等。这部分咱们花了较长时间做收集整理。
此外，咱们还做了一些定制开发的故障。因为仅基于开源工具，很多场景故障无奈模仿。举个例子，中国人寿当初应用了大量的中间件，一个 Java 工程应用很多内部 jar 包，有些内部包又依赖其余包，整个生态十分宏大，而内部的故障工具只能对其中某些中央做故障注入，不能齐全满足理论的故障模拟需要。所以须要很多定制化的故障开发来补齐这部分能力。
2.2 技术选型过程
实现性能布局后，咱们从业界支流的混沌工程平台中筛选了一些产品进行深入研究和试验测评。从故障注入能力、平安管控能力、试验配置与编排、界面易用性、部署难度、服务反对、扩展性兼容性等 7 个方面，做了深刻的剖析和比照。
基于技术自主可控的思考，最终咱们抉择了“自研 + 开源”的形式。基于开源的 ChaosBlade，进一步做了定制化开发，包含自定义故障的开发、监控能力整合等，造成了现有的混沌工程平台。
三、如何分阶段落地故障演练？
整个故障演练工作能够分成三个阶段。目前曾经实现测试环境和准生产环境的故障演练，我将重点分享这两个阶段的落地实操。
3.1 故障演练 - 测试环境
3.3.1 整体工作功效
从 2022 年 7 月开始至今，总计实现 13 个零碎测试环境的故障演练，累计进行 30 轮演练，发现 143 个危险点并采取预防措施，整改问题超过 50 个。
3.3.2 演练过程
1）第一轮：线上分散式演练
第一轮演练是线上分散式的，持续时间一周以上。次要参加人员有混沌教练、产品架构师、测试人员。其中，产品团队须要提供架构文档（如物理架构、逻辑架构、技术栈状况等）、历史故障清单（如上下游关系比拟近的系统故障）、演练的重要关注点等。
在此过程中，咱们会依据零碎技术栈和零碎架构，先在故障演练库中选出适宜的根底故障，再依据理论沟通状况补充利用适宜的故障。接下来，基于开发环境对筛选进去的故障做预演练，其目标就是通过适合的形式生成故障——有些故障比较简单，通过故障工具能够间接生成，但须要找到适合的地位并做深度分析；还有一些故障须要定制开发，并做演练迭代。
整个过程依据零碎的复杂度，短则继续 1 周，长则 2 - 3 周。演练实现后，就能造成适宜该零碎的比拟残缺的故障清单。
2）第二轮：集中研究整改措施
以线下集中的模式发展，工夫是半天左右。将混沌教练、产品经理以及产品组架构师等等骨干全副招集，对第一轮确定的故障清单做集中演示。同时，现场探讨并确定整改动作。有些故障会波及多个角色，也有可能产品组不认可问题整改意见，此时则须要多轮探讨，最终约定具体的整改计划。
3）第三轮：应急预案有效性验证
此阶段退出运维部署负责人，还是以线下的模式进行，次要对应急预案的有效性进行验证，工夫也是半天左右。
此轮咱们会筛选一部分和运维严密相干的故障，对第二轮整改后的零碎进行可触发应急处理的故障演练。运维人员染指并依据应急预案施行一遍，看看是否能笼罩并及时处理故障。同时，也会在现场探讨应急预案的动作是否正当、是否须要减少、是否须要欠缺等等，并可能在现场做屡次迭代试验。
3.3.3 演练后果
对于金融零碎来说，真正敢上生产环境做演练的简直没有，所以咱们在测试环境的演练播种会绝对少很多。后面讲到咱们总计实现了 13 个零碎测试环境的故障演练，其演练后果和问题大抵可做如下分类。
从数据中能够看出，大部分问题集中在监控缺失和告警规定。只管监控平台曾经建设了好几年，然而从演练后果来看，监控告警能力并不如大家设想的乐观——存在监控盲区或者须要达到肯定阈值才会在监控中出现、告警规定不合理等等。这里也是咱们测试环境演练最有价值的播种之一。
（中国人寿某零碎演练问题清单）
3.2 故障演练 – 准生产环境
3.3.1 演练背景
客户流动管理系统是中国人寿的客户节流动平台，在流动顶峰时，刹时 TPS 可达到 8000 以上。为应答行将到来的客户节流动，咱们在此零碎上做了准生产环境的故障演练。之所以称之为准生产环境，是因为尽管它自身是生产环境，但在客户节降临前，它没有生产流量，所以咱们能够间接在生产环境做尺度更大的故障注入。
3.3.2 演练过程
演练需同时依赖在线压测平台和监控平台进行。因为是在生产环境演练，所以必须用在线压测的办法能力把生产流量打上去。另外更重要的一点是，尽管客户流动平台刚上线没有生产流量，然而其上下游零碎也会有生产危险，所以须要依附在线压测平台做流量辨别，将测试流量打入影子库中。同时，一些不能调用的接口也需依靠在线压测平台做 Mock。所以，先有在线压测平台后，再来建设混沌平台，工作推动会更加正当。
3.3.3 演练功效
1）依靠在线压测平台全面验证各个模块容量；个别状况下，容量验证依附性能测试。但性能测试有个比拟大的难点，即 A 模块产生性能瓶颈但上游的 B 模块还未达到瓶颈，此时须要性能测试不停做生产变更和配置调整能力达到最优。而通过混沌工程平台，简略对 CPU 或内存做肯定比例的占用、对网络延时做大量调整即可检测出链路上各个模块的性能极限。
2）对数据库高可用、PAAS 平台多活、利用限流熔断、监控和告警等进行了全面验证；
3）首次生产应急演预案有效性验证，利用弹性扩容、数据库扩容和重启等。
四、故障演练解决了哪些理论问题？
4.1 开发畛域
1）强弱依赖梳理
重保期间人力老本升高。开门红是每家保险公司都非常重视的流动。因为业务量微小，在这种流动重保期间，咱们以前的做法是所有关联系统的运维人员、产品经理都须要 24 小时值班做撑持，这样的老本投入是十分高的。而依靠故障演练的强弱依赖梳理，能够准确晓得哪些零碎更重要须要 24 小时保障，而其余不要害的零碎则能够适当升高响应要求。理解组件之间准确的依赖关系，可能更合理安排运维反对，更大程度上缩小人力老本。
2）高可用动作有效性验证
架构设计的落地状况验证。以前有很多架构设计，通过评审上线后落地好坏是很难评估的，比方在架构设计文档里承诺实现的点，实际上线后可能因为各种起因并未达到设计要求，混沌工程故障演练能有肯定测验成果。
单点故障容错验证。次要验证集群中一个单点产生故障后，业务是否还能持续。在实操中，业务压力较大时，其中一个节点故障，整个集群的可用性并不一定如设计的那样无效。比方，在一次对某零碎生产故障复现的故障演练中，当咱们对 Redis 做故障注入，发现当主节点刹时内存大量占用呈现故障时，从节点并未切换为主节点。所以单点故障的容错验证是有必要的。
限流、熔断阈值验证。如后面提到，有些设计看起来是没问题的，然而不通过验证，它真的不肯定是牢靠的。
PaaS、网格等多活验证。中国人寿有本人的 PaaS 平台，做了一套多云多活的高可用设计，包含一套信创云做补充。通过混沌平台咱们验证了 PaaS 平台和网格的多活策略的有效性。
中间件高可用验证。对 Redis、音讯队列等依赖比拟重的零碎特地须要这一块的试验。
4.2 测试畛域
1）生产故障回归测试
月度生产故障根因剖析反对。在生产环境出故障或者难以还原现场时，咱们会用混沌工程模仿现场。只管剖析进去的根因可能会不一样，但这对周边零碎的高可用晋升具备借鉴意义，即当生产产生此故障时，周边零碎的高可用伎俩应该如何发挥作用。
重大生产问题复盘反对。
2）极限场景模仿测试
性能测试无奈模仿的场景反对。有很多场景是无奈通过性能测试模仿进去的，比方发压的压力达不到、或者流量配比不迷信、或者两头一些环节的容量不够，无奈把足够的压力传导到指定模块上，此时能够通过混沌工具占用一部分的 CPU 或者内存，再去做极限场景的性能测试。
4.3 运维畛域
1）监控发现能力和告警有效性验证
监控发现能力补全和告警有效性验证。后面讲到进行了 30 轮演练后，咱们发现监控缺失和告警规定不合理占大部分。我置信这种状况应该在各家公司是普遍存在的。
2）应急预案有效性验证
促成应急预案的欠缺；
锤炼运维队伍，晋升故障处理时效。
五、将来瞻望
将来咱们心愿打造更便捷，更平安，更智能的故障演练服务。
更便捷：以后在做故障演练时，咱们的投入是很大的，根本是把混沌小组最厉害的工程师、混沌教练，还有各个产品团队的架构技术骨干都集中到一起能力把整个工作发展起来。难度高、专业性强导致了便捷性的有余。将来在更便捷方面，咱们想像应用自来水一样做故障演练。
更平安：以后咱们还没有真正上生产。一是因为大家信念有余，二是监控指标的有效性、完整性以及依靠监控指标疾速复原现场的能力也还有待提高。
更智能：咱们也在思考人工智能和混沌工程的联合，比如说不须要人工再做简单的架构和技术栈剖析、历史故障剖析，甚至实现主动的故障注入和施行等。（全文完）
Q&A
1、混沌教练须要具备什么样的素质?
2、混沌工程构建故障是用的哪些测试工具？测试环境和准生产环境应用的工具有哪些不同?
3、故障演练、在线压测如何分工与合作?
4、怎么做到月度生产故障和重大生产问题故障的混沌场景，镜像生产数据?
更多具体内容，欢送点击“浏览全文”，观看完整版解答！
申明：本文由公众号「TakinTalks 稳定性社区」联结社区专家独特原创撰写，如需转载，请后盾回复“转载”取得受权。
本文由博客一文多发平台 OpenWrite 公布！
