本文整顿自美团技术沙龙第 75 期的主题分享《美团数据库攻防演练建设实际》，系超大规模数据库集群保稳系列的第 2 篇文章。本文首先介绍了美团以后数据库运维现状、遇到的问题，以及为什么要建设数据库攻防演练平台；其次，分享以后数据库攻防演练平台的具体实际；第三局部会介绍数据库攻防演练在美团外部的落地状况；最初，会联合混沌工程的成熟度规范和成熟度等级，分享咱们对将来工作的一些布局。
01 背景
1.1 初识混沌工程
首先咱们先理解一下什么是混沌工程？简略而言，混沌工程是在零碎上进行试验的技术手段，目标是建设对系统抵挡生产环境中失控条件的能力以及信念。这次要体现在两个方面，从零碎角度来讲，混沌工程能够晋升咱们架构的容错能力和韧性，升高故障发生率和复发率，晋升零碎用户在应用时的体验；从人员角度来讲，通过混沌工程咱们能够加深对架构的了解，在解决故障时能进步整体的应急效率，并且能被动去探索零碎中潜在的一些问题。
混沌工程最早能够追溯到 2008 年，过后奈飞公司（Netflix）因数据库故障造成了一次微小的损失，于是他们便围绕着稳定性体系做出了一些摸索和建设。直到 2015 年，混沌工程的理念才被奈飞正式的提出。2019 年，阿里云推出了开源工具 Chaos Blade；2020 年，PingCAP 开源了 Chaos Mesh，这也标记着国内在混沌工程畛域也有了成熟的产品。
1.2 现状
上面是以后美团数据库运维的一些现状，这里从五个维度开展：首先集群规模（包含集群的大小和数量）的线性增长；第二，集群访问量的继续减少，当然这也是美团业务增长的必然结果；第三，线上遇到的故障品种也越来越多；第四，单位工夫故障的影响也越来越大；第五，一些小概率事件的产生也随着集群规模的扩充成为了可能。
1.3 痛点 & 作用
基于以上的问题，咱们整体上对于数据库集群的稳定性要求也越来越高。所以，围绕着稳定性建设，数据库团队在故障的预防、发现、剖析、复原以及预先复盘 5 个方面做了很多工作。其中在故障预防方面，咱们会通过故障演练摸索不同故障场景对咱们业务的影响，晋升故障产生时业务零碎整体的容错能力。晚期的时候，咱们通过人工的形式来做故障演练，但人工演练在以下四个方面存在很大的问题：
- 在演练场景方面，人工演练能演练的场景比拟少，演练场景的复杂度也比拟高；
- 在演练覆盖率方面，人工演练无奈笼罩大多数的集群，也就无奈保障常态化的故障演练；
- 在演练规模方面，人工演练没有方法进行大规模演练，在遇到一些机房或者交换机级的故障时，切换能力无奈失去无效验证；
- 在影响范畴方面，人工演练在整个演练过程中不能很好地管制爆炸半径，遇到问题不能疾速止损。
基于人工演练的这些痛点问题，咱们设计并建设了数据库故障演练平台，这个平台的作用次要体现在以下四个方面：第一，验证故障产生时组件的防守能力；第二，通过数据库大规模容灾演练，验证数据库集群的容灾能力；第三，能够验证故障产生时相干预案（业务、DBA）的有效性；第四，能够预知故障对业务造成的各种影响。
02 建设实际
2.1 体系架构
以后，数据库故障演练平台体系架构次要包含如下六个模块：
- 权限治理 ，管制演练发起人，能够对哪些集群发动故障演练；
- 演练评估 ，演练之前为了防止演练危险，会对集群做一些查看，比方集群的高可用是否开启，拓扑是否符合要求，演练工夫是否处在集群拜访的高峰期等；
- 故障注入 ，在相干的查看通过后，真正去执行故障的下发；
- 指标观测 ，在整个演练期间会通过采集一些能够反映稳态的数据，比方以业务的拜访成功率、业务的响应提早等等，来剖析故障演练对业务造成的影响；
- 终止注入 ，在演练过程中发现整体影响比拟大，或者有一些非可控的影响，能够立即终止故障演练，防止故障演练对线上业务造成的影响进一步扩充；
- 智能剖析 ，在演练完结之后，能够通过采集一些反馈故障注入或者是防守组件的相干数据断定本次故障演练是否合乎预期。
以后故障注入反对的主机类型比拟全面，能够在物理机、虚拟机、容器上做故障演练。
2.2 能力全景
这部分次要介绍一下咱们故障演练平台的能力全景，它次要布局了咱们以后数据库故障演练平台的一些外围能力，整体的细节如下图所示：
- 从反对的数据库来看，以后咱们次要反对 MySQL 的故障演练；
- 反对的数据库组件有数据库拜访中间件、数据传输、高可用零碎和 Binlog Server，咱们会在后续的迭代中逐渐反对，以后咱们正在接入数据库拜访中间件的一些演练场景；
- 在整个故障演练过程中，咱们会依赖高可用、容灾管控、故障诊断、故障兜底以及拓扑自愈等多个方面的能力，次要是验证下面提到的这些组件在整个演练过程中的体现是否合乎预期；
- 以后，平台本身曾经造成了从故障编排、故障注入、指标观测、故障终止、剖析复盘的一个闭环。
2.3 故障注入能力
对于故障注入能力，以后反对的故障场景次要包含 5 个（如下图所示），目前咱们次要建设的是宕机类（包含主库宕机、从库宕机）、主从提早以及从库沉闷连贯多，因为当火线上 80% 的故障都是由这几个场景引起的，这也是咱们目前没有建设过多故障场景的次要起因。前面咱们还会布局建设高可用的链路故障，比方数据库和高可用同时出问题时，高可用的体现是怎么样的，是否可能顺利的进行切换。
在故障编排方面，咱们通过建设一个工作内的子工作间的串行故障和并行故障的编排机制，来实现演练工作的对立编排。
在并发能力上，以后故障演练平台激进的并发故障注入能力是在一分钟实现 5000+ 节点的故障注入，目前这个能力曾经能够满足咱们对于大规模故障演练的整体需要。
2.4 演练流程
整个演练流程次要分成三局部，演练前、演练中和演练后，同时咱们也造成了危险评估、危险复核、一键终止、故障复盘的能力闭环。
在演练前，咱们次要做三个方面的工作：
- 针对演练集群做危险评估，比方演练集群的高可用是否开启、拓扑是否符合要求；
- 利用多级审批机制，让业务和相干的 DBA 通晓整个演练的危险；
- 在演练前创立相干交换群，把故障演练相干的信息在群里进行周知。
在演练中，有两方面的工作：
- 在故障注入前，做一下前置查看，次要目标是在建设演练工作后和故障注入前这个时间段，避免因集群拓扑变动产生危险，比方演练的场景是从库宕机，这种状况下如果产生切换，故障注入的节点很有可能变成了主库；
- 如果一个工作里含有多个子工作，而某一个子工作产生了故障注入失败，那么后续演练咱们会主动终止。
在演练完结后，咱们会进行故障清理，实现后做演练的数据收集，用于复盘，并据此欠缺相干的危险管控流程。
2.5 爆炸半径管制
提到混沌工程，就不得不提到爆炸半径管制的问题，以后咱们次要从两个维度、三个方面做了一些管制。
第一个维度是物理隔离，它蕴含两方面：
- 场景维度隔离，即在同一时间点、单个数据库的集群只能注入繁多类型的故障，次要是为了防止在单个演练工作中如果针对一个数据库集群注入多种故障，整体影响不容易被评估。
- 机器维度隔离，单个集群故障注入只能选定一个特定机器，而不能抉择多个机器。
第二个维度是流量管制，次要是通过中间件按权重下发少部分流量到演练节点实现，流量管制能从一个更精密的维度来管制演练的危险。
另外，咱们在演练前、演练中和演练后都有相干的查看或措施，可能保障在演练期间呈现问题后迅速把影响降到最低，这也是另外一种变相的爆炸半径管制。实质上来说，爆炸半径和通过演练发现的问题数量会有一个反比的关系，即爆炸半径管制得越小，整个故障演练对业务的影响也就越小。但与此同时，整个故障演练裸露进去的问题，就会比拟无限，所以在建设过程中要做一个取舍。如果想发现更多的问题，那爆炸半径就要设计的大一些。以后，综合考量多种因素，咱们还是把爆炸半径管制在一个绝对正当范畴去进行故障演练，让业务以一个更低的老本进行故障演练。
2.6 演练复盘
当演练完结后，咱们须要对整体的演练后果做主观的评估剖析，进而判断这次演练整体是否达到预期。演练复盘内容包含演练整体流程、存在的问题以及针对问题造成的相干改良点，它能够用来领导后续的演练。如果本次演练不合乎预期，咱们会通过演练复盘性能买通故障演练平台和故障复盘两大产品，主动生成演练相干的工夫线，从而更好地进行人工复盘。
演练复盘次要是分为四局部：
- 第一局部是演练复盘的概览信息，它次要是蕴含六个方面：① 演练时长；② 本次演练波及的集群数；③ 演练场景数；④ 演练成功率，即故障注入的成功率；⑤ 演练过程中产生的告警数；⑥ 演练期间业务申请的成功率。
- 第二局部是关键步骤，这里收集了在整个演练过程中十分要害、十分外围的步骤，以及它整体的指标数据，这些能够帮忙咱们剖析平台自身亦或是防守组件的相干体现是否合乎预期。
- 第三局部是在演练过程中波及的外围防守组件的指标数据，比方针对主库宕机，咱们次要关怀两方面数据：一是故障注入后，高可用组件用了多长时间才发现这个故障，二是在发现了这个故障后切换花了多长时间。通过这些数据，就能够晓得在本次演练过程中防守组件的体现是否合乎预期。
- 第四局部是演练详情，它是针对单个集群的演练过程绘制的残缺的工夫线信息，能够通过这些信息看到一个演练集群从前置查看到故障注入，到告警产生，到防守组件的染指，再到故障清理呈现出的一个十分具体的工夫线数据，如下图所示：
2.7 随机、无告诉演练
从 2022 年开始，咱们开始建设随机、无告诉演练能力。之前故障演练平台次要是在特定工夫、特定场景下的演练，并且在整个演练过程会组织相干的人员协同跟进整个演练过程。然而，故障的产生是一个十分随机的行为，它不会给人足够的工夫去筹备、应答。而随机无告诉演练性能，就是心愿建设这样的能力，能够在非特定工夫、非特定集群、非特定场景进行故障演练，在肯定水平上填补了故障演练的空白，也是故障演练平台向混沌工程演进的一个里程碑。整个演练过程次要分成三个局部：
第一局部是须要增加演练打算，其次要内容包含三个方面：
- 能够通过集群、场景、演练工夫这 3 个维度，去管制哪些集群能够演练哪些场景，在什么工夫能够进行随机无告诉演练；
- 按集群、场景维度组合去做相干危险查看，以此来保障增加的这些集群能够进行相干场景的演练；
- 和惯例故障演练类似的是，它也提供了多维审批，能够让相干业务人员或者 DBA 通晓个整个演练的危险。
第二局部是演练工作生成，有了演练打算后，咱们按演练打算随机搭配生成演练工作并进行周知，和惯例演练最大不同是咱们不会周知演练的具体工夫（会周知演练集群、场景），次要是为了模仿故障产生的随机性。随着前面整体能力的降级迭代，咱们会逐渐去掉在集群、场景维度的周知。
第三局部是演练工作执行，它齐全复用咱们惯例故障演练的性能，也能够在演练前勾销、演练中终止，演练后能够主动复原整个集群的拓扑。
2.8 演练模式比照
上面咱们将惯例故障演练、随机无告诉演练以及混沌工程作一下比照，如下表所示：
- 首先从演练目标维度来看：惯例故障演练目的性十分强，它次要是验证已知的问题场景是否会再次造成生产上的事变；随机演练次要是在已知的故障场景、在无限的集群范畴内，是否会产生问题；混沌工程的演练目的性最弱，它次要是测验未知的故障场景是否会造成问题。
- 从是否有人值守的维度来看：惯例故障演练须要有人值守；随机无告诉演练是朝着无人值守方向倒退的，但以后鉴于咱们的能力还在建设初期，所以也会减少一些相干的值守机制来管制演练危险；混沌工程是齐全无人值守的，因为也无奈去值守一个混沌工程的“混沌”试验。
- 从事先周知的维度来看：惯例故障演练须要明确进行周知；随机无告诉演练以后在无限集群和无限场景范畴内进行演练（会周知演练集群、演练场景），不会周知具体的演练工夫；混沌工程是齐全无周知的演练模式。
2.9 演练经营体系
上面是数据库故障演练平台的经营体系的建设，次要关注四个局部：
首先是演练外围指标：
- 一是在一段时间内，共进行了多少次演练，波及演练集群数有多少个；
- 二是在一段时间内演练集群和演练场景的覆盖率以及达标率；
- 三是故障演练完结后的反馈，即演练是否合乎预期。
第二局部是大规模演练的外围指标，咱们次要关注三个方面：
- 第一方面是每次大规模演练的演练规模；
- 第二方面是故障注入的成功率；
- 第三方面是故障注入的耗时散布，次要统计在某一个工夫点，实现了多少实例的故障注入。
第三局部是业务接入指标，一方面统计外围业务的接入状况，同时也会反映一下 DBA 在不同业务线的推广状况。
第四局部是平台能力指标，一方面是平台接口成功率，另一方面是平台接口的相干耗时。
03 落地状况
3.1 演练推广
本局部会介绍故障演练平台在美团外部的落地状况。首先在推广层面，咱们次要采纳三种模式：
- 第一种模式是故障驱动形式，如果线上产生了特定的故障场景，导致业务损失，咱们就会进行相干故障场景的容忍能力建设以及验证。
- 第二种模式是被动演练，通过定期学习一些故障案例，判断相干的故障案例中的相干故障场景是否会对目前负责的业务产生影响，也能够通过故障演练平台做简略的摸底。
- 第三种模式是 DBA 被动策动组织，比方 2022 年，咱们进行了三次规模比拟大的演练，次要验证在特定故障场景下，业务的容错能力、高可用的防守能力是否合乎预期。
3.2 试验环境
在混沌试验的环境抉择上，咱们目前提供了三种不同的环境：
- 第一种是线下环境，次要是用来发现问题后进行相干预案的建设和验证；
- 第二种是线上演练环境，次要是通过大规模的容灾演练，去验证防守组件的防守能力是否合乎预期；
- 第三种是线上实在环境，就是咱们真正的线上业务集群，次要通过具体业务进行相干故障场景的演练，可能更加实在、全面地验证故障的影响，以及相干预案的有效性。
3.3 演练规模
接下来是演练规模，演练的规模越大，影响的范畴越大。咱们的演练规模能够划分成三类：
- 第一类是单集群演练，次要验证故障影响及预案有效性；
- 第二类是中小规模演练，次要通过规模化的演练，去验证特定故障场景对业务的影响；
- 第三类是大规模的集群演练，次要验证容灾能力，以及相干防守组件的防守能力是否合乎预期。
3.4 场景 & 等级
在整体推动方面，咱们目前会从两个维度进行演练：
- 第一个维度，咱们会依据故障影响的重大水平，做无损到有损场景的演练；
- 第二个维度，演练会从低等级集群开始，最终过渡到高等级集群，这样做的目标是先给业务建设一个对于故障演练的信念，之后逐渐在高等级集群中施展故障演练的重要作用。
3.5 演练经营数据
上面是惯例故障演练、随机无告诉演练以及大规模故障演练的一些相干数据：
- 从惯例故障演练的数据能够看出，以后咱们整体上的惯例故障演练覆盖率是偏低的。
- 随机性能演练是 2022 年第四季度才建设实现的能力，到目前还是高级推广阶段，所以整体上演练次数比拟少，2023 年的次要指标是通过在外围业务线的推广，一直进步演练集群的覆盖率，以期发现更多的问题。
- 大规模演练从 2022 年下半年开始，在演练频次有十分大的进步，这次要是为了更好地验证数据库底层依赖的防守能力在面临大规模故障时的体现。如果发现相干组件存在问题，咱们也能够更好地辅助这些组件去做迭代，辅助建设相干的能力。上图统计的是单任务演练规模超过 100 个集群的数据，但如果依照 20 或 50 个集群进行统计汇总，那么大规模演练的工作次数还会更多。
3.6 防守体系能力验证
在防守体系能力建设层面，咱们次要验证防守组件的三个外围能力：
- 第一个从高用来看，次要验证 RTO 和 RPO 是否合乎预期，以及在大规模故障场景下，其切换能力是否达标。
- 第二个从弹性伸缩来看，次要验证在单集群或规模化演练前提下，整体弹性扩容决策能力是否达到冀望，以及在小规模场景下实地验证弹性扩容的并发能力。
- 第三个从观测来看，次要验证当大规模演练产生时，观测工具的及时性以及准确性。
3.7 业务演练收益
诚然，演练会对业务方造成一些“打搅”，然而业务方也会踊跃配合咱们做这项工作，因为故障演练对业务方也有一些收益：一方面，业务方能够通过演练发现一些暗藏的问题，从而躲避更大的危险；另一方面，咱们在发现业务问题的同时，也能验证相干防守组件的体现是否合乎预期。更多的细节，大家能够参考下图：
04 将来瞻望
4.1 混沌工程成熟度模型
下图是混沌工程成熟度模型（CEEM），左边是咱们以后的数据库故障演练平台和规范的比照。能够显著地看到，以后咱们在一些维度上做的还不够，比方以后故障场景的笼罩水平、稳态指标的笼罩水平、试验观测、文化建设等方面都存在肯定的有余，而这些有余其实也是咱们后续着重要改良的点。
4.2 混沌工程成熟度等级
对于混沌工程成熟等级，咱们也做了一些总结：
- 从发展水平来看，以后咱们只是在一些外围部门进行了故障演练，在稳固晋升方面会有一些相干建设的成绩；
- 从落地播种来看，一是能够验证故障的影响，二是能够进步业务零碎对于故障的容忍度，三是能够通过数据库故障演练平台，评估咱们在稳定性建设方面的一些成绩；
- 从整体评级来看，咱们以后还处于根底阶段，前面也会持续在公司更多的外围部门推广数据库故障演练平台，继续为业务零碎稳定性晋升做出更大的奉献。
4.3 具体布局
在最初局部，咱们分享一下对于将来的布局。在具体门路层面，咱们会从五个方面进行发展工作：
- 第一，要升高单次演练老本，比方升高单次演练的染指率，无论是业务还是 DBA。
- 第二，丰盛故障演练场景，建设链路故障注入能力，从服务端故障向端到端故障做一个扩大。
- 第三，加强可观测性，以后整个故障演练平台在观测指标方面绝对比拟不足，后续咱们心愿通过引入更多的观测指标，从而更好地观测整个混沌工程的试验过程。
- 第四，智能化，次要聚焦三方面：① 建设整个稳态零碎，因为以后咱们整个故障演练是否合乎预期，次要还是通过人工或者 DBA 来进行判断，有了稳态零碎后，能够通过稳态零碎去判断；② 依据稳态零碎相干指标建设故障主动终止能力；③ 建设相干的演练举荐能力，因为当初业务线推广演练时，可能还不分明咱们该在哪些集群演练哪些场景，当有了这个能力后，业务在演练时会有更强的针对性。
- 第五，心愿可能实现演练常态化，即通过常态化演练去发现业务端更多的隐患。
| 在美团公众号菜单栏对话框回复【2022 年货】、【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。