5分钟一键切换！基于多云的站点同城容灾建设和故障演练实践

吴佳兴，恺英网络技术中心资深运维研发工程师。

曾就职于携程旅行网、哔哩哔哩弹幕视频网，目前在恺英网络担任资深运维研发工程师，也是 CNCF 多个项目的 contributor，目前专注于 IT 基础设施和研发效能提升

很高兴为大家带来一次线上的技术分享，我这次演讲的主题是基于多云的站点同城容灾建设和故障演练实践。

先简单介绍一下恺英网络，恺英网络是国内知名的互联网游戏上市公司，旗下的上海恺英、浙江盛和浙江九翎先后开发并运营了多款热门游戏，然后旗下的XY游戏平台是国内知名的精品网页游戏运营平台。我们这次演讲主题也即是运维同学怎么去运维XY平台的平台服务，然后保障稳定性和可用性的过程。

这是本次演讲的内容提要，分为四大块：

第一，首先介绍一下项目背景，为什么做这件事情。第二，怎么通过一个同城容灾的项目，通过机房架构跟站点架构的一个大规模的改造，实现站点的同城容灾。第三，怎么通过一个故障演练手段去验证，进一步优化可用性。第四，故障自愈+混沌工程的方向。

背景

首先介绍一下项目背景，在这之前我想先简单介绍一下什么是高可用，我想运维同学应该对这个概念并不陌生。高可用指的是系统能够无中断的执行其功能的能力，代表系统可用性程度。

这里有一个公式：

其中 A 是可用性，MTBF 是平均故障间隔，MTTR 是平均修复时间。可以看到，如果想要使一个系统可用性程度更高，那可以降低故障的发生频率，也可以缩短故障的持续时间。业内其实也有一个通俗说法，比如说 99.9%、99.99%，99.99% 已经算是比较高的一个程度。

这里是我个人对于站点高可用建设的几个维度的思考。

第一、鸡蛋不能放在一个篮子里。比如一个站点是托管到自建机房还是单个公有云都是不可靠的。无论是公有云还是自建机房都有故障的风险。使用公有云或单个自建机房，又没有备选方案和冗余方案，那很容易被绑架。我们知道公有云或者自建机房肯定是会有故障的风险，未来必然是一个多云或者是混合云的冗余架构。

第二、消除单点故障。 这个我相信运维同学都不陌生，比如服务架构，服务部署要求双副本或多副本，包括DB、SLB这些都需要消除单点故障。第三、提高关键节点的健壮性。这个关键节点我认为是站点架构里的核心交错点，比如网络、DB、SLB，如果这些关键节点能够提高健壮性，相对来说站点可用性是一个很大的提升。

第四、故障发生之后的快速恢复，这个我觉得可能大家很多时候对这块比较忽视，一个故障发生之后我们有没有对应的预案很快地去恢复，是不是可以通过降级、容灾、熔断的方式恢复服务，这也是一个很重要的维度。

上面是恺英网络2018年至今的可用性数据。可以看到 2018年不太理想，P0级别的事件发生多起，持续时间2000多分钟，可用性掉到99%。2019年-2020年都保证在99.9%，目前在往99.99%冲刺的阶段。为什么2018年故障这么频繁？可以从机房架构跟站点架构来思考下，XY平台当时部署在腾讯云广东机房，上海这边部署的是其他的核心服务，腾讯云和华为云中间有专线打通，一旦专线出现故障，腾讯云和华为云都不会成为责任方。

XY平台当时是腾讯云四层到七层，再到中山机房七层，再到后端DB的这样一个结构。其实我们遇到很多次故障，比如中山机房断电，网络炸了或者后端服务、DB挂了等等，一系列情况都是很被动的情况，除了中山机房，我们没有备选机房。另外一个情况，从腾讯云到中山机房是否健壮？能不能切走，也是一个问号。

诸如这些故障和痛点，确实不太好看，老板层面也有很大压力，促使我们做下一件事，就是同城容灾。

同城容灾（DR）

接下来从2018年开始做的事情，主要是同城容灾，相当于这套架构给改造掉，提高它的稳定性。这套方案称之为同城容灾也就是DR项目，为什么不做成多活模式？这个我们是有讨论过的，发现多活需要投入的精力很多，而且技术投入很大，比如说后端服务要做相应的改造，数据库层面可能需要一些中间件的支持，这个对我们来说是一个投入产出比没有那么高的情况，所以我们选择是一个更为适合我们的DR的方案。

