> **来源：[研报客](https://pc.yanbaoke.cn)** # 华为云卓越架构技术框架与实践 文档版本 01 发布日期 2026-01-05 版权所有 © 华为技术有限公司 2026。保留一切权利。 非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。 # 商标声明 HUAWEI和其他华为商标均为华为技术有限公司的商标。 本文档提及的其他所有商标或注册商标，由各自的所有人拥有。 # 注意 您购买的产品、服务或特性等应受华为公司商业合同和条款的约束，本文档中描述的全部或部分产品、服务或特性可能不在您的购买或使用范围之内。除非合同另有约定，华为公司对本文档内容不做任何明示或暗示的声明或保证。 由于产品版本升级或其他原因，本文档内容会不定期进行更新。除非另有约定，本文档仅作为使用指导，本文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。 # 安全声明 # 漏洞处理流程 华为公司对产品漏洞管理的规定以“漏洞处理流程”为准，该流程的详细内容请参见如下网址：https://www.huawei.com/cn/psirt/vul-response-process 如企业客户须获取漏洞信息，请参见如下网址：https://securitybulletin.huawei.com/enterprise/cn/security-advisory # 目录 # 1卓越架构技术框架简介 # 2 韧性支柱 4 2.1 韧性支柱简介 4 2.2基本概念 4 2.2.1 概念表 5 2.2.2 什么是应用韧性 2.2.3责任共担模式 6 2.2.4 可用性目标定义 6 2.2.4.1 可用度及SLO 6 2.2.4.2 RTO与RPO 8 2.2.4.3 数据持久度 9 2.2.5 可用性需求 9 2.3 设计原则 9 2.4 问题和检查项 ..... 11 2.5 高可用设计 13 2.5.1 RES01 冗余 13 2.5.1.1 概述 13 2.5.1.2 RES01-01 应用组件高可用部署 13 2.5.1.3 RES01-02 应用组件多位置部署 15 2.5.1.4 RES01-03 云服务器反亲和 15 2.5.2 RES02 备份 15 2.5.2.1 概述 ..... 15 2.5.2.2 RES02-01 识别和备份应用中所有需要备份的关键数据 ..... 16 2.5.2.3 RES02-02 自动数据备份 16 2.5.2.4 RES02-03 定期进行备份数据恢复 17 2.5.3 RES03 跨 AZ 容灾 17 2.5.3.1 概述 17 2.5.3.2 RES03-01 集群跨AZ部署 17 2.5.3.3 RES03-02 跨 AZ 数据同步 18 2.5.3.4 RES03-03 对接容灾仲裁，支持自动切换 19 2.5.3.5 RES03-04 支持容灾管理 19 2.5.4 RES04 跨Region/跨云容灾 19 2.5.4.1 概述 19 2.5.4.2 RES04-01 定义应用系统的容灾目标 RPO 与 RTO ..... 20 2.5.4.3 RES04-02 部署容灾系统以满足容灾目标 20 2.5.4.4 RES04-03容灾恢复过程自动化 21 2.5.4.5 RES04-04 定期进行容灾演练，以检查恢复能否满足容灾目标 21 2.5.5 RES05 网络高可用 22 2.5.5.1 概述 22 2.5.5.2 RES05-01 网络连接高可用 22 2.5.5.3 RES05-02避免暴露不必要的网络地址 23 2.5.5.4 RES05-03 不同流量模型业务的网络共享带宽隔离 23 2.5.5.5 RES05-04 预留 IP 资源以便扩展及高可用 ..... 23 2.6 故障全面检测 ..... 24 2.6.1 RES06 故障检测 24 2.6.1.1 概述 24 2.6.1.2 RES06-01 故障模式分析 24 2.6.1.3 RES06-02 面向所有故障进行检测 25 2.6.1.4 RES06-03 支持亚健康检测 26 2.6.2 RES07 监控告警 26 2.6.2.1 概述 26 2.6.2.2 RES07-01 定义关键指标与阈值并监控 ..... 27 2.6.2.3 RES07-02 日志统计监控 ..... 28 2.6.2.4 RES07-03 监控到异常后发送消息通知 28 2.6.2.5 RES07-04 监控数据存储和分析 ..... 29 2.6.2.6 RES07-05 端到端跟踪请求消息 29 2.7 故障快速恢复 29 2.7.1 RES08 依赖减少与降级 29 2.7.1.1 概述 30 2.7.1.2 RES08-01 减少强依赖项 30 2.7.1.3 RES08-02 依赖松耦合 30 2.7.1.4 RES08-03 减少被依赖项故障的影响 31 2.7.2 RES09 故障重试 31 2.7.2.1 概述 31 2.7.2.2 RES09-01 API 及命令调用需要设计为可重试 31 2.7.2.3 RES09-02 客户端需要根据综合评估是否要重试 32 2.7.2.4 RES09-03 重试需要避免造成流量压力 2.7.3 RES10 故障隔离 32 2.7.3.1 概述 32 2.7.3.2 RES10-01 应用控制平面与数据平面隔离 32 2.7.3.3 RES10-02 应用系统多位置部署 33 2.7.3.4 RES10-03采用Grid架构 33 2.7.3.5 RES10-04 健康检查与自动隔离 35 2.7.4 RES11 可靠性测试 35 2.7.4.1 概述 35 2.7.4.2 RES11-01 混沌测试 35 2.7.4.3 RES11-02 压力负载测试 36 2.7.4.4 RES11-03 长稳测试 37 2.7.4.5 RES11-04 灾难演练 37 2.7.4.6 RES11-05 红蓝攻防 37 2.7.5 RES12 应急恢复处理 37 2.7.5.1 概述 38 2.7.5.2 RES12-01 组建应急恢复团队 38 2.7.5.3 RES12-02 制定应急预案 38 2.7.5.4 RES12-03 定期应急恢复演练 38 2.7.5.5 RES12-04出现问题后尽快恢复业务 39 2.7.5.6 RES12-05 应急恢复回溯 39 2.8 过载控制 39 2.8.1 RES13 过载保护 39 2.8.1.1 概述 39 2.8.1.2 RES13-01 采用自动弹性扩缩容 2.8.1.3 RES13-02 应用系统负载均衡，避免流量不均匀 41 2.8.1.4 RES13-03 过载检测与流量控制 41 2.8.1.5 RES13-04 支持主动扩容 41 2.8.1.6 RES13-05 资源自动扩容考虑了配额限制 42 2.8.1.7 RES13-06 压力负载测试 42 2.9 变更防差错 42 2.9.1 RES14 配置防差错 43 2.9.1.1 概述 43 2.9.1.2 RES14-01 变更防呆检查 43 2.9.1.3 RES14-02 自动化变更 43 2.9.1.4 RES14-03 变更前数据备份 44 2.9.1.5 RES14-04 提供 runbook 进行标准化变更 44 2.9.2 RES15 升级不中断业务 44 2.9.2.1 概 44 2.9.2.2 RES15-01 自动化部署和升级 44 2.9.2.3 RES15-02 自动化检查 44 2.9.2.4 RES15-03 自动化回滚 45 2.9.2.5 RES15-04 灰度部署和升级 45 2.10参考架构 45 2.10.1 概述 46 2.10.2 内部工具或公测类应用典型部署架构（99%） 46 2.10.3 内部知识管理类应用典型部署架构（99.9%） 47 2.10.4 信息管理类应用典型部署架构（99.95%） 49 2.10.5 电商类应用典型部署架构（99.99%） ..... 51 2.10.5.1 单 Region 方案 ..... 51 2.10.5.2 双 Region 方案 53 2.10.6 金融类核心应用典型部署架构（99.999%） ..... 54 2.10.7 跨云场景典型部署架构（99.99%） 56 2.10.7.1 概述 56 2.10.7.2 跨云容灾方案 57 2.10.7.3 跨云双活方案 58 2.11 云服务可靠性介绍 60 2.11.1 概述 60 2.11.2 ECS弹性云服务器 62 2.11.2.1 可靠性功能 62 2.11.2.2 常见故障模式 63 2.11.3 BMS 裸金属服务器 64 2.11.3.1 可靠性功能 64 2.11.3.2 常见故障模式 65 2.11.4 CCE云容器引擎 65 2.11.4.1 可靠性功能 66 2.11.4.2 常见故障模式 67 2.11.5 ELB弹性负载均衡 67 2.11.5.1 可靠性功能 68 2.11.5.2 常见故障模式 68 2.11.6 AS弹性伸缩 68 2.11.6.1 可靠性功能 68 2.11.6.2 常见故障模式 69 2.11.7 DCS分布式缓存服务 69 2.11.7.1 可靠性功能 69 2.11.7.2 常见故障模式 70 2.11.8 DMS分布式消息服务 71 2.11.8.1 可靠性功能 ..... 71 2.11.8.2 常见故障模式 71 2.11.9 RDS 云数据库 ..... 72 2.11.9.1 可靠性功能 ..... 72 2.11.9.2 常见故障模式 73 2.11.10 云数据库 TaurusDB 云数据库 ..... 73 2.11.10.1 可靠性功能 73 2.11.10.2 常见故障模式 74 2.11.11 OBS 对象存储服务 75 2.11.11.1 可靠性功能 75 2.11.11.2 常见故障模式 76 3安全性支柱 77 3.1概述 77 3.1.1 安全性支柱简介 77 3.1.2责任共担模型 78 3.2 基本概念 78 3.2.1 概念表 79 3.2.2 概念模型 80 3.3设计原则 81 3.4 问题和检查项 ..... 83 3.5 云安全治理策略 ..... 84 3.5.1 SEC01 云安全治理策略 84 3.5.1.1 SEC01-01 建立安全管理团队 ..... 84 3.5.1.2 SEC01-02 建立安全基线 ..... 85 3.5.1.3 SEC01-03 梳理资产清单 ..... 85 3.5.1.4 SEC01-04分隔工作负载 86 3.5.1.5 SEC01-05 实施威胁建模分析 87 3.5.1.6 SEC01-06 识别并验证安全措施 ..... 88 3.6 基础设施安全 ..... 88 3.6.1 SEC02 身份认证 88 3.6.1.1 SEC02-01 对账号进行保护 89 3.6.1.2 SEC02-02 安全的登录机制 89 3.6.1.3 SEC02-03 安全管理及使用凭证 90 3.6.1.4 SEC02-04 一体化身份管理 90 3.6.2 SEC03 权限管理 91 3.6.2.1 SEC03-01 定义权限访问要求 91 3.6.2.2 SEC03-02 按需分配合适的权限 91 3.6.2.3 SEC03-03 定期审视权限 92 3.6.2.4 SEC03-04 安全共享资源 92 3.6.3SEC04网络安全 93 3.6.3.1 SEC04-01 对网络划分区域 93 3.6.3.2 SEC04-02 控制网络流量的访问 93 3.6.3.3 SEC02-03 网络访问权限最小化 94 3.6.4 SEC05 运行环境安全 95 3.6.4.1 SEC05-01 云服务安全配置 95 3.6.4.2 SEC05-02 实施漏洞管理 96 3.6.4.3 SEC05-03 减少资源的攻击面 96 3.6.4.4 SEC05-04 密钥安全管理 97 3.6.4.5 SEC05-05 证书安全管理 ..... 97 3.6.4.6 SEC05-06 使用托管云服务 98 3.7应用安全 99 3.7.1 SEC06 应用安全性 99 3.7.1.1 SEC06-01 安全合规使用开源软件 99 3.7.1.2 SEC06-02 建立安全编码规范 99 3.7.1.3 SEC06-03 实行代码白盒检视 100 3.7.1.4 SEC06-04 应用安全配置 101 3.7.1.5 SEC06-05 执行渗透测试 101 3.8 数据安全与隐私保护 101 3.8.1 SEC07通用数据安全 101 3.8.1.1 SEC07-01 识别工作负载内的数据 ..... 102 3.8.1.2 SEC07-02 数据保护控制 102 3.8.1.3 SEC07-03 对数据操作实施监控 103 3.8.1.4 SEC07-04 静态数据的加密 ..... 103 3.8.1.5 SEC07-05 传输数据的加密 ..... 104 3.8.2 SEC08 数据隐私保护 104 3.8.2.1 SEC08-01 明确隐私保护策略和原则 ..... 105 3.8.2.2 SEC08-02 主动通知数据主体 ..... 106 3.8.2.3 SEC08-03 数据主体的选择和同意 106 3.8.2.4 SEC08-04 数据收合合规性 107 3.8.2.5 SEC08-05 数据使用、留存和处置合规性 107 3.8.2.6 SEC08-06 向第三方披露个人数据合规性 108 3.8.2.7 SEC08-07 数据主体有权访问其个人隐私数据 108 3.9安全运营 109 3.9.1 SEC09 安全感知及分析 109 3.9.1.1 SEC09-01 实施标准化管理日志 109 3.9.1.2 SEC09-02 安全事件记录及分析 109 3.9.1.3 SEC09-03 实施安全审计 110 3.9.1.4 SEC09-04 安全态势感知 110 3.9.2 SEC10 安全事件响应 111 3.9.2.1 SEC10-01 建立安全响应团队 ..... 111 3.9.2.2 SEC10-02 制定事件响应计划 ..... 111 3.9.2.3 SEC10-03 自动化响应安全事件 112 3.9.2.4 SEC10-04 安全事件演练 114 3.9.2.5 SEC10-05 建立复盘机制 115 3.10参考架构 116 3.10.1 组织级参考架构 116 3.10.2 工作负载级参考架构 119 3.11安全性云服务介绍 121 4性能效率支柱 123 4.1性能效率支柱简介 123 4.2 基础概念 124 4.3设计原则 124 4.4 问题和检查项 ..... 125 4.5PERF01 流程与规范 126 4.5.1全生命周期性能管理 126 4.5.1.1 PERF01-01全生命周期性能管理 126 4.5.2 应用性能编程规范 127 4.5.2.1 PERF01-02 应用性能编程规范 127 4.6PERF02性能规划 128 4.6.1 性能规划 ..... 128 4.6.1.1 PERF02-01 定义性能目标 128 4.6.1.2 PERF02-02 容量规划 129 4.7PERF03性能建模 130 4.7.1 选择合适的计算资源 130 4.7.1.1 PERF03-01 选择合适类型的计算云服务 130 4.7.1.2 PERF03-02 选择合适规格的虚拟机和容器节点 ..... 131 4.7.1.3 PERF03-03 使用弹性伸缩 131 4.7.2 选择合适网络服务资源 133 4.7.2.1 PERF03-04 选择合适类型的网络云服务 133 4.7.3 选择合适的存储云服务 134 4.7.3.1 PERF03-05 选择合适类型的存储云服务 134 4.7.4 选择合适的应用中间件云服务资源 136 4.7.4.1 PERF03-06 选择合适的消息队列 136 4.7.4.2 PERF03-07 选择合适的Kafka 4.7.4.3 PERF03-08 选择合适的 RocketMQ 137 4.7.4.4 PERF03-09 选择合适的 RabbitMQ ..... 137 4.7.5 选择合适的数据库资源 137 4.7.5.1 PERF03-10 选择合适的关系型数据库 138 4.7.5.2 PERF03-11 选择合适的非关系型数据库 138 4.8PERF04性能分析 139 4.8.1 性能测试 139 4.8.1.1 PERF04-01 定义验收标准 140 4.8.1.2 PERF04-02 选择合适的测试方式 ..... 140 4.8.1.3 PERF04-03 性能测试步骤 ..... 140 4.8.2 性能数据采集 143 4.8.2.1 PERF04-04 资源性能数据收集 143 4.8.2.2 PERF04-05 应用性能数据采集 143 4.8.3 建立性能可观测性体系 144 4.8.3.1 PERF04-06 建立性能可观测性体系 ..... 144 4.9PERF05性能优化 144 4.9.1设计优化 144 4.9.1.1 PERF05-01 设计优化 144 4.9.2 算法优化 146 4.9.2.1 PERF05-02 通用算法优化 146 4.9.3 资源优化 147 4.9.3.1 PERF05-03 WEB 场景资源优化 147 4.9.3.2 PERF05-04大数据场景资源优化 147 4.10PERF06性能看护 148 4.10.1 性能看护 148 4.10.1.1 PERF06-01 分层看护 148 4.10.1.2 PERF06-02 性能劣化自动定界定位 149 4.10.1.3 PERF06-03 自动告警 149 4.11 云服务性能优化介绍 ..... 150 4.11.1 缓存性能优化 ..... 150 4.11.2 消息队列性能优化 154 4.11.2.1 Kafka 性能优化 ..... 154 4.11.2.2 RabbitMQ 性能优化 157 4.11.3 Serverless 性能优化 159 4.11.4 数据库性能优化 162 4.11.5 人工智能性能优化 ..... 163 4.11.6大数据性能优化 165 4.11.6.1 HIVE优化 166 4.11.6.2 Spark 性能优化 168 4.11.6.3 Flink 性能优化 ..... 169 # 5 成本优化支柱 171 5.1 成本优化支柱简介 171 5.2 基础概念 ..... 171 5.3设计原则 172 5.4 问题和检查项 ..... 173 5.5 COST01 规划成本优化相应的组织机构和流程 174 5.5.1 COST01-01 规划企业组织，将组织结构，流程和成本管理相匹配 174 5.5.2 COST01-02规划IT治理体系，提高管理效率 174 5.5.3 COST01-03 明确团队责任，建立和维护成本意识文化 175 5.5.4 COST01-04 制定云资源管理策略和相应的权限管理机制 ..... 175 5.6 COST02 实施预算规划管理机制 175 5.6.1 COST02-01 建立云预算与预测流程 175 5.6.2 COST02-02 精细化预算管理和跟踪 176 5.7 COST03 对成本进行分配 176 5.7.1 COST03-01 制定成本分摊原则 176 5.7.2 COST03-02 可视化成本分摊结果 177 5.7.3 COST03-03 公共成本分配 177 5.8 COST04持续进行成本治理 178 5.8.1 COST04-01 建立规范，持续提升成本分配比例 178 5.8.2 COST04-02 主动监控成本 179 5.9 COST05 优化指定策略和目标 ..... 179 5.9.1 COST05-01 分析业务趋势和优化收益 179 5.9.2 COST05-02 建立可以量化的优化目标 180 5.9.3 COST05-03 定期回顾和审核 ..... 180 5.10 COST06 使用不同计费模式优化成本 181 5.10.1 COST06-01 了解云上不同计费模式的特点 ..... 181 5.10.2 COST06-02 为工作负载选择合适的计费模式 ..... 181 5.10.3 COST06-03 跟踪并监控权益商品的使用情况 ..... 182 5.11 COST07 管理和优化资源 ..... 182 5.11.1 COST07-01持续监控资源利用率指标 182 5.11.2 COST07-02 释放闲置资源 182 5.11.3 COST07-03 考虑不同的云资源技术选型 182 5.11.4 COST07-04 合理降配低负载资源或升配高负载资源 183 5.12 COST08 进行架构优化 183 5.12.1 COST08-01 按地域规划应用架构 183 5.12.2 COST08-02 云原生架构改造 183 5.12.3 COST08-03 存算分离 183 5.12.4 COST08-04 Serverless 探索 184 5.13 成本优化云服务介绍 184 # 6卓越运营支柱 185 6.1卓越运营支柱简介 185 6.2 基础概念 185 6.3设计原则 187 6.4 问题和检查项 ..... 188 6.5OPS01 建立持续改进的团队文化和标准化的运维体系 189 6.5.1 OPS01-01 建立持续学习和改进的文化 ..... 189 6.5.2OPS01-02规划标准化的运维组织 189 6.5.3OPS01-03规划标准化的运维流程和运维工具 190 6.6OPS02通过CI/CD实现高效的频繁可逆的小规模变更 191 6.6.1OPS02-01进行需求管理和迭代开发 191 6.6.2OPS02-02关联源代码版本和部署的应用版本，使用代码质量最佳实践 191 6.7OPS03 完备的测试验证体系 192 6.7.1OPS03-01推行开发者测试 192 6.7.2 OPS03-02 使用多个环境进行集成测试，构建和生产环境相同的预生产环境 192 6.7.3OPS03-03进行性能压测 193 6.7.4OPS03-04对生产环境进行拨测 193 6.7.5OPS03-05进行混沌测试和演练 194 6.8OPS04自动化构建和部署流程 195 6.8.1OPS04-01有效落地持续集成 195 6.8.2OPS04-02采用持续部署模型 195 6.8.3OPS04-03基础设施即代码 196 6.8.4OPS04-04自动化工程运维任务 196 6.9OPS05 运维准备和变更管理 197 6.9.1 OPS05-01 进行生产准备度评审（Product Readiness Review） 198 6.9.2OPS05-02进行变更风控 198 6.9.3OPS05-03定义变更流程 198 6.10 OPS06 可观测性体系 199 6.10.1OPS06-01建立可观测性体系 199 6.10.2 OPS06-02 定义可观测对象 200 6.10.3OPS06-03制定和实施可观测性指标 201 6.10.4OPS06-04规范化应用日志 202 6.10.5 OPS06-05 实施依赖项遥测 202 6.10.6OPS06-06 实施分布式跟踪 203 6.10.7OPS06-07通过可观测性指标引入自动化措施 203 6.11 OPS07 进行故障分析和管理 203 6.11.1 OPS07-01 创建可操作的告警 203 6.11.2 OPS07-02 创建监控看板 204 6.11.3OPS07-03 支持事件管理 204 6.11.4OPS07-04支持故障恢复流程 204 6.12OPS08度量运营状态和持续改进 205 6.12.1 OPS08-01 使用度量指标衡量运营目标 205 6.12.2 OPS08-02 进行事故复盘和改进 205 6.12.3OPS08-03知识管理 206 6.13参考案例 206 6.13.1 通过 AOM 助力系统运维能力提升，降低运维成本与难度 ..... 206 6.13.2 基于 LTS 采集多类端侧日志，问题全链路追踪分析和业务运营分析 ..... 207 6.13.3 LTS助力某公司高效完成日常业务运维与等保合规 208 6.14卓越运营云服务介绍 209 6.14.1 软件开发生产线(CodeArts) 209 6.14.2 资源编排服务(RFS) 210 6.14.3 云运维中心(COC) 210 6.14.4 云监控中心(CES) ..... 211 6.14.5 云日志服务(LTS) 212 6.14.6 应用运维管理(AOM2.0) 212 6.14.7 应用性能管理(APM) 213 6.14.8 云堡垒机(CBH) ..... 213 6.14.9 应用管理与运维平台(ServiceStage) 213 6.14.10 多活高可用(MAS) 213 # 卓越架构技术框架简介 卓越架构技术框架（Well-Architected Framework）聚焦客户业务上云后的关键问题的设计指导和最佳实践。 以华为公司和业界最佳实践为基础，以韧性、安全性、性能效率、成本优化与卓越运营五个架构关注点为支柱，打造领先的卓越架构技术框架，支撑客户完成云架构设计、云架构治理体系建设、研发生产力提升、现代化应用构建及运营运维体系建设等关键问题解决。 # 架构支柱 # - 韧性支柱： 旨在帮助企业构建具有高可用的应用系统架构，提高工作负载的韧性，使之在面对各种异常场景时仍能提供和维持可接受的服务水平。韧性支柱结合了华为公司韧性设计经验和业界最佳实践，总结并提炼出一系列设计原则与最佳实践，用以帮助企业利用华为云平台基础设施达到高可用、面向各种故障场景进行韧性设计，并具备一定的灾备能力；同时通过规范化变更、部署及应急恢复等处理流程，减少业务中断时长，提升可用性。 # - 安全性支柱： 旨在确保业务的安全、可信、合规，通过一系列华为云架构的最佳实践保护工作负载免受各种安全威胁，降低安全风险。安全性支柱涉及保护云上系统、资产、数据的机密性、完整性、可用性以及合法、合规使用数据，保护用户隐私的一系列最佳实践。 # 性能效率支柱： 聚焦于如何设计出高性能的架构。作为基本的质量属性，性能的重要性和性能失败后果的严重性是无须质疑的。性能效率支柱为性能设计、性能优化提供一些技术方法和手段，可以用于系统的软件性能工程，也可用于指导性能调整和优化。 # 成本优化支柱： 专注于帮助企业高效地使用云服务来构建工作负载，面向工作负载的整个生命周期不断完善和改进，减少不必要的开支并提升运营效率，让云上应用始终最具成本效益。成本优化支柱结合了华为公司云成本运营经验和业界最佳实践总结提炼出的体系化实践建议。 # 卓越运营支柱： 融合了这些优秀实践，聚焦如何正确地构建软件，高效地运维软件，持续提供卓越的客户体验，包含：组织团队、设计工作负载、大规模运营工作负载和随时间变化改进工作负载的最佳实践。 # 应用场景 # 云架构治理体系建设 云平台将虚拟化、数据库与中间件、大数据与AI等技术融合业界最佳实践，以托管云服务的方式提供企业使用。随着业务上云，企业将不受限于自身的技术能力使用先进IT技术，企业可以基于先进的云平台与WA方法论，构建现代化架构治理体系，使能组织、流程、工具和产品，让企业在数字化时代处于领先地位。 云架构治理体系不同于传统IT架构治理体系，通过现代化云平台及轻量化治理体系，使能业务安全、强韧性、资源高效、成本最优、敏捷创新。 # 云架构设计 由于云平台封装了底层软件技术的复杂度，让企业可以更聚焦业务应用设计。云架构设计鼓励以领域驱动设计(DDD)为架构设计起点，结合不同视角的架构视图，融入韧性、安全性、性能效率、成本和运营支柱，真正将云架构关注点融入到架构设计过程中。 # 云架构审视 随着业务需求和技术发展的变化，系统的架构也需要不断演进和优化。通过对照卓越架构技术框架的最佳实践，架构师对工作负载的架构进行全面、系统的评估，确保架构符合最新的需求、规范，符合最新的云上最佳实践。架构审视是一个持续的过程，建议在关键里程碑点进行审视或定期例行（如每半年一次）审视。 # 研发生产力提升 基于云的应用研发，技术、工具和工程实践都有很高的成熟度。业务上云后，基于云最佳实践升级工具链，改造研发流程，提升研发团队基于云的研发能力，引入先进的DevSecOps体系和确定性运维体系将大幅度提升企业的生产力，真正做到业务敏捷。基于华为公司20年的数字化实践和数百万企业客户的服务经验，华为云吸收业界先DevSecOps理念精华，提炼出DevSecOps质量效能管理体系典型特征，同时以价值流创造为核心，摸索出了一套行之有效的质量效能方法论和最佳实践。 # 构建高韧性、高可用的应用程序 华为公司结合内部韧性设计经验和业界最佳实践，总结并提炼出一系列体系化设计原则与最佳实践： - 帮助客户利用华为云平台基础设施达到高可用、面向各种失败场景进行设计，并具备一定的灾备能力。 - 通过规范化变更、部署及应急恢复等处理流程，减少业务中断时长，提升可用性。 # 安全合规体系建设 云安全已经成为多维度的全球性挑战，华为云卓越架构技术框架结合业界先进的云安全理念和积累的网络安全经验和优势，参考世界领先的CSP优秀安全实践、摸索出了一整套行之有效的云安全战略和实践。并且已经构建起多维立体、纵深防御和合规遵从的基础设施架构，用以支撑并不断完善涵盖了IaaS、PaaS和SaaS等具有优良安全功能的常用云服务。 # - 确定性运维体系建设 IT运维行业正在面临着颠覆性的变化，我们正在从保障设备稳定的防守型运维转向支撑业务敏捷的进攻型运维，从关注自身网络转向关注客户应用，从系统维护工程师转向研发工程师，这个转型的过程对运维提出艰巨挑战的同时，也给每个组织和个人提供了难得的发展机会。华为云SRE过去构建了一些能力，也还在持续解决新的挑战，我们已经构建了一套质量管理机制、一套运维平台、一支全球专家队伍，更重要的是，我们已经和很多客户一起开展了面向应用视角的稳定性提 升工作，助力客户提升应用稳定性，从应用层到平台底层，在成本、质量、效率中寻找最优方案。 # 云财务体系(FinOps)建设 FinOps是“Finance”和“DevOps”的结合，目的是解决企业管理云成本难题。FinOps基金会将FinOps定义为“不断发展的云财务管理纪律和文化实践，通过帮助工程、财务、技术和业务团队在数据驱动的支出决策上进行协作，使组织获得最大的业务价值”。企业云资源消费贯穿用云的整个过程，管理云成本也需要持续迭代优化。 - FinOps框架提出三阶段(可视、优化、持续运营)实践模型，指导企业持续优化。在优化时，FinOps指导企业找到成本、质量与效率的平衡，避免企业为了极低成本导致业务效率和稳定性受影响。在一个公司内部业务团队众多，各团队实践FinOps进展不一，不同团队可能处于不同的阶段。FinOps指导企业通过多团队协作和基于数据决策，精细化管理云成本。各业务团队成本可视，主动控制不超支不浪费；企业基于数据决策云投资，保障企业核心业务和战略业务方向的支出。企业应用FinOps后，持续降低单位业务成本。 # 应用优化 当前，企业大量的存量应用逐渐成为业务发展的阻碍，老旧、复杂、僵化的系统难以更新，昂贵的基础设施维护成本高，繁杂的部署过程也给发布加上了沉重的枷锁，导致发布缓慢，现有的架构和技术无法很好地适应现代软件开发，这些问题都对企业的发展带来新的挑战。但对于大多数企业来说，这些应用仍然是公司价值链的重要组成部分，为企业提供核心功能和数据。对负责存量应用处理的开发和运营人员来说，同样面临诸多挑战：日益复杂的IT环境、不断增加的“技术债务”、有限的技能以及安全风险等，这些问题都将成为企业无法快速创新和实现业务目标的潜在风险。 卓越架构技术框架（Well-Architected Framework）将为企业提供优化建议，企业结合实施策略，有选择有节奏的优化应用，以提升存量应用的韧性、安全性、性能及资源利用率，适应现代化软件开发，降低运营成本。 # - 伙伴能力标签认证 华为云合作伙伴能力标签（简称能力标签）是华为云合作伙伴达到能力标准后获得的标识，华为云定义并维护能力标签的全集。 合作伙伴通过学习卓越架构技术框架（Well-Architected Framework），理解并参考各支柱的云上最佳实践，以获取更专业的云架构设计知识。在构建解决方案或给客户提供专业服务的过程中，合作伙伴应用这些最佳实践，持续提升架构设计质量、持续完善工作负载。合作伙伴提交实际的客户案例并经过华为云审核通过后，可获得相应领域、场景或行业的能力标签认证。 # 2 韧性支柱 # 2.1 韧性支柱简介 韧性支柱旨在帮助企业构建具有高可用的应用系统架构，提高工作负载的韧性，使之在面对各种异常场景时仍能提供和维持可接受的服务水平。韧性支柱结合了华为公司韧性设计经验和业界最佳实践，总结并提炼出一系列设计原则与最佳实践，用以帮助企业利用华为云平台基础设施达到高可用、面向各种故障场景进行韧性设计，并具备一定的灾备能力；同时通过规范化变更、部署及应急恢复等处理流程，减少业务中断时长，提升可用性。 华为云韧性支柱的设计框架如下图所示： # 2.2 基本概念 # 2.2.1 概念表 <table><tr><td>概念</td><td>解释</td></tr><tr><td>韧性(Resilience)</td><td>系统从故障中保持在已知运行状态（甚至降级）的能力。在遭遇故障后快速恢复核心功能和数据，且在业务需要的时间窗内恢复到有效运行状态。</td></tr><tr><td>可靠性(Reliability)</td><td>产品在规定的条件下和规定的时间内完成规定功能的能力。它的概率度量称为可靠度。</td></tr><tr><td>可用性(Availability)</td><td>产品在任意随机时刻需要和开始执行任务时，处于可工作或可使用状态的程度。它的概率度量称为可用度</td></tr><tr><td>云服务指标SLI</td><td>Service level Indicator，面向服务的指标，如：请求响应成功率</td></tr><tr><td>云服务目标SLO</td><td>Service Level Object，面向服务的目标，如：一定时间范围内的请求响应成功率大于XX%，或正常运行时间的百分比</td></tr><tr><td>云服务协议等级SLA</td><td>Service Level Agreement，面向用户的协议等级，涉及不满足时的补偿</td></tr><tr><td>数据恢复点目标RPO</td><td>Recovery Point Objective，主要指的是业务系统所能容忍的数据丢失量</td></tr><tr><td>恢复时间目标RTO</td><td>Recovery Time Objective，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。</td></tr></table> 业界对韧性没有统一的定义。狭义韧性，指的是自动或快速从故障中恢复运行的能力；而广义韧性，除了从故障中恢复运行的能力外，还包括故障容忍能力。 故障容忍（fault tolerance，简称“容错”），是使系统在其某些组件中出现一个或多个故障时能够继续提供服务的能力，从客户的角度来看，该服务仍能完全正常运行，或可能降级运行。 而可靠性同样分为狭义可靠性与广义可靠性。狭义可靠性工程的目标是提高系统无故障运行的能力，即提高可靠性。而广义可靠性工程的目标除了提高可靠性外，还包括提高从故障中恢复运行能力，即维修性（maintainability），同时还包括其他围绕故障展开的各种能力，如可用性（availability）、保障性（supportability）等。 因此，从广义韧性与广义可靠性的定义来看，并没有显著区别。只是可靠性和韧性的侧重点不同。可靠性工程的目标是尽可能减少系统中的故障，保证系统无故障运行。而韧性工程，接受故障总会发生的现实，关注的是如何降低故障带来的损失以及如何从故障中恢复。 # 2.2.2 什么是应用韧性 应用韧性是应用系统在运行过程中面对各种异常场景，如基础设施故障（如数据库异常）、外部攻击（如网络DDoS攻击超出预定限额流量）、外部依赖故障（如依赖系统访问超时或不可用）、地域灾难（如大面积停电、洪水）等，仍能提供和维持可接受的服务水平的能力，对系统至关重要。 系统韧性设计主要涉及以下两个方面： - 确保系统具有高可用的架构，如无单点故障 - 各种故障场景下的恢复能力，如数据丢失、设备或站点故障等场景均能恢复 相对于传统数据中心，华为云可以提供具备高可用、弹性伸缩、自动备份、跨AZ容灾、跨Region容灾等高可用能力的基础设施与云服务，便于客户构建高可靠的系统。例如： - EVS云硬盘、OBS对象存储采用分布式存储，可避免单个硬盘、单个服务器或单个机架等硬件故障的影响。 RDS数据库提供自动数据备份、跨AZ和跨Region的数据复制与切换。 不过，即使应用系统利用云平台能力具有了这些高可用能力，要实现较高的可用性，仍需要构建针对各种偶发故障下的恢复能力，如： - 由于硬件故障导致的高可用切换或跨AZ切换过程中，导致瞬时链接中断，需要应用系统具备链接中断重试的功能。 - 由于外部流量突发导致业务过载，需要应用系统具备流量控制的能力。 - 部分强依赖于硬件的负载，如依赖本地硬盘、GPU等，由于硬件故障导致服务中断，需要应用系统自身构建高可用的能力。 不同的应用系统，可用性要求可能不同，采用的韧性恢复方案会有差异。 # 2.2.3 责任共担模式 云上应用系统的韧性，依赖于云基础设施及应用系统本身的韧性，任何一方故障，都可能会导致云上应用系统故障；因此需要华为云与客户共同承担责任，来保障应用系统的韧性。 - 华为云责任：华为云提供高可用的基础设施，包括运行华为云服务的硬件、软件和机房设施，并确保服务可用性满足SLA服务等级协议。 - 客户责任：客户可以从华为云选择合适的产品并进行可靠性配置以符合应用韧性目标，并参考本白皮书中的设计原则与最佳实践，充分考虑各种异常场景的检测和恢复能力，来构建高可用应用系统。 # 2.2.4 可用性目标定义 # 2.2.4.1 可用度及SLO 可用性是衡量可靠性和韧性的综合性指标。 可用性目标用于衡量应用系统的运行时间和停机时间，其表现形式为应用系统正常运行的时间占总时间（通常是一个月或一年）的百分比（如 $99.9\%$ ），即： 可用度 = 可用时间 / 总时间 * 100% 常见的简单表达方式用“9”的数量或“9”的数量加“5”表示，如“三个9”表示“99.9%”，而“三个9一个5”表示“99.95%”。 系统可用性目标通过服务等级目标（SLO）定义。不同的应用系统对可用性目标是不同的，明确应用系统的可用性目标，对于衡量应用系统的韧性至关重要。常见IT系统SLO示意如下： <table><tr><td>SLO</td><td>每年最大不可用时间</td><td>典型IT服务</td></tr><tr><td>99%</td><td>3.65天</td><td>批处理，后台任务，数据抽取</td></tr><tr><td>99.9%</td><td>8.76小时</td><td>内部知识管理系统，项目跟踪系统</td></tr><tr><td>99.95%</td><td>4.38小时</td><td>客户账户管理，信息管理</td></tr><tr><td>99.99%</td><td>52.56分钟</td><td>电商，B2B web服务，大流量媒体/内容网站</td></tr><tr><td>99.999%</td><td>5.26分钟</td><td>银行，投资，金融，政府，电信，关键企业应用</td></tr></table> 系统的可用度依赖于系统内各业务单元的可用度。各业务单元之间典型的可靠性模型有两类： - 串联模型：组成系统的所有单元中任一单元的故障都会导致整个系统故障的称为串联系统。 $$ R _ {S} = \prod_ {i = 1} ^ {n} R _ {i} $$ 可靠性数学模型： 举例：假定系统存在2个串联单元，每个单元的可用度均为 $99.9\%$ ，则系统可用度为 $\mathrm{Rs} = 99.9\% * 99.9\% = 99.8\%$ 。 串联系统中系统可用度低于串联系统中任一单元的可用度。为提高系统可用度，设计时需考虑： - 尽可能减少串联单元数目 提高单元可靠性，降低其故障率 - 并联模型：组成系统的所有单元都发生故障时，系统才发生故障的成为并联系统。 $$ R _ {P} = 1 - \prod_ {i = 1} ^ {n} \left(1 - R _ {i}\right) $$ 可靠性数学模型： 举例：假定系统存在2个并联单元，每个单元的可用度均为 $99.9\%$ ，则系统可用度为 $\mathrm{Rs} = 1 - (1 - 99.9\%) * (1 - 99.9\%) = 99.9999\%$ 。 并联可显著提高系统可用度，典型的并联技术有：主备、集群、双活或多活等。 应用系统要达到可用性目标，需对应用系统内组件及依赖组件进行可用性要求分解，包括： - 对依赖组件的可用性要求：通常关键依赖组件需要比其他服务提高一个9的SLO目标，如应用系统SLO目标为 $99.9\%$ ，则关键依赖组件SLO目标要求达到 $99.99\%$ 。 - 应用系统SLO分解：综合系统SLO、故障频次、云服务SLA，分解得出应用组件的中断时长要求，进一步分解得出故障检测、人工介入、干预恢复的时长要求。 - 针对应用系统内薄弱环节进行增强： - 当云服务SLA无法满足要求时，需要应用层进行额外的保护和增强。 - 通过冗余提升可用度：包括组件冗余（负载均衡集群），故障回退冗余（fail-back，例如使用DMS访问失败时暂时切换到SMN）。 # 2.2.4.2 RTO与RPO 灾难场景通常采用RTO和RPO目标定义： - 恢复时间目标RTO：指灾难发生后应用不可用的最长时间。RTO决定了应用容灾整体架构，是采用数据备份，还是冷备、温备、热备。 - 恢复点目标RPO：指灾难发生后应用数据丢失的最大时间。RPO决定了数据备份频率或复制方式，是在线备份还是离线备份，是同步复制还是异步复制。 国家标准《信息系统灾难恢复规范》（GB/T20988-2007）中灾难恢复等级与RTO/RPO的关系如下： <table><tr><td>灾难恢复能力等级</td><td>能力要求</td><td>RTO</td><td>RPO</td></tr><tr><td>1</td><td>基本支持：基本支持备份介质并场外存放</td><td>2天以上</td><td>1天至7天</td></tr><tr><td>2</td><td>备用场地支持：有备份场地，能调配所有资源</td><td>24小时以上</td><td>1天至7天</td></tr><tr><td>3</td><td>电子传输和设备支持：关键数据定时传送，备用网络部分就绪</td><td>12小时以上</td><td>数小时至1天</td></tr><tr><td>4</td><td>电子传输及完整设备支持：少量数据丢失，备用数据系统就绪，数据定时传送，备用网络就绪</td><td>数小时至2天</td><td>数小时至1天</td></tr><tr><td>5</td><td>实时数据传输及完整设备支持：数据丢失趋于0，备用数据系统就绪，远程数据复制，备用网络就绪</td><td>数分钟至2天</td><td>0至30分钟</td></tr><tr><td>6</td><td>数据零丢失和远程集群支持：数据零丢失，自动系统故障切换，远程磁盘镜像，备用网络active</td><td>数分钟</td><td>0</td></tr></table> # 2.2.4.3 数据持久度 数据持久度是指数据不丢失的概率，即存储在预计周期内不出现数据丢失的概率，可以用于度量一个存储系统的可靠性。其只表示数据是否丢失的概率，不体现数据丢失多少；数据持久度的预计周期，一般按一年进行预计。 影响存储数据持久度的主要因子有：冗余数、磁盘失效率与数据修复时间。其中每多一个冗余，数据持久度通常可增加2~3个9；云上常用的对象存储，一般采用3副本冗余，通常可提供11~12个9的数据持久度。 # 2.2.5 可用性需求 根据“常见IT系统SLO示意”中的表格可以得知，不同的IT系统，SLO目标是存在差异的，不是所有的应用系统都需要达到最高可用性要求。 当系统可用性目标要求升高时，所需的成本也通常会增加，因此在可用性目标制定时，需要对韧性与成本进行权衡，确定真正的可用性需求。 在系统的可用性目标明确后，可参考以下韧性最佳实践来优化系统，使之满足可用性目标要求。 # 2.3 设计原则 由于故障不可避免，如硬件故障、软件错误、网络延迟、突发流量等，因此在设计高可用应用系统时，必须考虑所有的硬件及系统包括的软件都可能会失效，包括IaaS、PaaS、SaaS及应用系统本身。韧性设计的目标不是试图防止这些故障的发生，而是为了在这些故障发生时，能最大程度地减轻故障对系统造成的影响，并持续稳定地运行，建议遵循以下设计原则。 # 高可用设计 单点故障会导致整个系统崩溃、主要功能受到影响、任务延误的系统轻度损坏或存在较大的故障隐患，因此系统的高可用设计非常关键。 高可用设计的主要手段是冗余，甚至是多级冗余的组合，包括异地容灾方式保证灾难情况下无单点： - 冗余机制：只要条件允许，需要考虑关键组件的冗余，甚至是多级冗余的组合（例如：1+1冗余、n+1冗余、N-Way冗余等） - 异地容灾：例如，两地三中心，保证灾难的情况也可以提供业务。 - 数据冗余：可以通过定期备份和多副本备份等方式实现以提高数持久度，并确保数据一致性。 冗余的增加，意味着成本的增加；因此在应用高可用设计时需要综合考虑冗余对成本的影响。 # 故障全面检测 故障检测是故障管理的前提，检测全面与检测快速都很重要，通常情况下故障检测全比故障检测快重要。 故障检测涉及以下方面： - 检测范围：识别并跟踪检测所有组件，有重大影响的故障模式需要重点检测。 - 亚健康检测：对不引起系统故障却导致系统或服务KPI下降的亚健康异常需要能检测，如网络时延变大、磁盘变慢、内存泄露等亚健康故障。 - 备用检测：冗余系统中，主备用模块的故障都需要检测，避免静默故障。 - 有特殊寿命器件：应及时监控有特殊寿命（如本地硬盘）要求的期间健康状态，通过提前预警采取维护错误，避免故障的突然发生造成严重影响。 - 检测速度：需要根据业务综合要求，确定合适的检测速度。 - 检测影响：故障定时检测的周期，需综合考虑对CPU占用率的影响和检测延迟对业务恢复速度的影响。 - 检测模块要简单：故障检测系统、模块要比被检测系统、模块简单。 在检测到问题后，需要通过监控系统及时发现，迅速处理。 # 故障快速恢复 故障恢复指恢复产品执行规定功能的能力，一般情况下恢复越快影响越小。 结合业务情况，综合考虑技术实现难度、技术方案复杂度、成本等设计合适的故障恢复方案： - 自动恢复：对于影响业务的故障，系统应尽可能自动恢复自愈，如保护倒换、局部复位或系统服务等。 - 优先恢复：优先对故障发生概率高、故障影响大的故障进行恢复。 - 分级复位：提供分级复位设计，尽可能在更小级别进行复位，以减少对业务的影响。 - 无耦合恢复：尽可能做到系统局部故障或各部件启动顺序不影响系统成功启动。 - 分层保护：系统故障保护要考虑网络分层，下层的故障保护倒换要比上层灵敏，防止系统出现乒乓倒换。 通过检测系统运行状态，或监控系统在关键指标，来判断系统是否发生故障，并针对故障可进行自动恢复处理。 可以通过故障分析方法分析各种故障模式、影响及危害，设计对应的可靠可用方案，提供冗余、隔离、降级、弹性等能力；并通过故障注入测试（FIT）验证可靠可用方案的有效性，最大程度提高业务的可靠性和可用性。 对于某些故障，即使通过各种技术手段进行冗余和自动恢复处理，但仍会导致业务中断，需要人工干预，如备份恢复或灾难恢复处理，因此需要建立高效的故障应急恢复处理流程和平台，以便在故障发生时，能快速恢复业务，减少故障影响。 # 过载控制 在系统请求超过系统容量时，会由于资源饱和而导致系统请求失败，在云中，可以监控系统和工作负载的利用率，来自动添加或删除资源，以维持最佳级别来满足业务需求，而无需过度配置或配置不足。 控制业务流量一般通过动态资源管理来实现，不建议简单地使用静态门限来达到防过载的目的，有可能造成资源大量浪费，过载设计应该考虑以下方面： - 动态限流：根据系统资源消耗情况动态调整流控门限。 - 弹性扩缩容：自动检测系统资源利用率，自动进行添加或删除资源。 先负载均衡后流控：多个并行处理单元场景下，优先考虑负载均衡，避免单个处理单元资源受限导致业务受损；然后进行过载控制保护，使得整个系统的处理能力最大化。 - 及早控制：系统过载时，应尽可能在业务流程处理前端或业务处理较早的处理模块或底层协议层次上控制业务接入，避免中间控制带来不必要的性能消耗。 - 优先级保障：系统过载时保证高优先级的业务能够优先获得资源，优先得到处理，从而保证社会效益最大化。 # 变更防差错 当对系统进行升级部署、配置变更时，需要防止变更过程中由于人因差错导致系统和业务受损或失效。 通常采用防呆的方式来减少人因差错。防呆是一种预防矫正的行为约束手段，运用防止错误发生的限制方法，让操作者不需要花费注意力、也不需要经验与专业知识，凭借直觉就可准确无误地完成操作，在许多场景下可以提升效率和使用体验，也防止损坏更换的成本，因此优良的产品中防呆设计极为基础而普遍。 变更防差错通常采用以下方案： - 角色约束：通过权限控制设计预防对不同角色的配置范围进行约束，避免越权配置导致错误。 - 查改分离：通过产品界面设计将配置界面分层分级，查看与修改分离等降低人为配置失误风险。 - 配置校验：通过配置生效机制设计确保在配置生效前进行必要的检查，避免错误配置生效。通过使用自动化方式进行配置变更处理，可减少人因输入错误的可能。 - 删除保护：在删除资源时增加保护机制，防止误删，如：删除前运行状态检查保护，资源锁定防止误删除，回收站机制等。 # 2.4 问题和检查项 企业在进行应用韧性设计的过程中，推荐使用如下问题寻找自身可以改进的点，并参考检查项/最佳实践进行改进，以下所有检查项，也是最佳实践建议，将在下一章节进行详细描述。 <table><tr><td>问题</td><td>检查项/最佳实践</td></tr><tr><td>RES01您如何使用冗余技术确保应用系统的高可用?</td><td>1. 应用组件高可用部署2. 应用组件多位置部署3. 云服务器反亲和</td></tr><tr><td>RES02您如何备份应用程序中的关键数据?</td><td>1. 识别和备份应用中所有需要备份的关键数据2. 自动数据备份3. 定期进行备份数据恢复</td></tr><tr><td>RES03您如何对应用程序进行跨AZ灾难恢复?</td><td>1. 集群跨AZ部署2. 跨AZ数据同步3. 对接容灾仲裁,支持自动切换4. 支持容灾管理</td></tr><tr><td>RES04您如何对应用程序进行跨Region或跨云灾难恢复?</td><td>1. 定义应用系统的容灾目标RPO与RTO2. 部署容灾系统以满足容灾目标3. 容灾恢复过程自动化4. 定期进行容灾演练,以检查恢复能否满足容灾目标</td></tr><tr><td>RES05您如何保证网络高可用?</td><td>1. 网络连接高可用2. 避免暴露不必要的网络地址3. 不同流量模型业务的网络共享带宽隔离4. 预留IP资源以便扩展和高可用</td></tr><tr><td>RES06您如何进行故障检测处理?</td><td>1. 故障模式分析2. 面向所有故障进行检测3. 支持亚健康检测</td></tr><tr><td>RES07您如何监控应用系统资源?</td><td>1. 定义关键指标与阈值并监控2. 日志统计监控3. 监控到异常后发送消息通知4. 监控数据存储和分析5. 端到端跟踪请求消息</td></tr><tr><td>RES08您如何减少依赖影响?</td><td>1. 减少强依赖项2. 依赖采用松耦合3. 减少被依赖项故障的影响</td></tr><tr><td>RES09您如何进行重试?</td><td>1. API以及命令调用需要设计为可重试2. 客户端需要根据综合评估是否需要重试3. 重试需要避免造成流量压力</td></tr><tr><td>RES10您如何进行故障隔离?</td><td>1. 应用控制平面与数据平面隔离2. 应用系统多位置部署3. 采用Grid架构4. 健康检查与自动隔离</td></tr><tr><td>RES011您如何进行可靠性测试?</td><td>1. 混沌测试2. 压力负载测试3. 长稳测试4. 灾难演练5. 红蓝攻防</td></tr><tr><td>RES012您如何进行应急恢复处理?</td><td>1. 组建应急恢复团队2. 制定应急预案3. 定期应急恢复演练4. 出现问题后尽快恢复业务5. 应急恢复回溯</td></tr><tr><td>RES013您如何进行过载保护以适应流量变化?</td><td>1. 采用自动弹性扩缩容2. 应用系统负载均衡,避免流量不均匀3. 过载检测与流量控制4. 支持主动扩容5. 资源自动扩容考虑了配额限制6. 压力负载测试</td></tr><tr><td>RES14您如何进行配置防差错?</td><td>1. 变更防呆检查2. 自动化变更3. 变更前数据备份4. 提供runbook进行标准化变更</td></tr><tr><td>RES15您如何进行升级不中断业务?</td><td>1. 自动化部署和升级2. 自动化检查3. 自动化回滚4. 灰度部署和升级</td></tr></table> # 2.5 高可用设计 # 2.5.1 RES01 冗余 # 2.5.1.1 概述 具有高可用的系统必须避免单点故障，以防由于某个节点故障而导致整个系统不可用。 本节操作介绍冗余设计方案来消除单点故障，提高可用性。 # 2.5.1.2 RES01-01 应用组件高可用部署 应用系统内的所有组件均需要高可用部署，避免单点故障。 风险等级 高 关键策略 应用系统内各组件需要根据其具体能力，采用不同的高可用部署方案： - 使用原生高可用实例：当云服务既支持单节点资源，又支持主备或集群资源时，应用的关键节点应使用主备或集群资源，如CCE高可用集群、RDS主备实例、DDS集群、DCS主备或集群实例等。对于运行在CCE集群上的工作负载，也需要配置多个，以避免单个节点故障就导致业务中断。 单节点实例通过多实例实现高可用：当云服务只支持单节点发放，则需要应用层来实现多个节点之间的主备或负载均衡，如ECS实例，用户可以通过构建ELB+多ECS实例，来实现无状态业务在多实例之间的负载均衡和自动切换，或从应用层实现两个ECS实例的主备等。 - 硬件依赖实例从应用层实现高可用：当ECS使用本地硬盘、直通FPGA、直通IB网卡等物理服务器强相关的硬件资源时，当硬件故障时会导致ECS故障，且无法通过虚拟机HA功能自动恢复；针对此类问题，需要应用系统在设计时就必须要预料到偶发故障，尽可能避免使用，若必须用时需要从应用层来实现高可用，以便在所依赖的硬件故障时业务能快速恢复。 - 虚拟机HA：当ECS不依赖于特殊资源时，可以支持虚拟机故障自动恢复功能，在其所在物理服务器故障的情况下，可以自动在其他物理服务器上重启；对于部署在这种ECS中的工作负载，需要支持虚拟机重启后业务自动恢复的功能，并能容忍虚拟机HA期间业务处理性能短暂下降或中断。 对已部署的应用系统，改造为支持高可用能力的实施步骤： a. 确定应用系统的关键组件; 所谓关键组件是指一旦故障, 会导致整个应用系统或其中的关键功能受损。 b. 针对关键组件，检查其高可用能力，即在其故障的情况下，是否能自动故障转移，进行业务恢复。 c. 针对未支持高可用的关键组件，进行如下优化处理： - 若云服务实例为单节点实例，如ECS，则通过申请多个实例承载相同业务，并利用ELB实现负载均衡和自动故障切换，或由应用层实现多实例的自动故障切换能力，来实现高可用。 - 对于不依赖于特殊资源的ECS，支持故障自动恢复功能，在ECS所在物理服务器故障的情况下可以自动在其他物理服务器上重启；对于部署在这种ECS中的工作负载，需要检查ECS重启后业务是否能自动恢复。 - 对于依赖特殊资源的ECS，如本地盘、直通FPGA卡、直通IB卡等，不支持故障自动恢复，针对此类ECS需要检查是否可以替换为不依赖于这些特殊资源的 ECS，以提高ECS的可用性。 - 对于ECS、BMS、MRS等实例，在使用本地盘时，由于磁盘存在使用寿命上的限制，长时间使用后出现故障的概率会比较高，需要避免使用，而尽可能使用具有高可用能力的EVS磁盘；若必须使用时，则建议使用RAID提升本地盘的可用性，并从应用层实现高可用，以便在一个实例故障时，应用可以自动故障切换和恢复业务。 # 相关云服务和工具 弹性云服务器 ECS 裸金属服务器BMS 弹性负载均衡ELB - 云容器引擎CCE 文档数据库服务 DDS 分布式缓存服务 DCS MapReduce服务 MRS # 2.5.1.3 RES01-02 应用组件多位置部署 应用组件需要部署在多个数据中心，以避免单个数据中心故障而导致业务中断。 # 风险等级 高 # 关键策略 可根据不同需求，将应用的数据和资源部署在多个位置： - 应用多AZ部署：应用应尽可能部署在多个可用区，避免由于单个可用区故障而导致所有业务中断。 - 应用多Region部署：对于可用性要求高的应用系统，需要考虑多Region部署，避免由于单个Region故障而导致所有业务中断。 - 在多AZ部署能满足需求的情况下，应优先使用多AZ部署。大多数工作负载的可用性目标都可通过在单个Region内多AZ部署来实现，只有工作负载具有极高的可用性要求或者其他业务目标时，才考虑多Region架构。 # 2.5.1.4 RES01-03 云服务器反亲和 应用内相同业务的ECS需要分散到多台物理服务器，避免运行到同一台物理服务器上，当发生这种情况时，可能会由于一台物理服务器故障而导致业务中断。 # 风险等级 高 # 关键策略 - 针对多个承载相同业务的ECS，需要配置主机组反亲和，从而可以将相同业务的ECS调度到不同物理服务器上，以避免由于单台物理服务器故障而导致所有业务不可用的场景。 - 若ECS通过AS进行弹性伸缩时，则需要AS配置云服务器组反亲和，以避免AS自动创建的ECS运行在同一个物理服务器上。 - 若CCE集群节点或节点池采用弹性云服务器ECS时，建议配置云服务器组反亲和，以避免CCE集群中的ECS节点运行在同一个物理服务器上。 # 相关云服务和工具 - 弹性云服务器 ECS：云服务器组 弹性伸缩服务AS 云容器引擎CCE # 2.5.2 RES02 备份 # 2.5.2.1 概述 对于应用系统中的重要数据，需要提供备份功能，以便在病毒入侵、人为误删除、软硬件故障等场景，能够快速将数据恢复到备份点。 由于容灾通常对数据采用实时复制且没有多备份点，在主数据被误删或误改的情况下，错误数据会同步到备端，从而无法达到数据备份的效果，因此通常不能使用容灾来代替备份。 备份恢复时的RPO指标（即数据丢失量），与最近一个备份时间点相关；不同类型的数据，允许丢失数据量可以不同，即RPO不同；为了保证数据备份的RPO目标，需要采用定期自动备份，而不要依赖人工进行手工备份。 # 2.5.2.2 RES02-01 识别和备份应用中所有需要备份的关键数据 不同数据的重要性不一样，针对应用系统内的所有数据，需要明确其重要性及对应的RPO/RTO指标要求。比如对于重要数据，通常允许数据丢失的时间会比较少，从而需要更频繁的备份；对于一般的数据，允许数据丢失的时间比较长，可以使用较低的备份频率；对于一些不重要的数据，其数据丢失对业务没有影响，则不需要进行备份。 # 风险等级 高 # 关键策略 - 识别应用系统中的所有数据。数据可以存储在多种资源中，如ECS/BMS中的卷、RDS/DDS等数据库、SFS文件系统、OBS对象存储等。 - 根据重要性对数据进行分类。应用系统内的不同数据具有不同的重要程度，对备份的要求也不同；如对一些重要数据，RPO要求接近0，需要实时备份；而对另外一些数据，重要性不高，可以容忍数据丢失，可以不做备份；此外还存在一些比较重要的数据，数据丢失的容忍程度各有不同，需要设计不同的备份策略。 - 针对需要备份的数据设计备份方案以满足其RPO/RTO指标要求。 # 2.5.2.3 RES02-02 自动数据备份 对于需要备份的数据，可根据该数据的RPO指标要求，设置定期备份策略进行自动备份。 # 风险等级 高 # 关键策略 使用华为云备份服务或第三方备份软件对数据进行备份，并可根据RPO要求设置自动备份频率。CBR云备份服务可对ECS/BMS/EVS/SFS Turbo以及文件目录等进行备份；大多数云服务，如RDS、DDS、DCS等具备原生的创建备份功能；云商店也有不少备份软件可以支持各种数据的备份。 华为云云服务提供了备份工作负载数据的功能，典型的备份有： - 云备份CBR服务：CBR提供对磁盘（EVS）、服务器（ECS、Flexus、BMS）基于快照的备份和恢复能力，SFS Turbo文件系统备份，云服务器部署的MySQL或SAP HANA等数据库备份，以及混合云备份。CBR支持一次性备份和周期性备份两种配置方式。目前备份时间只支持整点，可以同时选择多个整点进行备份，即最小RPO=1小时，用户需要根据数据重要性选择合适的备份周期。 - 数据库自动备份：RDS、DDS、GaussDB等数据库服务提供了缺省自动备份功能，实例每5分钟自动进行一次增量备份，以保证数据库的可靠性。 - DCS备份：DCS服务针对非单机实例提供了自动备份和手工备份功能，建议设置自动备份策略进行备份。 此外，用户也可使用第三方备份软件进行备份。 华为云中云服务的数据备份到OBS存储中，可高度保障用户的备份数据安全。 # 相关云服务和工具 云备份CBR - 云数据库RDS 分布式缓存服务 DCS # 2.5.2.4 RES02-03 定期进行备份数据恢复 通过定期恢复测试，可以验证备份数据的完整性与恢复处理过程是否可用，且数据丢失时间以及恢复时间符合数据的RPO与RTO指标要求。 # 风险等级 高 # 关键策略 定期执行备份数据恢复，以验证备份的完整性。 - 为了避免备份恢复对生产业务造成影响，可以构建一个测试环境，并使用已有的备份数据进行恢复处理。 华为云云服务提供了手工恢复功能，用户可定期执行恢复操作，以进行恢复测试。 # 相关云服务和工具 云备份CBR - 云数据库RDS 分布式缓存服务 DCS # 2.5.3 RES03 跨AZ容灾 # 2.5.3.1 概述 为了预防单可用区故障，可借助华为云多可用区（Availability Zone，简称AZ）能力，应用可以用较小成本来完成容灾架构部署。 应用系统可设计为使用分布在多个可用区中的资源池，并利用云服务实例本身具备或应用自身支持的跨AZ数据复制与切换能力， 在多个AZ之间复制数据、负载均衡和跨AZ故障切换，从而使应用系统具备应对可用区故障的能力。 # 2.5.3.2 RES03-01 集群跨AZ部署 应用内所有组件均采用跨AZ容灾部署，以避免单AZ故障时业务中断。 # 风险等级 高 # 关键策略 - 云服务实例具备跨AZ高可用实例时，优先使用云服务实例自身的跨AZ高可用实例。 - 云服务实例只支持发放单AZ实例，不支持跨AZ高可用实例时，需要借助其他云服务或应用层实现跨AZ容灾；以ECS为例： 对于无状态ECS实例，可利用AS弹性伸缩服务的跨AZ伸缩能力，或ELB跨AZ负载均衡能力，实现跨AZ高可用，在一个可用区故障时能自动快速切换。 对于有状态ECS实例，或BMS实例，建议从应用层实现跨AZ容灾，支持跨AZ自动切换或通过容灾管理工具实现自动化容灾切换，减少灾难发生时的人工操作。 对于已部署的应用系统改造为跨AZ实例的实施步骤： a. 确定应用系统的关键组件; 所谓关键组件是指一旦故障, 会导致整个应用系统或其中的关键功能受损。 b. 针对关键组件，检查其跨AZ高可用能力，即在一个AZ故障的情况下，是否能自动故障转移到另外一个AZ，进行业务恢复。 c. 针对未支持跨AZ高可用的关键组件，可进行如下优化处理： - 若云服务实例支持跨AZ高可用实例且支持由单AZ高可用实例改造为跨AZ高可用实例，如RDS、DDS、DCS实例，则直接原地由单AZ实例改造为跨AZ实例； - 若云服务实例支持跨AZ高可用实例但不支持由单AZ高可用实例改造为跨AZ高可用实例，如独享ELB、CCE集群、DMS、OBS桶等，则需要新申请跨AZ高可用实例替换原来的单AZ高可用实例。 - 若云服务实例为单节点实例，如ECS，则通过申请多个AZ的多个实例承载相同业务，并利用跨AZ的ELB实现跨AZ的负载均衡和自动故障切换，或由应用层实现跨AZ多实例的自动故障切换能力，来实现跨AZ高可用。 # 相关云服务和工具 华为云大部分云服务支持创建多可用区实例，可实现在一个可用区故障时能自动快速切换，不影响实例对外提供服务，如ELB负载均衡、AS弹性伸缩、CCE容器集群、DCS实例、DMS消息服务、RDS数据库、GaussDB数据库等。 # 2.5.3.3 RES03-02跨AZ数据同步 针对有状态业务，需要进行跨AZ的数据同步，以便在一个AZ故障的情况下，数据不丢失；对于无状态业务不涉及。 # 风险等级 高 # 关键策略 - 当应用组件对应的云服务实例支持跨AZ高可用实例时，可采用云服务实例自身的跨AZ数据同步；如RDS数据库、DCS实例、OBS桶等。 - 当应用组件对应的云服务实例不支持跨AZ高可用实例，但提供了同步服务进行跨AZ数据同步时，可利用该服务进行跨AZ数据同步；如存在有状态数据的 ECS实例不支持跨AZ高可用，但可通过SDRS服务进行跨AZ数据同步。 - 当应用组件对应的云服务实例不支持跨AZ高可用实例，且不支持跨AZ数据同步或不使用跨AZ数据同步服务时，则需要由应用层进行数据复制；如存在有状态数据的BMS实例。 # 相关云服务和工具 - 存储容灾服务SDRS 弹性云服务器 ECS - 云数据库RDS 分布式缓存服务 DCS - 对象存储服务 OBS # 2.5.3.4 RES03-03 对接容灾仲裁，支持自动切换 针对有状态的主备类型业务，在跨AZ部署并支持自动切换时，需要对接容灾仲裁，以避免出现双主或双备，从而在AZ间链路中断的情况下，业务能自动切换到一个AZ提供服务而不受影响；对于集群类业务不涉及。 风险等级 高 关键策略 - 面向有状态主备类型业务提供容灾仲裁，站点间链路中断不双主，不破坏数据完整性。 - 应用内所有相关组件对接一致性仲裁，在链路中断的情况下所有组件均能切换到同一个站点，实现端到端的业务可用性 # 2.5.3.5 RES03-04 支持容灾管理 提供容灾管理功能，实现容灾状态及RPO监控，及异常场景下的业务切换。 风险等级 高 关键策略 - 实时监控容灾状态，了解容灾运行状态。 - 支持应用级数据校验，比较AZ间数据同步差异，监控RPO指标。 典型确定性故障场景下自动容灾或切换，无需人工接入，业务不受影响，满足RPO/RTO指标。 - 典型亚健康故障场景，支持业务降级或主动切换，业务不持续受损。 相关云服务和工具 - 多活高可用服务 MAS # 2.5.4 RES04 跨Region/跨云容灾 # 2.5.4.1 概述 为了预防区域级灾难发生，或业务跨云容灾需求，需要构建容灾系统提供较为完善的数据保护与灾难恢复能力，以便在站点级灾难发生时，可以保证生产系统的数据尽可能少的丢失，业务系统能在最短时间内由灾备中心接替，恢复业务系统的正常运行，将损失降到最小。 对于跨Region容灾场景，应用系统可在多个Region中部署，并将数据从一个Region复制到另一个Region，以便在发生地区级服务中断或数据丢失时可进行灾难恢复。 对于跨云容灾场景，当应用系统已部署在IDC或其他云中，可以在华为云中另外部署一套系统并将数据从IDC或其他云复制到华为云中，以便在发生整IDC或整朵云服务中断或数据丢失时可以进行灾难恢复。 # 2.5.4.2 RES04-01 定义应用系统的容灾目标 RPO 与 RTO 在进行容灾设计前，需要根据应用系统的重要性，明确其容灾目标，通常以RPO和RTO指标来定义： - RPO：允许的数据丢失量，与数据的周期性复制周期或连续性复制延时相关。 - RTO：允许的业务恢复时长，即业务中断时长，与灾备端业务的部署与切换方式相关。 风险等级 高 关键策略 不同的业务系统重要性不一样，针对应用系统内的各种业务，需要明确其重要性及对应的RPO/RTO指标要求。比如对于核心业务，通常需要保障业务的连续性，允许业务中断的时间会比较少，从而需要保障故障场景下的业务快速恢复，可采用双活/多活容灾；对于重要业务，允许一定的业务中断时间，可采用主备容灾；对于一般业务，允许中断的业务时间可达到天级，则可采用远程备份；对于一些不重要的业务，其业务中断对外部客户没有影响，则不需要进行容灾。 # 2.5.4.3 RES04-02 部署容灾系统以满足容灾目标 针对不同应用系统的容灾目标，需要综合考虑中断概率、容灾成本等因素，来决定采用什么样的容灾方案来实现这些目标。 风险等级 高 关键策略 面向跨Region/跨云容灾场景，可基于不同的可用性目标要求，采用不用的容灾方案，如远程备份、主备容灾、双活容灾等，其中生产站点根据场景不同可能为其他云或IDC或华为云Region： 远程备份：生产站点内的重要数据，备份到异地华为云灾备Region，当生产站点发生灾难时，需要在异地灾备Region新部署一套业务系统并使用最新备份数据恢复数据，并恢复业务。 - 主备容灾：生产站点与华为云灾备Region各部署一套业务系统，并将生产站点的重要数据异步复制到灾备Region；平常只有生产站点提供业务，当生产站点发生灾难时，将灾备Region提升为主，并将业务流量切换到灾备Region并由其提供业务。 - 双活/多活容灾：生产站点与华为云灾备Region各部署一套业务系统，并将各自站点的重要数据异步复制到其他站点；每个站点都同时提供业务，通过全局负载均衡器进行流量分发；当一个站点发生灾难时，则将业务流量全部分发到其他站点来接管其业务。 以跨Region主备容灾为例，对于已在一个Region部署应用系统后，增加支持跨Region主备容灾能力的实施步骤建议如下： a. 选择另一个Region作为灾备Region，部署一套相应的应用系统，包括工作负载、数据库实例等。 b. 针对应用系统内的关键数据，利用云服务或应用系统自身实现跨Region的数据复制。 若云服务实例支持跨Region容灾，则配置生产站点与灾备Region之间的复制，如对于RDS数据库实例，需申请DRS实例对主Region与灾备 Region的数据库进行实时复制；对于OBS桶，需要配置主Region中的OBS桶到灾备Region中OBS桶的复制。 - 若云服务实例不支持跨Region容灾，但数据比较关键，则需要应用层实现跨Region的数据双写，以进行数据同步。 c. 接入侧主Region与灾备Region各自申请外部IP，并通过DNS域名解析到主Region，在主Region故障时，将DNS域名对应IP地址修改为灾备Region中的外部IP。 d. 申请MAS多活高可用服务，进行容灾编排，以便在灾难场景快速主备切换恢复业务。 # 相关云服务和工具 - 云备份 CBR：支持跨区域复制与恢复 - 数据复制服务 DRS：支持RDS for MySQL、GaussDB for MySQL等数据库的实时灾备，支持跨Region/跨云容灾场景 - 对象存储服务 OBS：支持跨区域复制与双活 # 2.5.4.4 RES04-03容灾恢复过程自动化 由于容灾恢复场景涉及容灾站点的业务恢复、数据库的主备切换、业务到容灾站点的流量切换等，恢复过程比较复杂，因此需要提供容灾管理功能，实现容灾状态及RPO监控，以及灾难场景下的一键式自动切换，减少人工干预。 # 风险等级 高 # 关键策略 - 实时监控容灾状态，了解容灾运行状态。 - 支持应用级数据校验，比较AZ间数据同步差异，监控RPO指标。 - 灾难场景下的一键式自动切换，减少人工干预，满足RPO/RTO指标。 - 支持容灾恢复流程编排、容灾演练等功能。 # 相关云服务和工具 - 多活高可用服务 MAS # 2.5.4.5 RES04-04 定期进行容灾演练，以检查恢复能否满足容灾目标 通过定期的容灾演练，可以验证灾备系统是否可用，且数据丢失时间以及恢复时间符合数据的RPO与RTO指标要求。 # 风险等级 高 # 关键策略 - 每年至少进行一次容灾演练；通过演练可提升操作人员的熟练程度。 - 演练期间需要对恢复过程计时，以确定应用系统的RPO与RTO目标能否满足。 - 演练期间可检查灾难恢复计划执行顺序及恢复时间并进行优化。 # 相关云服务和工具 - 多活高可用服务 MAS # 2.5.5 RES05 网络高可用 # 2.5.5.1 概述 应用系统对外或对内通信都依赖于网络，一旦网络异常将会导致业务中断，因此网络架构的高可用及容灾能力至关重要。在进行网络设计时，需要充分考虑应用系统对内和对外的网络连接、IP地址管理和域名解析等。 华为云中网络高可用主要涉及三个场景： - 公有云网络：构建应用系统相关的公网网络连接的高可用，可减少由于网络连接中断而导致的业务中断。 - 混合云网络：对于自建本地数据中心（IDC）或使用其他云的用户，基于业务发展需要将部分业务部署到华为云时，将涉及到混合云网络互连；应用系统跨云部署时（如跨云主备容灾或双活），需要构建高可用的混合云网络连接，以减少由于网络连接中断而导致的业务中断。 - 云上网络之间访问：当业务系统涉及到多个部门或业务团队时，一般会使用多个VPC进行业务隔离，不同团队和部门之间需要相互访问，将会涉及不同VPC之间的网络连接。 # 2.5.5.2 RES05-01 网络连接高可用 应用系统对外提供服务时，需要确保对外网络连接的高可用，避免单个网络连接中断而导致业务不可用。 风险等级 高 关键策略 - 网络链路冗余：网络连接需要支持多路径，以实现高可用能力，以避免在一条网络路径中断的情况下，业务能切换到其他路径继续通信。 - 网络链路快速倒换：需要定期检查网络链路的连通性，但检测到失败时需要尽快切换到正常路径。 公有云组网场景可通过多EIP弹性IP及DNS域名解析实现网络连接的高可用；对可用性要求较高的场景，需要支持智能DNS功能，能对EIP进行异常监控和自动切换；此外DNS自身也需要冗余容错，避免由于DNS故障而导致域名解析失败，业务中断。 混合云组网场景链路冗余与倒换方案： - 双DC专线冗余：用户数据中心与华为云VPC之间采用两条DC专线互通；其中两条物理专线接入同区域的两个华为云专线接入点，并通过BGP路由协议接入同一个VPC，用户可设置虚拟接口的优先级以决定业务的主备链路。 具体的方案参见“用户通过虚拟网关负载冗余方式访问VPC”。 - 双VPN冗余：用户数据中心与华为云VPC之间采用两条VPN连接保证可靠性；当其中一条VPN连接故障时，系统可以切换到另一条VPN连接，保证网络不中断。两条VPN连接可以是双活或主备部署。 具体的方案参见“通过VPN实现云上云下网络互通（双活模式）”与“通过VPN实现云上云下网络互通（主备模式）”。 - DC专线/VPN主备：用户数据中心与华为云VPC之间同时部署DC专线和VPN 两条网络链路，互为主备，并通过企业路由器，可以实现DC和VPN主备链路 的自动切换，不需要手工切换双链路，不仅避免业务受损，同时降低维护成本。 具体的方案参见“通过企业路由器构建DC/VPN双联路主备混合云组网”。 # 相关云服务和工具 - 云专线DC - 虚拟专用网络VPN # 2.5.5.3 RES05-02 避免暴露不必要的网络地址 网络地址对外暴露时，可能会引入安全风险，需要避免暴露不必要的网络地址。 # 风险等级 高 # 关键策略 - 通常对外网络地址需要尽可能集中管控，避免分散暴露，如使用网络服务ELB弹性负载均衡、公网NAT网关、Web云防火墙等作为公网访问入口。 - 对外的IP地址需要通过安全组、NAT等限制网络端口访问，减少安全风险。 # 相关云服务和工具 - 虚拟私有云VPC：安全组 弹性负载均衡器ELB - NAT网关NAT Web云防火墙 WAF # 2.5.5.4 RES05-03 不同流量模型业务的网络共享带宽隔离 不同流量模型业务共享网络带宽时，可能会导致流量抢占，相互影响，一个业务流量突然可能会导致其他业务不可用。 # 风险等级 高 # 关键策略 - 相同流量模型的业务，可共享网络带宽，带宽需要满足所有共享业务的需求 - 不同流量模型的业务，为了避免相互干扰，建议使用各自独立的共享带宽实例 - 不同特性的业务，建议使用各自独立的域名隔离。 # 2.5.5.5 RES05-04 预留 IP 资源以便扩展及高可用 云上网络需要满足可扩展以及高可用需求，以便在云上资源弹性伸缩或业务扩展时，有足够网络资源支撑业务发展。 # 风险等级 高 # 关键策略 云上网络规划设计应满足以下原则： - 针对每个Region，根据业务需要规划不同的VPC，每个VPC使用独立的地址空间；并需要预留IP地址空间用于新建VPC。 - 针对每个VPC中，需要根据业务需要规划子网和IP地址空间；并需要预留IP地址空间用于新建子网。 - 针对每个子网，需要预留IP地址空间用于网络扩容。 - 当涉及与其他网络（如VPC、IDC或其他云）互连时，需要确保IP地址空间不重叠。 # 2.6 故障全面检测 # 2.6.1 RES06 故障检测 # 2.6.1.1 概述 高可用性系统必须具有完善的故障检测能力，以确保能够快速发现那些可能导致故障的事件、显示正在发展的故障、激活的故障，以及潜在的故障的事件。 在几乎所有情况下，故障检测能力都是故障恢复的前提。 # 2.6.1.2 RES06-01 故障模式分析 故障模式分析是在系统分析和设计过程，通过对各组成单元潜在的各种故障模式及其对产品功能的影响进行分析，并把每一种潜在故障模式按它的严酷度予以分类，找出单点故障和产品的薄弱环节，提出可以采取的预防改进措施，以提高产品可靠性的一种设计方法。 当应用系统部署在华为云中时，华为云提供了基础设施的故障管理，应用系统可减少对机房、电力、环境、计算服务器、存储设备、网络交换机等基础设施的故障模式的检测和恢复处理，但仍需考虑这些基础设施故障对应用系统的影响及对应的恢复措施，如机房发生灾难(AZ或Region级灾难)、计算服务器故障/重启、使用本地硬盘时硬盘故障/亚健康、网络通信中断/丢包等。而对于应用自身相关的故障模式，如软件系统类、数据类、通信类、负荷过载、人因差错等类型的故障，更需要充分分析并提供检测和恢复措施。 # 风险等级 高 # 关键策略 针对每种故障模式，分析其发生的频率以及造成的影响，以确定严酷度等级。对于存在单点故障的组件对应的故障模式，严酷度必须设置为高。云服务通用的故障模式有：CPU过载、内存过载、磁盘使用率过高、数据故障(被误删等)、AZ故障、Region故障等。 a. 定义严酷度类别 严酷度是度量故障给系统造成的最坏潜在后果，一般分为四个等级：Ⅰ类（严重）、Ⅱ类（较严重）、Ⅲ类（一般）、Ⅳ类（轻微）。 - I类：这种故障会导致整个系统崩溃或主要功能受到严重影响； II类：这种故障会导致系统主要功能受到影响、任务延误的系统轻度损坏或存在较大的故障隐患； III类：系统次要功能丧失或下降，须立即修理，但不影响系统主要功能实现的故障； IV类：部分次要功能下降，只需一般维护的，不对功能实现造成影响（一般告警或指示灯故障等）。 其中，I～II类故障通常称为重大故障，也即“单点故障”，它们的区别主要是I类故障可能涉及到安全性问题，或者I类故障是所有/大部分功能丧失。II类故障指主要功能受影响。III类故障可简单理解为需要尽快修复的故障。 通常来说，当一个故障不能被检测出来时，会认为这是一个故障“隐患”，相应的故障严酷度级别上升一级。 b. 标识系统中的所有组件及功能模块 明确应用系统涉及的所有组件，以及外部依赖项，如提供者、第三方服务等。 c. 识别故障点 对于每个组件，标识可能发生的潜在故障。单个组件可能具有多种故障模式，需要针对不同故障模式分别分析。故障模式的种类需要尽可能完备，若出现遗漏，可能导致该故障在设计中不被考虑，而没有进行监控和恢复处理。 d. 故障影响范围分析(爆炸半径) 针对每种故障模式，分析其发生的频率以及造成的影响，以确定严酷度等级。对于存在单点故障的组件对应的故障模式，严酷度必须设置为高。云服务通用的故障模式有：CPU过载、内存过载、磁盘使用率过高、数据故障(被误删等)、AZ故障、Region故障等。 e. 提供故障检测和缓解措施 f. 针对每种故障模式，需要分析如何检测和恢复，提出改进建议措施，并在系统复杂度和成本之间进行综合考虑，优先解决严酷度高的故障模式。 # 相关云服务和工具 - 云运维中心COC：支持故障模式管理。 # 2.6.1.3 RES06-02 面向所有故障进行检测 针对所有故障场景，都需要能自动检测，以便及时发现和恢复故障。 # 风险等级 高 # 关键策略 - 所有故障都必须有检测。 - 支持按不同维度进行故障检测，如Region、AZ、服务、方法、实例或容器ID等，检测维度与故障恢复方式对齐。 - 检测到故障后需及时告警或自动恢复。 针对具体故障进行检测时，根据检测的类型通常可以分为资源检测、功能检测和业务检测。 - 资源检测：云环境中一般指虚拟化后的物理硬件资源及其对应的软件资源，具体包含CPU、内存、网络和磁盘资源等。 - 功能检测：对组成产品系统的各个内部模块对象进行检测的过程，确定模块功能是否满足设计的需求。当产品系统的功能发生故障时，对外的呈现即为功能输出和预期不一致。在产品上线之前，通过功能相应接口，开发者和测试人员需要多次检测以保证模块功能的正确性。功能检测可以使用传统日志跟踪技术、调用链技术来进行检测，如华为云APM。 - 业务检测：模拟用户的业务操作过程，获得完成业务的操作过程性能数据和操作结果数据；业务检测使用拨测技术来完成检测，由于拨测需要占用网络资源，对于长周期拨测，一般选择在空闲时间段进行，属于抽样检测，而如果是短周期拨测（如5分钟周期），则可例行进行；与功能检测的联系是，业务检测也可以采用调用链来完成。 故障检测方法根据类型有很多种，下面是一些在高可用性系统中常用的故障检测方法。 数值范围检查：在大多数应用中，一个操作的结果必须处于某个范围之内。对这些边界条件可以进行一些测试来验证数据是否满足预期要求。 - 数据完整性检查：每当数据被从一个单元传递给另一个单元时，该数据可能会被破坏。对于在硬件单元间传递的数据尤其如此。然而，由于软件层可以隐藏本地内存传送和跨远程链路的传送间的差异，因此需要在多个点进行数据完整性检查。可以采用很多方法来验证数据的完整性，其中大多数方法都依赖于冗余或者包含在数据中的摘要信息。有些方法采用足够的冗余，不仅能检测错误，而且能纠正错误。但大多数方法中都只包括足够的额外信息来检测数据是否有效。典型的方法如奇偶校验和CRC（循环冗余校验）。 比较测试：当系统具有冗余时，可以使两个系统并行进行计算，然后对结果进行比较，如果结果不匹配则认为发生了故障。这种概念也称为表决。比较可以在系统的任何层次上进行，包括在一条内存总线上的cycle by cycle的比较，到最终发送到网络上结果的比较。 - 时间检测：时间检测是故障检测的一种简单形式。如果一个事件预期应在某个时间段内发生，而却没有在该时间段发生，就检测到了一个故障。时间检测的一种特殊方法通常称为心跳方法。它采用以某个规定的周期频率执行的某些类型的消息握手。该技术可以用于验证单元或子系统是否仍然能够维持某些等级的功能。 # 2.6.1.4 RES06-03 支持亚健康检测 系统内组件有可能完全故障，也有可能处于亚健康状态；亚健康是指系统整体业务未超标，但系统中局部实例业务超标。亚健康更多是个相对概念，相对历史表现的统计，或相对系统整体。因此针对亚健康的检测和判断有所不同。当处于亚健康状态时，系统也需要及时进行隔离或恢复处理，避免对业务造成影响。 # 风险等级 高 # 关键策略 亚健康检测通常用于根据亚健康症状来预测系统故障，典型的例子是内存泄漏，内存泄漏往往不会立刻导致系统失效，系统首先会因为Swap Memory不足变得运行缓慢，消耗内存量持续增加，因此通过监控实例内的内存占用率，在超过阈值的情况下及时告警，人工介入迅速恢复，可避免造成业务中断。 典型的亚健康场景有：通信链路丢包/错包、硬盘性能下降、CPU/内存过载等，当应用系统内组件出现亚健康时，可能会导致应用系统对外业务成功率下降。 由于亚健康并非故障，因此针对亚健康的检测一般是针对业务监控指标设置阈值，当指标超过阈值时进行告警和恢复处理。 # 2.6.2 RES07 监控告警 # 2.6.2.1 概述 监控是应用运维的基础，确保运维人员通过监控主动发现问题。 应用系统需要监控，以便维护人员能快速识别系统运行现状及问题。 # 2.6.2.2 RES07-01 定义关键指标与阈值并监控 对资源进行监控时，需要先定义资源的关键指标以及对应的阈值，以便快速有效地发现业务表现和系统状态，以便在异常状态下尽早干预恢复，或定位改进系统缺陷。 # 风险等级 中 # 关键策略 - 关键指标需要与系统内工作负载的关键性能指标相关，并能确定为系统性能下降的早期警告信号，如系统处理的API数量及成功率，相比CPU利用率、内存利用率等基础指标，能更真实的指示系统性能问题。 - 从可用性保证出发，结合有效性和简化，建议应用系统至少从业务状态、服务状态、资源状态三个层面进行监控。根据业务规模，可以使用CES服务（侧重在I层服务）或AOM/APM服务（侧重在P层业务），也可以借助Prometheus、Zabbix、Zipkin等部件自行搭建，使用Grafana等部件进行界面展示和时序对齐。 # 1、业务监控 以下4个黄金指标，是针对大量分布式监控的经验总结，可以作为业务监控的参考，包括： - 延迟：注意需要区分请求成功的延迟和请求失败的延迟。 - 流量：对系统业务负荷的监控。 - 错误率：注意区分显示失败（如HTTP 500错误）和隐式失败（如HTTP 200中包含了错误内容）。 - 饱和度：侧重在对系统中最为受限的瓶颈资源的监控。 对于基于Java的应用系统，华为云用户可使用APM服务实现基于调用链的业务延迟和错误率监控。函数服务FunctionGraph、微服务引擎CSE提供了流量、延迟和错误率监控能力。基于API网关暴露接口的应用，可使用APIG服务提供的流量、延迟和错误率监控能力。如果云服务现有能力不能满足系统要求，用户也可以自行埋点或基于Zipkin开源框架实现调用链跟踪、延迟和流量监控。 # 2、服务监控 由于服务实例的冗余配置和应用系统的容错保护，业务指标正常并不意味着服务实例状态一定正常。例如，在配置了ELB的虚拟机集群中，ELB会主动隔离异常节点，虽然业务会在正常节点上分担，但应用系统实际已损失了部分处理容量。因此，云服务状态监控必不可少。 云服务具体指标因功能特性而异。站在功能提供者的层面，通常同样需要重点关注延迟、流量、错误率、利用率等指标。此外，服务实例的动态伸缩、过负荷控制、故障自愈或迁移等可靠性关键事件也是服务健壮性的表征，如有异常需要预先干预。关键事件监控可以使用CES服务，或自行搭建。 CES服务支持ECS、EVS、OBS、VPC、ELB、AS等IaaS服务，以及RDS数据库，DCS、DMS等高可用中间件的主要指标监控，支持用户上报自定义监控指标。如果用户自行搭建监控系统，也可以通过CES SDK获取指定服务的监控指标。 AOM服务提供了微服务应用和节点的关键指标监控能力。云容器工作负载关键指标在CSE服务中查看。函数服务关键指标在FunctionGraph控制台中查看。 # 3、资源监控 资源监控通常用于识别资源瓶颈分析系统性能问题。对应用系统资源进行监控时，需要先定义资源的关键指标以及对应的阈值，以便快速有效地发现业务表现和系统状态，以便在异常状态下尽早干预恢复，或定位改进系统缺陷。 常用USE方法（Utilization Saturation and Errors Method）对资源监控，包含： - 使用率Utilization：覆盖系统资源，包括但不限于CPU、内存、网络、磁盘等。 - 饱和度Saturation：针对资源的饱和度，如CPU队列长度，注意与业务监控的黄金指标相区分。 - 错误Errors：资源处理错误，如网络丢包率等。 CES主动监控提供了虚机细粒度的监控能力，其他服务监控指标也不同程度涉及到资源使用率和错误监控。如果云服务现有能力不能满足系统要求，用户可使用CES或AOM服务的自定义指标监控能力。用户若自行搭建监控系统，需要覆盖主机资源、网络设备和Apache、Java、MySQL等第三方组件，开源的Zabbix是常见选择。 # 相关云服务和工具 云监控服务CES - 应用运维管理 AOM - 应用性能管理 APM # 2.6.2.3 RES07-02日志统计监控 应用系统需要收集日志，在必要时对日志进行统计分析，设置告警规则触发告警，统计分析的内容可以是统计一定时间段内某些关键字出现的次数。 # 风险等级 中 # 关键策略 - 日志关键字与出现次数阈值需要合理设置，以免监控信息不正确。 - 日志信息（如关键字或出现频率）发生变化时，需要及时更新告警规则。 # 相关云服务和工具 - 云日志服务 LTS # 2.6.2.4 RES07-03 监控到异常后发送消息通知 当对应用系统监控发现应用异常后，需要向相应的人员和系统发送实时通知消息和告警，以便及时处理。 # 风险等级 中 # 关键策略 - 采用实时快捷的消息通知方式，以便相关人员能及时得到消息。 - 消息发送人员需要涵盖运维人员，以便及时恢复。 - 运维人员需要有备份，避免单点风险。 SMN消息通知服务可依据用户需求主动推送通知消息，方式可为短信、电子邮件等。CES、AOM、CTS、APM、LTS等服务均已经对接SMN消息通知服务，在阈值规则发生变化时，可以以邮件或短信等方式通知，以便您在第一时间发现异常并进行处理。 # 相关云服务和工具 消息通知服务SMN - 云运维中心COC：支持人员管理、排班管理和通知管理，可以根据通知规则自动将消息发送给要通知的人员。 # 2.6.2.5 RES07-04 监控数据存储和分析 监控数据包括统计和日志信息，均需要存储并进行生命周期管理，以满足数据监控的保留要求；并定期对其进行分析，以了解系统运行状态和趋势。 风险等级 中 关键策略 - 监控数据存储时长需要满足保留要求。 - 监控数据需要定期分析，以便发现或预测系统故障，减少业务中断。 相关云服务和工具 LTS云日志服务：支持日志分析与数据转储 # 2.6.2.6 RES07-05 端到端跟踪请求消息 端到端跟踪请求消息的处理流程，便于分析和调试问题，并提高处理性能。 风险等级 低 关键策略 - 消息跟踪需要包含消息处理流程中所有组件，以便跟踪结果完整，从而进行准确分析和定位。 相关云服务和工具 - 应用性能管理 APM：支持调用链追踪，能够针对应用的调用情况，对调用进行全方面的监控，可视化地还原业务的执行路线和状态，协助性能及故障快速定位。 在查询后的调用链列表中，单击待查看的调用链的链接，查看该调用链基本信息。 调用链详情页面可以查看调用链的完整链路信息，包含本地方法堆栈和相关远程调用的调用关系。 调用链与日志关联，提高用户体验。用户可以从调用链直接跳转LTS查看日志。 # 2.7 故障快速恢复 当应用系统采用华为云服务的高可用设计时，在云服务实例发生故障后，云服务能自动检测和恢复；但对于应用系统本身的故障，需要应用系统自身进行检测和快速恢复处理，以保证系统能够正常运行，从而提高系统的可靠性和稳定性。 # 2.7.1 RES08依赖减少与降级 # 2.7.1.1 概述 对于应用系统，需要识别和管理系统依赖项。应用系统设计人员需要维护对其他系统组件的依赖项的完整列表，包括系统内和系统外的所有依赖。 应用系统应尽可能减少关键依赖项，即减少由于该依赖项不可用而导致服务中断的组件。 # 2.7.1.2 RES08-01 减少强依赖项 系统内组件之间强依赖时，一个组件故障会对其他组件造成直接影响，影响系统可用性。 风险等级 中 关键策略 可以通过以下技术将强依赖项转换为非强依赖项： - 提高关键依赖项的冗余级别，降低该关键组件不可用的可能性。 - 与依赖项的通信采用异步消息并支持超时重试，或发布/订阅消息功能将请求与响应分离，以便依赖项从短时故障中恢复。 - 依赖项长时间无法访问时，应用程序应能继续执行其核心功能，以便将局部故障对整体系统功能的影响减到最小。如所依赖的数据丢失时，应用程序仍能运行，但可以提供稍微陈旧的数据、替代数据，甚至没有数据，应用仍处于可预测和可恢复的状态。 避免启动依赖及循环依赖。若应用系统由于某些原因导致重启时，若依赖于其他依赖项启动或加载关键配置数据，可能会导致应用系统长时间停在启动状态而无法响应外部消息。针对这种情况，应用系统应该先使用缺省配置启动，再检查依赖项的状态或加载最新配置数据，以恢复正常运行。 # 2.7.1.3 RES08-02 依赖松耦合 系统内组件之间直接访问时，会产生紧耦合关系一个组件的状态变化会对其他组件产生直接影响，从而会导致所有组件的可用性均下降。而采用松耦合架构时，各个组件之间的依赖关系非常弱，它们可以独立地进行修改和扩展，而不影响其他组件；系统更加灵活，易于维护和升级，并且稳定性和可靠性也更强。 风险等级 中 关键策略 组件之间通过消息队列、消息缓存、负载均衡器等交互（即松耦合关系），可一定程度上屏蔽组件的状态变化，防止对其他组件造成影响 相关云服务和工具 弹性负载均衡服务ELB 分布式缓存服务 DCS 分布式消息服务Kafka版 分布式消息服务RabbitMQ版 分布式消息服务RocketMQ版 事件网格EG # 2.7.1.4 RES08-03 减少被依赖项故障的影响 被依赖项自身的可用性需要增强，以减少对依赖它的组件的影响。 风险等级中 关键策略 对于被依赖项本身，为减少由于服务故障或运行缓慢对依赖它的组件的影响，需要考虑使用以下技术和原则： - 减少被依赖项本身的外部依赖。 - 优化性能，减少消息响应时延和负载。 - 使用优先队列，优先处理高优先级用户的请求，以便在流量过载时不影响应用系统的核心功能。 - 流量过载时支持功能逐步降级。 - 被依赖项本身的功能受损时，提供缺省处理，以便应用系统仍可继续正常运行；由于缺省处理可能与实际配置有差异，此时需要告警以便通知系统管理员解决问题。 # 2.7.2 RES09 故障重试 # 2.7.2.1 概述 当应用系统部署在云中，虽然云具有一定的高可用和故障自动恢复能力，但对外仍会导致短时间的故障，需要应用系统能针对这种短时间故障进行适配处理，主要是采用重试机制。 云中故障需要重试的典型场景有： 1. 实例主备切换时可能会导致连接中断，如DCS、RDS实例由于某些原因主备切换时，会导致连接中断，需要客户端重试。 2. 实例由于故障重启可能会导致通信中断，如ECS所在物理服务器由于硬件原因故障时，ECS重启或在其他物理服务器中自动恢复，恢复过程中与ECS的通信会中断，需要重试。 3. 实例由于过载导致无法及时响应，需要重试。 # 2.7.2.2 RES09-01 API及命令调用需要设计为可重试 在进行重试处理时，API及命令调用会重复发送，服务方会多次重复执行，需要保证重复执行多次的结果不变。 风险等级 高 关键策略 应用系统在设计时，应使操作具有幂等性，也就是允许一个操作连续执行两次或多次时，应该与单次调用产生的结果相同，从而保证重试安全；若不支持操作的幂等性，会导致客户端难以重试或重试的处理更复杂。 # 2.7.2.3 RES09-02 客户端需要根据综合评估是否要重试 当客户端请求超时或收到错误响应时，客户端需要决定是否重试；重试有助于客户端在请求失败时，通过重复消息来获得预期的结果，避免业务失败，但也会消耗更多的服务器时间来获取所需的成功响应。 # 风险等级 高 # 关键策略 - 请求超时，可能是链路闪断或其他临时性故障导致消息丢失，可以进行重试。 - 根据错误响应码进行有针对性的重试；对于临时性故障，如错误码指示为系统繁忙时，可等待一段时间后重试，否则无需重试。 - 请求SDK中内置了消息重试时，客户端无需重复重试。 - 多层业务栈一般只在源端重试，避免逐层重试。 # 2.7.2.4 RES09-03 重试需要避免造成流量压力 对于链路闪断等原因导致的临时性故障，客户端进行一定的重试，可取得较好的效果；对于流量过载等原因导致的故障，重试可能会导致情况进一步恶化，因此需要避免这种影响。 # 风险等级 高 # 关键策略 客户端进行重试处理时，建议： - 增加指数回退和抖动方法，以避免对服务端造成流量压力；采用指数回退重试时，每次重试之间的间隔会逐渐延长，并在两次重试之间引入抖动，以随机调整重试间隔，避免同时出现造成重试峰值。 - 限制最大重试次数或用时，避免由于消息积压而导致流量过载。 # 2.7.3 RES10 故障隔离 # 2.7.3.1 概述 当系统某个单元发生故障时，如果不采取措施，故障可能会大规模扩散，从而造成整个系统失效。故障隔离技术的核心思想是将一个工作负载内的故障影响限制于有限数量的组件内，降低故障影响范围，防止产生级联故障。 通过划分故障隔离域，限制工作负载的影响，可有效进行故障隔离。 # 2.7.3.2 RES10-01 应用控制平面与数据平面隔离 通常应用的数据平面处理业务，比较重要，可用性要求比较高，而控制平面不直接处理业务，因此其故障时不应该影响业务系统。 # 风险等级 高 # 关键策略 - 应用控制平面与数据平面隔离，避免控制系统故障影响业务。 - 数据平面所在业务系统的故障恢复可不依赖控制平面，避免由于控制平面故障而导致业务系统无法恢复。 # 2.7.3.3 RES10-02 应用系统多位置部署 通过将应用系统部署在多个位置，可以避免由于一个位置的基础设施故障而导致系统不可用。 风险等级 高 关键策略 - 将应用系统的数据和资源部署在多个AZ，可避免单个AZ故障影响业务。 - 对于可用性要求较高的应用系统，可部署在多个Region，避免单个Region故障影响业务。 - 当多AZ架构可以满足应用可用性需求时，无需采用多Region部署。 # 2.7.3.4 RES10-03 采用 Grid 架构 采用Grid架构，可将应用系统内的工作负载的故障影响限制在有限Grid业务单元中。 风险等级 高 关键策略 应用系统采用多个功能相同的Grid业务单元，每个Grid业务单元具备完整业务功能，处理整个业务负载中的一个子集，不涉及与其他Grid业务单元的交互；在一个Grid业务单元发生故障时，仅影响本Grid业务单元所处理的业务，对其他Grid业务单元没有影响，从而减少爆炸半径。 应用系统典型Grid架构部署如下： 实施步骤： a. 确定分区键。选择分区键应考虑: 选择分区键必须考虑匹配服务的“粒度”或者考虑以最小的方式跨分区互动。对于多用户系统，可使用用户ID作为分区键；而对于资源为对象的系统，则可以使用资源ID作为分区键。 - 所确定的分区键，必须在所有API或命令中都能直接包含或可通过其他参数间接转换得到，以便能使用该分区键进行分区处理。 按分区键进行分区处理时，需要确保对应分区能独立处理业务，尽可能避免或减少与其他分区的交互。 b. 确定分区数量与每个分区的大小，后续还存在增加分区的情况。需要综合考虑： 分区数量越多，对应分区会越小，爆炸半径也越小，运维定位简单，可用性高，但由于资源共享利用率低，所需的成本也越高。 分区数量越少，每个分区的资源多，更容易适合对资源要求较高的大客户，运维管理简单，且资源利用率越高，所需的成本低。 c. 确定分区映射算法。存在以下一些映射算法供参考: 原始除模：即使用分区键对分区数量取模，该算法分布均匀，但是不适配Grid增删场景，一旦增删需要进行业务迁移。 - Range-Hash/Hash：即使用分区键按范围分区后Hash或直接使用分区键 Hash，元数据管理相对复杂一些。 Full-Mapping：全映射，即针对分区键指定Grid，使用全映射会带来对映射表的严重读写依赖，读写一致性要求考虑，通常需要引入meta data service。 基于前缀和范围mapping：基于前缀和范围的映射，将分区键映射到Grid，并在提供灵活性的同时，弥补了Full-Mapping的不足。 - Mapping代替：强制将特定key分配给特定Grid，方便测试、隔离。 d. 进行Grid路由层设计。设计原则如下: - 路由层是系统唯一的一个共享组件，因此需要尽可能的稳定，减少修改。 避免业务逻辑，保证尽可能的稳定，减少修改。 由于爆炸半径大，需要足够轻，足够简单，但是不能太简单。 - 某些情况，要考虑避免路由所有调用，有助于减少延迟，并减小路由层的规模。 支持横向扩展，避免路由层成为性能瓶颈。 e. 提供Grid迁移功能，以便在增加/删除Grid业务单元时，可以快速调整分区键对应的Grid业务单元。典型处理过程如下： 从分区键对应的旧位置拷贝数据到新位置。 - 更新Grid路由层路由，使分区键重定向到新位置。 从分区键旧位置删除数据。 # f. Grid代码部署与更新: - Grid代码部署可与跨AZ、跨Region结合，通过多层隔离，减少故障影响范围。 - Grid业务单元代码更新时，建议采用类似金丝雀部署（灰度发布）的方式进行更新，以减少由于版本问题而导致多个Grid业务单元同时故障的可能 # 2.7.3.5 RES10-04 健康检查与自动隔离 对应用组件进行健康检查，当发现故障后进行主动隔离，避免故障扩散。 # 风险等级 高 # 关键策略 - 对系统内组件需要定期进行健康检查，以判断其状态是否正常。 - 对于异常组件，需要能支持自动隔离，避免对整体业务造成影响。 # 相关云服务和工具 - 弹性负载均衡器 ELB：支持健康检查，会定期向后端服务器发送请求以测试其运行状态，并根据健康检查来判断后端服务器是否可用，当判断为异常后就不会将流量分发给该异常后端服务器。 - 云容器引擎 CCE：支持容器健康检查，容器运行过程中，可根据用户需要，定时检查容器健康状况。若不配置健康检查，如果容器内应用程序异常，Pod将无法感知，也不会自动重启去恢复。最终导致虽然Pod状态显示正常，但Pod中的应用程序异常的情况。 # 2.7.4 RES11 可靠性测试 # 2.7.4.1 概述 可靠性测试是为了保证系统在规定的生命周期内，达到预期的可靠性目标；与通常的功能测试不同，可靠性测试需要在业务负荷叠加故障中进行，对测试环境和能力提出了更高要求。 可靠性测试和演练通过主动引入故障来充分验证软件质量的脆弱性，从而提前发现系统风险、提升测试质量、完善风险预案、加强监控告警、提升故障应急效率等方面做到故障发生前有效预防，故障发生时及时应对，故障恢复后回归验证。基于故障本身打造分布式系统韧性，持续提升软件质量，增强团队对软件生产运行的信心，减少业务运行中出现类似问题。 为了保证测试的有效性，测试环境需要与生产环境保持一致。 华为云提供了MAS-CAST故障注入服务、CodeArts PerfTest性能测试服务、MAS多活高可用服务，可用于故障注入测试、压力负荷测试、长稳测试以及灾难演练。 # 2.7.4.2 RES11-01 混沌测试 混沌工程（Chaos Engineering）是通过故障注入的方式，触发或模拟实际故障，验证系统的稳定性和容错保护能力。 # 风险等级 高 # 关键策略 - 在真实环境中测试。 - 作为CI/CD管道的一部分例行执行。 - 主动注入故障，以便在问题发生前提前发现并解决问题。 - 以可控方式注入故障，减少对客户的影响。 混沌工程度量指标： - 故障场景的覆盖率：分析故障场景的覆盖率，例如容灾场景覆盖 $80\%$ ，过载场景覆盖 $60\%$ 。 - 故障场景的命中率：分析故障场景中，真实发生的比率。 - 应急预案的质量：用于度量应急预案有效性和执行效率。 - 风险发现个数与等级：定期评估分析（季度或年度）主动发现的风险数量和级别。 - 风险消减个数、等级与类型：风险降级的数量，风险消减的数量，增加预案的数量，改进监控项的数量。 - 故障恢复时长提升率：对应故障场景经过混沌工程演练，平均恢复速度提升的比率。 - 故障数量相比上年减少数量：本年度故障数量相比上年度减少多少。 # 相关云服务和工具 - MAS-CAST故障注入服务：针对云应用提供测试工具和注入手段，支持故障和业务流程编排的可靠性评估测试、压力负荷测试、CHAOS随机故障注入、生产环境故障演练等能力。 - 云运维中心COC：支持混沌演练，为用户提供一站式的自动化演练能力，覆盖从风险识别、应急预案管理、故障注入到复盘改进的端到端的演练流程。 # 2.7.4.3 RES11-02压力负载测试 通过施加超出系统容量的业务压力，验证云服务的过载保护、业务隔离和优雅降级等能力。为全面验证系统整体的容量规划和业务依赖，云服务应用通常采用全链路压测进行测试。 # 风险等级 高 # 关键策略 - 模拟大量接口消息进行压力测试。 - 模拟各种业务场景进行压力测试。 - 持续自动测试。 - 性能发生偏差时自动告警，以便及时定位和处理。 # 相关云服务和工具 性能测试 CodeArts PerfTest：针对HTTP/HTTPS/TCP/UDP/HLS/RTMP/WEBSOCKET/HTTP-FLV等协议构建的云应用提供性能测试的服务，其支持快速模拟大规模并发用户的业务高峰场景，通过自定义报文内容、时序、多事务组合等复杂场景，帮助用户测试验证业务高峰下的服务表现。 # 2.7.4.4 RES11-03 长稳测试 基于用户使用场景构建业务模型，使用自动化工具构建覆盖系统容量规格 $70\%$ 的业务量，持续7*24小时进行长时间负载测试以评估系统稳定性。 # 风险等级 高 # 关键策略 模拟各种业务场景进行测试。 - 持续自动测试。 - 测试结果发生偏差时自动告警，以便及时定位和处理。 # 2.7.4.5 RES11-04 灾难演练 通过容灾演练，可以验证灾备系统是否可用，且数据丢失时间以及恢复时间符合数据的RPO与RTO指标要求。 灾难演练着重测试服务跨AZ或跨Region故障转移能力，验证系统的容灾能力以及面对灾难时的应对能力，涉及到多个团队间配合，通常作为专项开展。容灾演练可以帮助企业更好地验证RPO、RTO指标，及时发现和解决相关问题，提高系统的可用性和可靠性。 # 风险等级 高 # 关键策略 - 模拟AZ故障或Region故障场景，并基于容灾切换手册进行恢复演练 - 演练结束后，检查RPO/RTO指标是否符合预期；当不符合预期时，调整系统容灾方案，重新进行灾难演练 # - 相关云服务和工具 - MAS多活高可用服务灾难演练：支持同城跨AZ灾备/双活、两地三中心及异地多活等场景下的业务高可用容灾管理、工作流编排及演练切换功能。 # 2.7.4.6 RES11-05 红蓝攻防 通过红蓝攻防，可以模拟各种复杂的攻击场景，帮助全面评估应用韧性，及时发现并解决潜在风险。 # 风险等级 高 # 关键策略 - 蓝军从第三方角度发掘各类脆弱点，并向业务所依赖的各种软硬件注入故障，不断验证业务系统的可靠性；而红军则需要按照预先定义的故障响应和应急流程进行处置。 - 演练结束后，建议针对故障中的发现、响应、恢复三个阶段的时长和操作内容进行复盘，并梳理改进点进行优化，提升业务系统的稳定性。 # 2.7.5 RES12 应急恢复处理 # 2.7.5.1 概述 应用系统无论如何精心设计，仍可能会出现无法恢复的故障，当此类故障发生后，需要进行应急恢复处理。 应急恢复处理预先完成设计，并定期演练。 # 2.7.5.2 RES12-01 组建应急恢复团队 为了应对紧急故障场景，需要组建应急恢复团队，明确责任人，并进行培训。 风险等级高 关键策略 - 组建应急恢复团队：其中包括应急恢复主席及所有组件及关键依赖项的恢复责任人。 应急恢复主席：在出现问题后及时组织应急恢复团队进行快速恢复处理。 组件或关键依赖项运维责任人：负责问题定位和应急恢复处理。 - 制定应急恢复管理方案：所有应急恢复团队人员都需要进行应急恢复培训，熟悉应急恢复处理流程和恢复方法。 # 2.7.5.3 RES12-02 制定应急预案 针对常见问题现象，提供标准化的应急恢复指导，以便在出现问题后，可以有序地完成恢复操作，避免操作失误。 风险等级高 关键策略 需要覆盖常用典型场景。 - 应急恢复需要有标准的操作流程和动作，确保在事件发生时，相关干系人都能够明确自身职责和所需要采取的措施。 - 每个恢复操作动作必须明确无歧义，可指导操作人员。 相关云服务和工具 - 云运维中心COC：支持应急预案管理。 # 2.7.5.4 RES12-03 定期应急恢复演练 定期测试突发事件应急恢复处理，以便在出现问题后能进行高效的恢复处理。 风险等级高 关键策略 - 每年至少进行一次应急恢复演练；通过演练可提升操作人员的熟练程度。 - 演练期间严格按照应急预案进行恢复，以检验应急预案的准确性。 - 演练结束后需要对恢复过程进行回溯，并优化应急预案。 # 相关云服务和工具 - 云运维中心COC：支持混沌演练，为用户提供一站式的自动化演练能力，覆盖从风险识别、应急预案管理、故障注入到复盘改进的端到端的演练流程。 # 2.7.5.5 RES12-04出现问题后尽快恢复业务 应用系统出现故障后，需要能尽快发现，尽快响应。 # 风险等级 高 # 关键策略 可以通过以下途径实现故障的快速发现： - 监控：应用系统需要提供业务监控信息，以便实时了解系统运行状态；维护团队需要有专人观测，并在发现故障发生时，需要及时响应。 - 告警：应用系统在检测到故障后需要及时告警，并能通过短消息、邮件等方式发送给所有相关人员，确保使相关人第一时间得知故障信息，以便快速组织应急响应。 - 预测：维护团队需要根据系统运行现状，通过数据分析、机器学习等方式，预测系统的风险情况，提前进行预防和处理。 在进行应急恢复处理时，通常需要尽快缓解或恢复业务，快速结束业务中断对客户的影响，然后再启动问题定位和修复处理流程，以减少业务中断时间。 - 组织协调：故障发生后，应急恢复主席需要迅速组织相关人员快速恢复业务。 - 应急恢复处理：系统发生故障后需要快速问题分析并按照事先制定的应急预案进行恢复处理。 # 2.7.5.6 RES12-05 应急恢复回溯 在业务进行应急恢复处理后，需要对事件进行回溯并进行优化，以避免故障的再次发生。 # 风险等级 高 # 关键策略 - 对问题进行定位和修复，优化产品能力，减少同类事件的发生。 - 针对应急恢复过程进行总结，优化恢复过程。 # 2.8 过载控制 系统内组件资源有限，在遇到突发流量时可能会造成资源耗尽，而导致业务受损。 # 2.8.1 RES13 过载保护 # 2.8.1.1 概述 当系统流量超过一定阈值后，导致系统处于过载状态时，可能会导致部分请求失败，失败触发业务重试，会进一步增加系统的负荷，形成恶性循环，导致业务成功率远远 低于系统的设计容量，甚至整体不可用。因此应用应该设计过载保护机制，使得在过载状态下依然可以保证一定比例设计容量的处理能力。 通过过载保护，可以缓解客户流量突增、泛洪攻击或重试风暴所造成的大量容量峰值情况，让工作负载能够继续正常处理支持的请求量，避免出现资源耗尽而导致所有请求都不能处理的情况。 # 2.8.1.2 RES13-01 采用自动弹性扩缩容 当系统突发流量时，通过自动弹性扩容，可减少业务中断影响。 # 风险等级 高 # 关键策略 弹性扩缩容需要通过业务处理逻辑与数据分离、状态外置等技术手段支撑系统处理能力的快速增加或减少。 系统扩容和缩容的处理方式有两种，一种是改变单机的处理能力，包括CPU、内存、存储等，称之为纵向伸缩；另一种是单机节点处理能力不变，通过增加节点的数量来改变系统的处理能力，称之为横向伸缩。 系统设计时一般建议采用横向伸缩。采用横向伸缩时，要求业务与数据解耦，即将系统的业务处理逻辑与数据分离、数据（状态）外置，以实现业务节点（含资源）无状态，按需快速增加或减少，从而实现系统业务处理能力的伸缩。 当节点故障或资源不足时，系统需要自动检测和扩展节点，以实现自动横向扩缩容，自动增加资源容量，解决业务处理能力不足的问题，无需人工干预。 华为云提供AS弹性伸缩服务，可以根据伸缩组内的负载情况，及伸缩规则，自动调整ECS实例、带宽等资源。当业务需求增长时，AS自动增加弹性云服务器（ECS）实例或带宽资源，以保证业务能力；当业务需求下降时，AS自动缩减弹性云服务器（ECS）实例或带宽资源，以节约成本。 此外，华为云还提供了一些内嵌伸缩能力的云服务，对用户无感知或仅需简单配置： - OBS、SFS、FunctionGraph等服务会根据请求量自动扩展业务处理能力，用户无感知。 - RDS服务最多支持5个只读副本，可在线扩展只读负载；一键规格变更实现CPU、内存扩容/缩容；在线存储容量扩容。 - CCE服务支持配置自动扩容集群节点和工作负载，伸缩策略支持告警（按CPU或