腾讯云的云上容灾实践

在 2023 年 11 月 12 日，刚经过双 11 的购物节大压力的阿里，却从 17:44 起发生了服务宕机，旗下的淘宝、闲鱼、饿了么等服务出现服务中断，甚至让高校学生宿舍的洗衣机都“宕机”了。从阿里云健康看板公布的数据可以看出，阿里云的几乎所有的云产品等服务都受到了影响，影响了全球范围内多个地域。阿里云这次故障，放在整个云厂商界都是炸裂般的存在。阿里云历时 3 个多小时，服务才陆续恢复。

https://status.aliyun.com/#/historyEvent

开始时间 (GMT+8) :

2023-11-12 17:44

结束时间 (GMT+8) :

2023-11-12 21:11

故障带来的思考🤔️

回到故障本身，不管什么原因导致了此次阿里如此严重的故障，充分说明现实世界中复杂系统中灾难（即使再小的概率）是无法完全避免的！故障既然客观存在，那么如何降低甚至避免此类故障发生时给构建于云上的业务系统不受影响才是我们应该思考的问题。

拥抱多云

从 flexera 的统计数据（Flexera 2023 State of the Cloud Report）来看，采用多云容灾架构的占比高达 87%。其中多公有云的架构占有 13%。

对于企业及组织而言，多云不仅可以降低对单一平台的过度依赖，避免绑定风险，减少因单一云平台出现技术故障而导致全线崩塌的情况，有效提高云端容错率。此外，从 12 日发生的阿里“单云级”故障，我们也可以看出，把所有业务的安全性都押在同一个云服务商身上并不绝对保险。多云战略已成为当下大多数上云企业及组织的选择项。

云容灾架构建设新范式——云上混沌工程

为了减少一个云厂商服务或者云产品不可用时给业务带来的影响，云容灾架构就是一个有效的方案，但是这仅仅是一个理论上可行的方案，事实是否真的有效呢？有没有一个标准的范式可以帮助用云的团队验证容灾方案有效性，以及进行常态化的容灾稳定性建设呢？有，便是开展云上的混沌工程。

什么是云上混沌工程？

混沌工程的诞生可以追溯到 2008 年，位于美国加利福尼亚州的 Netflix 公司数据中心，发生了一起重大的数据库故障。为解决这一问题，Netflix 创造了 Chaos Monkey。它会在集群列表中随机选择一个服务器将其关闭，主动将问题摆在工程师面前进行解决。Chaos Monkey 就是混沌工程的雏形。在 2015 年，Netflix 工程师团队正式定义了混沌工程“Chaos Engineering”。混沌工程就是一种故障主动注入测试的方法，通过实验的方式发现问题并解决问题。之后，混沌工程不断发展，逐渐发展为稳定性建设的一套完整的工程化解决方案。

所谓云上混沌工程，就是在云计算环境中开展传统的混沌工程实践，为构建于云环境中的业务系统提供稳定性保障。云上混沌工程会对各种云上资源（IaSS,PaSS,SaSS 等产品服务）主动引入故障，模拟真实生产环境中的灾难场景，验证业务系统面对灾难时的稳定性韧性。在云上开展混沌工程，可以帮助用户发现平时难以发现的容灾设计隐患并及时修复验证。将云上混沌工程纳入到业务系统的发展周期中是科学，有必要的。

腾讯云的云上混沌工程

腾讯云早在 2021 年就意识到混沌工程对于稳定性建设的科学意义，并在内部的各个产品以及服务中逐步开展混沌工程，成立「混沌蓝军」虚拟组织，积极的开展内部的云上混沌工程实践，并将沉淀的稳定性建设经验逐步开放到公有云，推出「腾讯云混沌演练平台」。

腾讯云混沌异地多活容灾客户案例

上图便是一个针对云数据库腾讯云 &用户 IDC 容灾混沌场景，通过引入「云数据库 MySQL 不可用」以及「云数据库 Redis 不可用」故障，模拟数据库单云灾难场景。用于验证业务架构是否能够及时切换到 IDC 环境数据库，达到业务容灾要求。通过该云上的混沌演练，可以验证云上云下的容灾架构有效性以及故障应急处理机制是否合理，也可显著提高用户面对单云数据库灾难时的信心。

腾讯云混沌的故障能力

腾讯云混沌团队结合多年内部稳定性建设经验，与各个云产品团队通力合作，沉淀出百余种原子故障场景，并提供灵活的演练编排能力，可以轻松设计复合场景的混沌演练。