这是我们当前的一个机房架构，可以看到从最开始的一个单机房，多云之间用单线直连，到现在引入 pop 点，office先连到 pop点，这个 pop 点连到云上。这样有什么好处呢？之前专线如果挂掉，没有责任方也没有冗余，现在 pop 点首先有冗余，然后 pop 点的一根专线挂掉也不会造成故障。另外一块我们对机房架构做了一定的标准化，分为核心机房和边缘机房。核心机房有华为云和腾讯云打通，核心机房和边缘机房通过 VPC0 连到对应的内部网络。为什么这样设计？我们在边缘部署一些单个的游戏服务，大家知道游戏特点快速迭代、快速验证的方式，如果投入产出比不理想，我们会快速卸掉，在这个过程中我们不希望对核心机房造成一些变动，所以会部署到边缘机房。这样一个结构对于我们是足够冗余的多云结构，鸡蛋没有放到一个篮子里。随着我们机房结构变迁，站点架构也做了一些改造。以XY平台为例，之前是腾讯云广州到中山机房的线路，中山机房是很大一块问题，其次有很多单点跟故障风险点。这些风险点在改造之后，首先演变成一个多云的冗余机构，每套云上面都有完整XY平台服务。DB的话，变成一个多主多从的数据库方案。

如果遇到各种故障，比如机房挂了，可以通过 DNS 直接切换到华为云上，如果是服务挂了，通过一个自建的SLB可以将后端自主切换到对应另外一套机房的后端，所以这里其实有一定的冗余和灾备的。

我们发现也会有一些痛点。

• 第一、手工操作。在发生故障的时候切换步骤非常多，切换执行下来会花费很多时间；

• 第二、工具可用性。发生故障的时候工具不一定就绪，比如说发生故障我们想用SLB平台，管理SLB的工具，想用SLB平台做切换的时候，我们发现这个工具也出问题了，也切不动了，这个时候很被动了，我们只有联系对应的工具开发去找问题，我们手动去配置和修改；

• 第三、可监察性。故障发生时需要通过监控告警手段去验证服务可用性。这里分为两点，第一点我们需要通过监控告警发现站点挂了，第二在故障发生之后切换了，怎样去验证切换是否OK呢？也是通过监控告警的手段。

• 第四、伪双活。真正要切换到备用服务器时，好像不是100%可用，这个相信大家可以理解。比如研发或运维做变更或代码发布，优先面向主，备有时候会很忽略，代码有没有更新？配置没有更新或是有些服务没有起，这些都是问题。

练兵：故障演练

那这些问题促使我们做下一个阶段的事情，也就是所谓故障演练，一个实际练兵的过程。我们前面做了架构改造，能不能验证，能不能进一步优化，我们就启用这样故障演练的手段。

以XY平台为例，架构是CNAME 域名指向四层再到七层，然后到后端再到DB，这里有两种方案，一种是DNS直接切换，第二种是后端解析过去。因为XY平台是一个核心服务，有依赖于第三方服务，例如微信和支付宝，如果单纯做DNS切换是会影响到客户的，如果主挂了，切DNS到备，主这边的服务还有人访问。

我们希望除了DNS之外，后端也能切换到备用的服务。这样的话，主跟备对应的 SLB 都起到了作用，大家访问的都是可用的那套服务。

这里需要调度的人员其实挺多的，每次演练都需要跨部门的协调。

这是一个故障演练的实际情况。可以看到分9大块，上图就是实际的一个步骤，这中间也依赖于监控告警，比如在模拟故障时，验证是否真正故障，DB停掉是否有告警？这样模拟效果达到了。

下方的图，访问量和 Nginx 处理量可以知道，故障之后访问量降低了，这也是可以验证切换是否成功了，服务的访问量回去了。

这是故障演练步骤。这是标准运维这个阶段，还是一个相对手工的阶段，即便是运维人员操作的时候是通过工具切换，但是其实这些步骤是手工操作步骤，其实是需要人去操作的，这里可以看到大概是花费了16分钟的时间，其实大部分都是SLB和数据库方面的切换，所操作花的时间。

这是我们这次故障演练时发生的一些问题，可以看到真正去做这件事情的时候，你会发现没有你想象的那么美好，你会发现有很多莫名其妙的问题冒出来。比如主从复制，数据不一致，IE浏览器访问、SLB等等。这必须是终端访问才会爆出来的问题。XP 系统 IE 浏览器访问发现 HTTPS 异常，只有真正做的这个故障演练，真正终端用户访问的时候才会出现这样的问题，所以这些问题是只有真正演练才会发现的问题。

