一次“实景”容灾演练 —— 以某新闻客户端为例

简介: 保障头部新闻客户端的业务连续性,阿里云帮助客户在真实场景下完成容灾演练

云计算和新闻APP,能有什么关系?
2021年,传媒行业某头部媒体的新闻客户端进行了全新改版并升级上线,以 “内容+技术”的融合驱动效率提升,加速其新媒体业务的数字化转型进程。

该客户端作为这一媒体在移动互联网端发布新闻的重要渠道,客户对发稿的时效性、直播的流畅性等方面有着极高的要求。具体到云平台侧,客户要求除了要保障云平台整体的稳定性外,还需要云平台能在极端情况下具备容灾逃逸能力,同时针对可用区级别的容灾提出了更高的RTO和RPO要求。

客户的命题看起来似乎很简单:“一个机房挂了,另一个机房要能用,这样不会影响到稿件的正常及时发布,保证新闻的时效性”。

这个命题对于阿里云团队来说,意味着要基于同城双AZ容灾架构,保证平台的可用性,进而提升客户业务的连续性。

更有挑战性的是,对于这个命题的解答,客户要求不能仅仅提留在“理论”层面,还需要阿里云接受“实实在在的实景考验”,即在预期时间范围内,在设定的故障场景下,我们要验证:当第一个AZ 故障后,云平台具备切换至第二个AZ的能力,证明阿里云的云平台具备在AZ之间30分钟内完成切换的能力,同时在修复主机房的故障之后完成回切。

看似简单,实则不然
从拿到命题,到交卷,这用了近五个月时间,其中规划期就用了近2个月。同城双AZ架构本身并不算是很复杂的架构形式,但这道题的难点在于客户业务作为新闻客户端的特殊性。新闻具有突发性和时效性,业务难以被预测,所以每一次给到阿里云进行变更的窗口期都很珍贵,且不能失败,这对于技术和评估就提出了很高要求。

其次,客户对于这次容灾演练也是既谨慎又大胆,愿意创新突破,但同时也因为担心影响到真实的业务而非常忐忑。虽然该传媒客户没有金融级客户对于数据的强一致性要求,但是因为容灾演练要基于真正的生产环境,对于可用性的要求极高,云产品的所有组件在演练完成后都要尽快回到切换前的终态。此外,容灾演练需要联动云平台和上层应用,不仅涉及云平台,还要考虑到云外的网络和公共云等因素,要求对业务的影响时段和影响面可控。

最终,阿里云TAM团队现场调研、摸底,并结合产研团队的技术评审,针对平台业务、产品、所有组件进行了多轮摸底调研,制定了数百个CHK项,对客户应用负载、调用链路、应用配置、部署形态等多方面进行了全面的诊断和治理。全程阿里云团队通过了20多次灰度切换验证,熬过6个通宵,涉及十几个演练场景,对原有产品、演练方案进行了30个改进项的完善和落地,还做了一个模拟客户业务访问的模型demo监控,来确保演练在最终实施时的可行性。

一次充满“反差感”的演练
就这样,来到了真实演练的那一天,整个过程并没有想象中的惊心动魄,反而是平稳顺利。在主机房注入故障后的10分钟内,整个云平台就完成了应急切换;历时7个小时,顺利完成带生产业务的机房级容灾演练,整个过程对业务影响不超过1小时,并进行了全场景、全流程的业务测试,通过率100%。演练过程中,阿里云进行了多次预案执行的有效性和应急处置,拟定好的组织、角色按演练SOP有效执行,确保了整个演练流程的规范和有序。

在孤岛演练之后的三天内,阿里云和该客户进行了无业务影响的长尾问题修复,使平台恢复到演练前状态。这次演练不仅验证了云平台、业务的容灾能力,还帮助客户完善了网络容灾能力的建设,进一步增强了客户对于云平台灾备能力的信心。

容灾,何以成为阿里云的竞争力?
阿里云飞天企业版同城容灾解决方案,让云平台的容灾能力全面覆盖网络产品、云计算产品、数据库产品、存储产品、中间件产品等核心云产品,采用网络互备、数据主备模式构建了整个云平台同城双AZ容灾能力。

除了覆盖产品广,阿里云飞天企业版还配备全栈式灾备管理平台,针对不同机房级故障提供一键式容灾切换能力(如下图);一旦发生灾难(如主机房掉电/网络孤岛故障/单产品故障等),可通过灾备管理平台进行一键式切换,提高云平台抵御自然灾害、设备故障、系统故障等突发事件的能力,提升云平台及云上客户业务连续性。

相较于传统的容灾方案,阿里云专有云同城容灾架构提供了一致性的容灾切换体验,对客户业务透明,使用户能更加聚焦于业务开发,降低应用开发难度,提供更加便捷的体验。

灾备图片.png

(阿里云飞天企业版灾备管理平台界面)

在此基础上,TAM团队针对客户业务的使用场景,结合项目现场运维和各类容灾架构平台的演练实施经验,不仅安全高效地完成方案实施落地,更在实施过程中不断发现方案与现场环境的缺陷并予以纠正迭代,使得解决方案更加完善;贴合客户平台真实环境,真正做到了最贴近真实故障、最小化业务影响、最快速应急恢复的技术目标。

通过产品技术能力和现场运维能力的双剑合璧,阿里云飞天企业版同城灾备方案得以无缝平滑落地,顺利完成本次容灾演练。

风雨后再回首,是更广阔的天空
回看这次容灾演练,带着真实业务做测试,就好像在飞机飞行中换引擎。阿里云TAM运维团队与产研团队携手,不仅建成了阿里云在传媒行业首个同城双AZ容灾云平台,更基于双方的紧密配合和对于平台的精细化管理,熟悉现场环境和故障应急处理的全流程,完成了平台上的不中断业务演练任务,让客户真正看到并相信了阿里云同城双AZ的容灾能力。

这说明了阿里云飞天企业版的容灾能力,并没有停留在文档或是方案里。这个能力是可被演练、可被验证的。而这份底气,是我们前进的意义,也是客户信任的根基。

相关文章
|
容灾
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.5 A机房公共区&核心区云产品切换演练
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.5 A机房公共区&核心区云产品切换演练
|
容灾
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.6 A机房公共区云平台故障演练(入口断网)
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.6 A机房公共区云平台故障演练(入口断网)
|
容灾 NoSQL 关系型数据库
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.1 公共区数据层演练
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.1 公共区数据层演练
115 0
|
容灾 应用服务中间件
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.2 公共区应用层演练
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.2 公共区应用层演练
|
容灾
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.7 机房核心区云平台故障演练(入口断网)
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.7 机房核心区云平台故障演练(入口断网)
|
容灾 NoSQL 关系型数据库
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.3 核心区数据层演练
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.4 容灾演练方案——4.4.3 核心区数据层演练
|
容灾 数据中心
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.1 容灾演练调研——4.1.1 调研及改造目标
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.1 容灾演练调研——4.1.1 调研及改造目标
|
弹性计算 容灾 安全
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.2 平台侧网络改造(上)
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.2 平台侧网络改造(上)
290 0
|
负载均衡 容灾 应用服务中间件
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.2 平台侧网络改造(下)
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.2 平台侧网络改造(下)
236 0
|
弹性计算 负载均衡 容灾
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.3 应用侧网络改造
《医保行业容灾演练云上技术白皮书》——第四章 医保云容灾演练方案——4.2 容灾演练改造——4.2.3 应用侧网络改造
134 0