在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 受影响产品 : 企业级分布式应用服务、消息队列 MQ、微服务引擎、链路追踪、应用高可用服务、应用实时监控服务、Prometheus监控服务、消息服务、消息队列Kafka版、机器学习、图像搜索、智能推荐 AIRec、智能开放搜索 OpenSearch、云行情、数据总线 DataHub、检索分析服务 Elasticsearch版、图计算服务 Graph Compute、实时计算 Flink版、智能数据建设与治理 Dataphin、开源大数据平台 E-MapReduce、云原生大数据计算服务 MaxCompute、实时数仓 Hologres、大数据开发治理平台 DataWorks、智能媒体服务、媒体处理、视频点播、对象存储、文件存储NAS、表格存储、日志服务、云存储网关、文件存储 HDFS 版、块存储、混合云备份服务、密钥管理服务、云防火墙、数据库审计、加密服务、运维安全中心（堡垒机）、容器镜像服务、容器服务Kubernetes版、API 网关、资源编排、云原生数据仓库 AnalyticDB PostgreSQL版、图数据库、云原生内存数据库Tair、云数据库 Redis 版、云原生关系型数据库 PolarDB、云数据库专属集群、云数据库 MySQL 版、云原生数据仓库AnalyticDB MySQL版、云原生分布式数据库 PolarDB-X、云数据库 ClickHouse、云原生多模数据库Lindorm、云数据库 PostgreSQL 版、云数据库 SQL Server 版、云数据库 MongoDB 版、云数据库HBase版、数据传输、数据库自治服务、数据库备份、物联网平台、NAT网关、负载均衡、云解析 PrivateZone、弹性公网IP、共享带宽、转发路由器、私网连接、高速通道、IPv6 网关、专有网络VPC、云企业网、VPN网关、FPGA 云服务器、超级计算集群、批量计算、无影云桌面、弹性伸缩、弹性容器实例、弹性裸金属服务器、云服务器 ECS、轻量应用服务器、函数计算、Serverless 应用引擎、云托付、专有宿主机、GPU云服务器、弹性高性能计算、操作审计、服务器迁移中心、运维编排、智能计算灵骏、云呼叫中心、交通云控平台、客服工作台、视觉智能开放平台、智能外呼机器人、智能语音交互、智能对话机器人、智能用户增长、运维事件中心、新零售智能助理、智能双录质检、地址标准化、机器翻译、自然语言处理、短信服务、云解析DNS、域名、号码认证服务、邮件推送、版权与专利服务、语音服务、智能联络中心、工商财税、Salesforce on Alibaba Cloud、智能营销引擎、云采销、能耗宝、阿里邮箱、商标服务、移动研发平台、机器人流程自动化、号码隐私保护、DataV数据可视化、音视频通信、视频直播、闪电立方、网盘与相册服务、安全、内容安全、安全管家、应用身份服务 (IDaaS)、实人认证、数字证书管理服务（原SSL证书）、风险识别、Web应用防火墙、云安全中心（态势感知）、数据管理、云价签、云投屏、物联网智能视频服务、物联网无线连接服务、CDN、云数据传输、数据语音、智能接入网关、全站加速、ChatAPP 消息、全球加速、安全加速 SCDN、边缘节点服务 ENS、访问控制、资源管理、云监控、配置审计 受影响地域 : 华北2（北京）、华北6（乌兰察布）、华北1（青岛）、华东2（上海）、华南2（河源）、华北3（张家口）、中国香港、印度（孟买）、美国（硅谷）、华南1（深圳）、英国（伦敦）、韩国（首尔）、日本（东京）、阿联酋（迪拜）、西南1（成都）、华南3（广州）、新加坡、澳大利亚（悉尼）、马来西亚（吉隆坡）、华北5（呼和浩特）、印度尼西亚（雅加达）、美国（弗吉尼亚）、菲律宾（马尼拉）、泰国（曼谷）、华东1（杭州）、华南1 金融云、华东5（南京-本地地域）、华东6（福州-本地地域）、华北2 金融云（邀测）、华东2 金融云、华东1 金融云、华北2 阿里政务云1、非区域性、德国（法兰克福）、沙特（利雅得-合作伙伴运营）
故障带来的思考🤔️
回到故障本身，不管什么原因导致了此次阿里如此严重的故障，充分说明现实世界中复杂系统中灾难（即使再小的概率）是无法完全避免的！故障既然客观存在，那么如何降低甚至避免此类故障发生时给构建于云上的业务系统不受影响才是我们应该思考的问题。
拥抱多云
从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环境数据库，达到业务容灾要求。通过该云上的混沌演练，可以验证云上云下的容灾架构有效性以及故障应急处理机制是否合理，也可显著提高用户面对单云数据库灾难时的信心。
腾讯云混沌的故障能力
腾讯云混沌团队结合多年内部稳定性建设经验，与各个云产品团队通力合作，沉淀出百余种原子故障场景，并提供灵活的演练编排能力，可以轻松设计复合场景的混沌演练。