我们刚说了标准运维的故障演练的阶段，这里其实还牵扯到一个阶段，我们在演练的时候工具挂了怎么办？这其实是一个很大的问题，怎样保障需要做切换的时候工具是可用的，这是一个大前提，这里我们就发起了第二阶段的演练过程，所谓的工具多活的改造。

工具能不能做成多活？首先这是一个前提和问题，那么其实是可以的，答案是肯定的，我们只需要把运维工具数据库置为双写，两边机房双写，因为工具场景是一个写频率比较低，写入口相对来说是可以控制的，因为操作人员就这些，可能是研发甚至只有运维同学来做，所以这些数据被脏写的风险很小，其实我们是可以通过数据库做成多活的模式，双写的模式来做成多活的。

这里是我们实际工具多活演练过程当中发生的一些问题，主要的问题还是工具跟工具之前其实是有依赖的，那么这个依赖是需要解开的。比如说当时发现 DB 切换是依赖 Workflow 工作流任务系统，工作流DB又是依赖DB，DB是只读的切不了，所以就发生这种问题。还有比如说代码不一致、服务的问题、监控问题这些都是问题，通过演练把这些问题发现解决掉。

这里可以理解为 Ansible 里的 playbook，搭配自定义参数里的 vars 变量组合起来，指定一个策略，可以一键切换。

下面是一个截图可以看到演练方案，然后是一个双机房后面是切换策略，从A机房切换到B机房，运维同学点切换按钮，点确认就可以自动化，一键式切换。这个是16个步骤，从检查工具系统是否可用，到维护，切换DB主从，包括后面切机房，DNS解析，其实运维只需要去看有没有什么问题，出问题去恢复，如果一套下来没有问题，那么减轻了运维同学很多的负担，所以是一键式切换平台带来的好处。

左边是一个变量，右边是执行的步骤。

通过这样一个一键切换工具平台，真正实现了站点能够在大约在5分钟内完成一键切换。

常态化演练

第四个阶段常态化演练，因为我们知道一个站点服务毕竟是一个不断演进，不断迭代的过程，包括代码也好服务架构、负载均衡配置也好，这些东西都是一个不断演进的过程，如果要保证这套流程不被腐化，那么一定需要常态化演练，定期要做的事情，稳步推进可靠性站点建设。定期要验证这个方案到底还能不能去做切换，所以这个是常态化演练的阶段，而且通过这样的手段，可以进一步一直往前走。

然后我们回顾一下刚才提到的一些高可用建设的方面，包括痛点。

• 第一、鸡蛋不放一个篮子里面，我们通过多云多机房的方案做一个冗余。

• 第二、消除单点故障，我们是把ELB、SLB、后端服务、DB这些层的单点故障给消除掉。

• 第三、关键节点的健壮性，这里是通过多云多线路+DR的手段提高健壮性。

• 第四、故障之后快速恢复。这里是制定标准运维流程，通过故障演练去验证，一键切换加速了故障的恢复。

这里一些痛点，

• 手工操作，通过一键切换来解决；
• 工具可用性，通过工具改造成多活来解决；
• 可监察性。我们是通过监控告警的手段来验证。这里还要回答一个问题，在故障发生时监控本身能不能保障高可用？现在虽然是做到了，但是还是有一些问题，监控系统其实还有一些依赖，比如服务树。一旦这些服务挂掉，我们会有一个兜底。如果是服务树挂了会有缓存，告警联系人从服务树获取，现在的方案可以写死一批名单；如果服务树也访问不通，告警再发给特定人员。这块还有一段路要走，这方面还没有实现真正的多活和高可用；
• 伪双活，我们是通过常态化故障演练来验证。

未来是希望站点故障自愈+混沌工程的方法。这其实大家也可以理解，因为故障是不可预料的，今天可能会是SSO挂了，机房断电了弄UPS，比如说WAF炸了，我们遇到过的，当时的办法是登机器改配置，导致站点可用性进一步降低了。这些不可预知的问题怎么解决呢？我们想通过混沌工程的方式去验证、发现，进而不断迭代。这也是我们未来的一个方向，大家有兴趣可以多多交流。这里就是我今天分享的所有内容，谢谢大家。

9月25日，GOPS全球运维大会 2020 · 深圳站，近80位演讲大咖，18个名企专场组团来袭~中行、腾讯、阿里、京东、招行、广东移动、神州泰岳，哪个是你的菜？

专场一览⬇️

精彩议题 ⬇️

近期好文：

从 MySQL 到 ClickHouse 实时复制与实现

关于 Kubernetes 的这些原理，你一定要了解

“高效运维”公众号诚邀广大技术人员投稿，
投稿邮箱：[email protected]，或添加联系人微信：greatops1118.