华为云用户手册

RES09-03 重试需要避免造成流量压力 对于链路闪断等原因导致的临时性故障，客户端进行一定的重试，可取得较好的效果；对于流量过载等原因导致的故障，重试可能会导致情况进一步恶化，因此需要避免这种影响。 风险等级 高 关键策略 客户端进行重试处理时，建议： 增加指数回退和抖动方法，以避免对服务端造成流量压力；采用指数回退重试时，每次重试之间的间隔会逐渐延长，并在两次重试之间引入抖动，以随机调整重试间隔，避免同时出现造成重试峰值。 限制最大重试次数或用时，避免由于消息积压而导致流量过载。 父主题： RES09 故障重试

问题和检查项 在企业进行成本优化的过程中，推荐使用如下问题寻找自身可以改进的点，并参考检查项/最佳实践进行改进，以下所有的检查项，也是最佳实践建议，将在下一章节进行详细描述。 问题 检查项/最佳实践 COST01 您是否按照成本优化的需求，规划了相应的组织机构和流程？ 1. 规划企业组织，将组织结构，流程和成本管理相匹配 2. 规划IT治理体系，提高管理效率 3. 明确团队责任，建立和维护成本意识文化 4. 指定云资源管理策略和相应的权限管理机制 COST02 您是否有预算规划管理机制？ 1.建立云预算与预测流程 2.精细化预算管理和跟踪 COST03 您是否将成本分配到组织单元？ 1. 制定成本分摊原则 2. 可视化成本分摊结果 3. 公共成本分配 COST04 您是否有持续的成本治理？ 1. 建立规范，持续提升成本分配比例 2. 主动监控成本 COST05 您是否为优化指定了策略和目标? 1. 分析业务趋势和优化收益 2. 建立可以量化的优化目标 3. 定期回顾和审核 COST06 您是否使用考虑了不同的计费模式优化成本？ 1. 了解云上不同计费模式的特点 2. 为工作负载选择合适的计费模式 3. 跟踪并监控权益商品的使用情况 COST07 您是否管理了和优化了资源使用情况？ 1. 持续监控资源利用率指标 2. 释放闲置资源 3. 考虑不同的云资源技术选型 4. 降配低负载资源或升配高负载资源 COST08 您是否考虑了架构优化？ 1. 按地域规划应用架构 2. 云原生架构改造 3. 存算分离 4. Serverless探索 父主题： 成本优化支柱

工作负载级参考架构 对于一些中小企业，使用华为云单账号即能满足其IT系统管理的诉求。客户会把所有工作负载部署在一个账号内。以下是一个单账号的工作负载级的安全参考架构。 该架构主要的安全设计如下： 网络安全 防DDoS攻击使用AAD服务 Web类攻击采用WAF防护 采用SSL证书进行通信加密 互联网边界、VPC之间采用 云防火墙 运行环境安全 企业主机安全 服务保护主机安全和 容器安全 VPC内访问控制使用网络ACL+安全组 使用 漏洞扫描服务 定时扫描云上各资源漏洞 数据安全 数据安全中心 实现数据全生命周期安全 存储默认启 数据加密 关键数据库部署数据库安全服务 使用云备份归档服务防关键数据丢失 安全运营 使用 安全云脑 鸟瞰整个云上安全 使用 云日志 、 云审计 、配置审计、 云监控 等服务管理云上资源 使用 威胁检测服务 检测各类云服务日志中的恶意活动和未经授权行为 使用 云堡垒机 接入运维 父主题： 参考架构

RES06-01 故障模式分析 故障模式分析是在系统分析和设计过程，通过对各组成单元潜在的各种故障模式及其对产品功能的影响进行分析，并把每一种潜在故障模式按它的严酷度予以分类，找出单点故障和产品的薄弱环节，提出可以采取的预防改进措施，以提高产品可靠性的一种设计方法。 当应用系统部署在华为云中时，华为云提供了基础设施的故障管理，应用系统可减少对机房、电力、环境、计算服务器、存储设备、网络交换机等基础设施的故障模式的检测和恢复处理，但仍需考虑这些基础设施故障对应用系统的影响及对应的恢复措施，如机房发生灾难(AZ或Region级灾难)、计算服务器故障/重启、使用本地硬盘时硬盘故障/亚健康、网络通信中断/丢包等。而对于应用自身相关的故障模式，如软件系统类、数据类、通信类、负荷过载、人因差错等类型的故障，更需要充分分析并提供检测和恢复措施。 风险等级 高 关键策略 针对每种故障模式，分析其发生的频率以及造成的影响，以确定严酷度等级。对于存在单点故障的组件对应的故障模式，严酷度必须设置为高。云服务通用的故障模式有：CPU过载、内存过载、磁盘使用率过高、数据故障(被误删等)、AZ故障、Region故障等。 定义严酷度类别 严酷度是度量故障给系统造成的最坏潜在后果，一般分为四个等级：Ⅰ类（严重）、Ⅱ类（较严重）、Ⅲ类（一般）、Ⅳ类（轻微）。 I类：这种故障会导致整个系统崩溃或主要功能受到严重影响； II类：这种故障会导致系统主要功能受到影响、任务延误的系统轻度损坏或存在较大的故障隐患； III类：系统次要功能丧失或下降，须立即修理，但不影响系统主要功能实现的故障； IV类：部分次要功能下降，只须一般维护的，不对功能实现造成影响（一般告警或指示灯故障等）。 其中，I～II类故障通常称为重大故障，也即“单点故障”，它们的区别主要是I类故障可能涉及到安全性问题，或者I类故障是所有/大部分功能丧失。II类故障指主要功能受影响。III类故障可简单理解为需要尽快修复的故障。 通常来说，当一个故障不能被检测出来时，会认为这是一个故障“隐患”，相应的故障严酷度级别上升一级。 标识系统中的所有组件及功能模块 明确应用系统涉及的所有组件，以及外部依赖项，如提供者、第三方服务等。 识别故障点 对于每个组件，标识可能发生的潜在故障。单个组件可能具有多种故障模式，需要针对不同故障模式分别分析。故障模式的种类需要尽可能完备，若出现遗漏，可能导致该故障在设计中不被考虑，而没有进行监控和恢复处理。 故障影响范围分析(爆炸半径) 针对每种故障模式，分析其发生的频率以及造成的影响，以确定严酷度等级。对于存在单点故障的组件对应的故障模式，严酷度必须设置为高。云服务通用的故障模式有：CPU过载、内存过载、磁盘使用率过高、数据故障(被误删等)、AZ故障、Region故障等。 提供故障检测和缓解措施 针对每种故障模式，需要分析如何检测和恢复，提出改进建议措施，并在系统复杂度和成本之间进行综合考虑，优先解决严酷度高的故障模式。 相关云服务和工具 云运维中心 COC：支持故障模式管理。 父主题： RES06 故障检测

缓存性能优化 以下章节我们结合一些具体建议和案例来说明如何针对缓存的使用进行性能优化。 Redis使用规范 如下的规范可以帮助我们在系统运行过程中，尽可能减少遇到redis不稳定或异常的概率， 保证系统的长稳运行。 业务使用规范 原则 原则说明 级别 备注 就近部署业务，避免时延过大 如果部署位置过远（非同一个region）或者时延较大（例如业务服务器与Redis实例通过公网连接），网络延迟将极大影响读写性能。 强制 如果对于时延较为敏感，请避免创建跨AZ Redis实例。 冷热数据区分 建议将热数据加载到 Redis 中。低频数据可存储在 Mysql或者ElasticSearch中。 建议 Redis将低频数据存入内存中，并不会加速访问，且占用Redis空间。 业务数据分离 避免多个业务共用一个Redis。 强制 一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。 禁止使用select功能在单Redis实例做多db区分。 强制 Redis单实例内多DB隔离性较差，Redis开源社区已经不再发展多DB特性，后续不建议依赖该特性。 设置合理的内存淘汰（逐出）策略 合理设置淘汰策略，可以在Redis内存意外写满的时候，仍然正常提供服务。 强制 D CS 默认的逐出策略为volatile-lru，请根据业务需求选择。Redis支持的数据逐出策略 以缓存方式使用Redis Redis事务功能较弱，不建议过多使用。 建议 事务执行完后，不可回滚。 数据异常的情况下，支持清空缓存进行数据恢复。 强制 Redis本身没有保障数据强一致的机制和协议，业务不能强依赖Redis数据的准确性。 以缓存方式使用Redis时，所有的key需设置过期时间，不可把Redis作为数据库使用。 强制 失效时间并非越长越好，需要根据业务性质进行设置。 防止缓存击穿 推荐搭配本地缓存使用Redis，对于热点数据建立本地缓存。本地缓存数据使用异步方式进行刷新。 建议 - 防止缓存穿透 非关键路径透传数据库，建议对访问数据库进行限流。 建议 - 从Redis获取数据未命中时，访问只读数据库实例。可通过 域名 等方式对接多个只读实例。 建议 核心是未命中的缓存数据不会打到主库上。 用域名对接多个只读数据库实例，一旦出现问题，可以增加只读实例应急。 不用作消息队列 发布订阅场景下，不建议作为消息队列使用。 强制 如没有非常特殊的需求，不建议将 Redis 当作消息队列使用。 Redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。 如需要消息队列，可使用高吞吐的Kafka或者高可靠的RocketMQ。 合理选择规格 如果业务增长会带来Redis请求增长，请选择集群实例（Proxy集群和Cluster集群） 强制 单机和主备扩容只能实现内存、带宽的扩容，无法实现计算性能扩容。 生产实例需要选择主备或者集群实例，不能选用单机实例 强制 - 主备实例，不建议使用过大的规格。 建议 Redis在执行RewriteAOF和BGSAVE的时候，会fork一个进程，过大的内存会导致卡顿 具备降级或容灾措施 缓存访问失败时，具备降级措施，从DB获取数据；或者具备容灾措施，自动切换到另一个Redis使用。 建议 - 数据设计规范 分类 原则 原则说明 级别 备注 Key相关规范 使用统一的命名规范。 一般使用业务名（或数据库名）为前缀，用冒号分隔。Key的名称保证语义清晰。 建议 例如，业务名:子业务名:id 控制Key名称的长度。 在保证语义清晰的情况下，尽量减少Key的长度。有些常用单词可使用缩写，例如，user缩写为u，messages缩写为msg。 建议 建议不要超过128字节（越短越好）。 禁止包含特殊字符（大括号“{}”除外）。 禁止包含特殊字符，如空格、换行、单双引号以及其他转义字符。 建议 由于大括号“{}”为Redis的hash tag语义，如果使用的是集群实例，Key名称需要正确地使用大括号避免分片不均的情况。 Value相关规范 设计合理的Value大小。 设计合理的Key中Value的大小，推荐小于10 KB。 建议 过大的Value会引发分片不均、热点Key、实例流量或CPU使用率冲高等问题，还可能导致变更规格和迁移失败。应从设计源头上避免此类问题带来的影响。 设计合理的Key中元素的数量。 对于集合和列表类的数据结构（例如Hash，Set，List等），避免其中包含过多元素，建议单Key中的元素不要超过5000个。 建议 由于某些命令（例如HGETALL）的时间复杂度直接与Key中的元素数量相关。如果频繁执行时间复杂度为O(N)及以上的命令，且Key中的子Key数量过多容易引发慢请求、分片流量不均或热点Key问题。 选择合适的数据类型。 合理地选择数据结构能够节省内存和带宽。 建议 例如存储用户的信息，可用使用多个key，使用set u:1:name "X"、set u:1:age 20存储，也可以使用hash数据结构，存储成1个key，设置用户属性时使用hmset一次设置多个，同时这样存储也能节省内存。 设置合理的过期时间。 合理设置Key的过期时间，将过期时间打散，避免大量Key在同一时间点过期。 建议 设置过期时间时，可以在基础值上增减一个随机偏移值，避免在同一个时间点大量Key过期。大量Key过期会导致CPU使用率冲高。 命令使用规范 原则 原则说明 级别 备注 谨慎使用O(N)复杂度的命令 时间复杂度为O(N)的命令，需要特别注意N的值。避免N过大，造成Redis阻塞以及CPU使用率冲高。 强制 例如：hgetall、lrange、smembers、zrange、sinter这些命令都是做全集操作，如果元素很多，会消耗大量CPU资源。可使用hscan、sscan、zscan这些分批扫描的命令替代。 禁用高危命令 禁止使用flushall、keys、hgetall等命令，或对命令进行重命名限制使用。 强制 请参考命令重命名的内容。 慎重使用select Redis多数据库支持较弱，多业务用多数据库实际还是单线程处理，会有干扰。最好是拆分使用多个Redis。 建议 - 使用批量操作提高效率 如果有批量操作，可使用mget、mset或pipeline，提高效率，但要注意控制一次批量操作的元素个数。 建议 mget、mset和pipeline的区别如下： mget和mset是原子操作，pipeline是非原子操作。 pipeline可以打包不同的命令，mget和mset做不到。 使用pipeline，需要客户端和服务端同时支持。 避免在lua脚本中使用耗时代码 lua脚本的执行超时时间为5秒钟，建议不要在lua脚本中使用比较耗时的代码。 强制 比如长时间的sleep、大的循环等语句。 避免在lua脚本中使用随机函数 调用lua脚本时，建议不要使用随机函数去指定key，否则在主备节点上执行结果不一致，从而导致主备节点数据不一致。 强制 - 遵循集群实例使用lua的限制 遵循集群实例使用lua的限制。 强制 使用EVAL和EVALSHA命令时，命令参数中必须带有至少1个key，否则客户端会提示“ERR eval/evalsha numkeys must be bigger than zero in redis cluster mode”的错误。 使用EVAL和EVALSHA命令时，DCS Redis集群实例使用第一个key来计算slot，用户代码需要保证操作的key是在同一个slot。 对mget，hmget等批量命令做并行和异步IO优化 某些客户端对于MGET，HMGET这些命令没有做特殊处理，串行执行再合并返回，效率较低，建议做并行优化。 建议 例如Jedis对于MGET命令在集群中执行的场景就没有特殊优化，串行执行，比起lettuce中并行pipeline，异步IO的实现，性能差距可达到数十倍，该场景建议使用Jedis的客户端自行实现slot分组和pipeline的功能。 禁止使用del命令直接删除大Key 使用del命令直接删除大Key（主要是集合类型）会导致节点阻塞，影响后续请求。 强制 Redis 4.0后的版本可以通过UNLINK命令安全地删除大Key，该命令是异步非阻塞的。 对于Redis 4.0之前的版本： 如果是Hash类型的大Key，推荐使用hscan + hdel 如果是List类型的大Key，推荐使用ltrim 如果是Set类型的大Key，推荐使用sscan + srem 如果是SortedSet类型的大Key，推荐使用zscan + zrem 父主题： 云服务性能优化介绍

RES04-03 容灾恢复过程自动化 由于容灾恢复场景涉及容灾站点的业务恢复、数据库的主备切换、业务到容灾站点的流量切换等，恢复过程比较复杂，因此需要提供容灾管理功能，实现容灾状态及RPO监控，以及灾难场景下的一键式自动切换，减少人工干预。 风险等级 高 关键策略 实时监控容灾状态，了解容灾运行状态。 支持应用级数据校验，比较AZ间数据同步差异，监控及PO指标。 灾难场景下的一键式自动切换，减少人工干预，满足RPO/RTO指标。 支持容灾恢复流程编排、容灾演练等功能。 相关云服务和工具 多活高可用服务 MAS 父主题： RES04 跨Region/跨云容灾

COST06-01 了解云上不同计费模式的特点 风险等级 高 关键策略 云服务存在按需、包年包月、资源包、竞价实例等多种计费模式，不同的计费模式有着不同的适用场景。企业或者组织需要根据自己的需要，了解不同计费模式的特点，合理选择各种计费模式来适配不同的业务形态和降低费率，实现成本节省。 按需计费：适用于临时、突发的业务场景； 包年包月：通过预付一定周期的资源使用费用，来获取优惠的计费模式。一般适用于资源长期使用，业务较稳定的场景； 资源包：一种特殊的包年包月，可通过预付一定周期下某种资源使用量的费用，来获取优惠的计费模式。资源包可以抵扣多个资源的用量，适用于长期使用且用量比较稳定的场景； 竞价计费：适应于业务稳定性不高，中断也不影响业务的场景。 父主题： COST06 使用不同计费模式优化成本

PERF03-03 使用弹性伸缩 风险等级 中 关键策略 如果工作负载能够支持弹性（例如：应用无状态化），请考虑具有自动缩放功能的计算服务，该功能可根据需求自动调整计算容量。自动缩放有助于确保在高峰期拥有足够的资源，并防止在低需求时段过度预配。虚拟机弹性伸缩和容器弹性伸缩都是实现应用自动化扩容和缩容的方式，但虚拟机弹性伸缩需要更多的资源和时间来启动和部署，而容器弹性伸缩可以更快速地响应变化，同时具有更高的资源利用率。虚拟机场景可以使用AS，容器场景充分考虑CA和HPA的弹性策略。 使用容器时弹性策略可参考下面内容： CCE的弹性伸缩能力分为如下两个维度： 工作负载弹性伸缩：即调度层弹性，主要是负责修改负载的调度容量变化。例如，HPA是典型的调度层弹性组件，通过HPA可以调整应用的副本数，调整的副本数会改变当前负载占用的调度容量，从而实现调度层的伸缩。 节点弹性伸缩：即资源层弹性，主要是集群的容量规划不能满足集群调度容量时，会通过弹出ECS资源的方式进行调度容量的补充。 两个维度的弹性组件与能力可以分开使用，也可以结合在一起使用，并且两者之间可以通过调度层面的容量状态进行解耦，详情请参见使用HPA+CA实现工作负载和节点联动弹性伸缩。 工作负载弹性组件介绍 类型 组件名称 组件介绍 参考文档 HPA Kubernetes Metrics Server Kubernetes内置组件，实现Pod水平自动伸缩的功能，即Horizontal Pod Autoscaling。在kubernetes社区HPA功能的基础上，增加了应用级别的冷却时间窗和扩缩容阈值等功能。 HPA策略 CustomedHPA CCE容器弹性引擎 自研的弹性伸缩增强能力，主要面向无状态工作负载进行弹性扩缩容。能够基于指标（CPU利用率、内存利用率）或周期（每天、每周、每月或每年的具体时间点）。 CustomedHPA策略 Prometheus Prometheus（停止维护） 云原生监控插件 一套开源的系统监控报警框架，负责采集kubernetes集群中kubelet的公开指标项（CPU利用率、内存利用率）。 NA CronHPA CCE容器弹性引擎 CronHPA可以实现在固定时间段对集群进行扩缩容，并且可以和HPA策略共同作用，定时调整HPA伸缩范围，实现复杂场景下的工作负载伸缩。 CronHPA定时策略 节点弹性伸缩组件介绍 组件名称 组件介绍 适用场景 参考文档 CCE集群弹性引擎 Kubernetes社区开源组件，用于节点水平伸缩，CCE在其基础上提供了独有的调度、弹性优化、成本优化的功能。 全场景支持，适合在线业务、深度学习、大规模成本算力交付等。 节点自动伸缩 CCE突发弹性引擎（对接CCI） 将Kubernetes API扩展到无服务器的容器平台（如CCI），无需关心节点资源。 适合在线突增流量、CI/CD、大数据作业等场景。 CCE容器实例弹性伸缩到CCI服务 相关云服务和工具 弹性伸缩 AS 云容器引擎 CCE 云容器实例 CCI 父主题： 选择合适的计算资源

COST02-02 精细化预算管理和跟踪 风险等级 高 关键策略 针对企业不同项目/业务/应用，应该建立预算管理机制，精细化管理每个项目/业务/应用全生命周期的云开销。 企业的项目/业务是随时间变化而变化的，一般而言，新兴业务/项目常有更多云资源扩容的需求，而稳定的业务/项目则可以更多考虑单位收益的云成本是否可以持续优化，而处于生命周期末尾的项目/业务则需要考虑逐步释放不再需要的资源。 企业制定预算时，应该伴随项目生命周期的有效跟踪，建立定期审查机制，同时根据业务情况动态调整，不断改进预算规划来更好控制成本，以确保其符合企业的实际情况。 企业应该建立紧急响应和应对计划，设计应对成本超支情况的紧急响应计划。包括明确的流程和责任人，确定接收警报并负责采取行动的责任人或团队。这些人员可能是财务团队、运维团队、部门负责人或特定的成本管理团队。以便在警报触发时能够快速采取必要的措施，如优化资源、停止不必要的服务，或者针对某个部门，项目进行新购买云资源的限制等。 相关服务和工具 华为云提供了通用的预算管理工具，您可以根据企业实际规划的预算，用预算管理工具跟踪起来，并可以设置细粒度的过滤条件，精细化跟踪具体产品、团队、项目的成本。 除了在成本中心查看预算进展外，您还可以为指定预算设置预算提醒，当实际使用或预测使用达到提醒阈值时，及时接收系统发出的短信或邮件预警，从而及时采取下一步措施。 您还可以设置预算报告，定期将指定预算的执行情况以日报、周报、月报的形式周知给企业内部相关角色，比如业务部门、财务、CTO，达到成本透明的目的。 父主题： COST02 实施预算规划管理机制

OPS02-01 进行需求管理和迭代开发 风险等级 高 关键策略 您的云上应用要达到卓越运营，从设计和开发阶段就需要保证可用性，可恢复性，同时也需要保证代码的质量。您需要评估和了解软件DFX相关要求，包括可靠性、性能、可服务性、可运维性、可交付性等要求 将监管、行业和内部合规性要求纳入需求范围中，同时在需求排序的时候，给予这些需求足够的时间和重视。 同时从可维护性来看，较之于一次性颠覆性的大范围应用/软件更新，小步快跑，持续迭代地进行云上软件的更新更有利于运维，因为一则小范围的云上软件更新和部署更不容易引起大范围事故，其次，不停地迭代更新也有效地保证了开发，运维团队成员能够时刻处于练兵状态，不至于对运维的流程，最佳实践比较陌生。要保证云上应用进行迭代更新，那么从需求阶段，就要进行迭代规划和跟踪，通过迭代的方式进行开发管理，根据需求划分迭代计划。 相关云服务和工具 华为云CodeArts Req服务 父主题： OPS02 通过CI/CD实现高效的频繁可逆的小规模变更

RES11-05 红蓝攻防 通过红蓝攻防，可以模拟各种复杂的攻击场景，帮助全面评估应用韧性，及时发现并解决潜在风险。 风险等级 高 关键策略 蓝军从第三方角度发掘各类脆弱点，并向业务所依赖的各种软硬件注入故障，不断验证业务系统的可靠性；而红军则需要按照预先定义的故障响应和应急流程进行处置。 演练结束后，建议针对故障中的发现、响应、恢复三个阶段的时长和操作内容进行复盘，并梳理改进点进行优化，提升业务系统的稳定性。 父主题： RES11 可靠性测试

RES12-02 制定应急预案 针对常见问题现象，提供标准化的应急恢复指导，以便在出现问题后，可以有序的完成恢复操作，避免操作失误。 风险等级 高 关键策略 需要覆盖常用典型场景。 应急恢复需要有标准的操作流程和动作，确保在事件发生时，相关干系人都能够明确自身职责和所需要采取的措施。 每个恢复操作动作必须明确无歧义，可指导操作人员。 相关云服务和工具 云运维中心 COC：支持应急预案管理。 父主题： RES12 应急恢复处理

SEC05-02 实施漏洞管理 漏洞管理有助于及时发现并修复系统中存在的安全漏洞，防范潜在的安全威胁和攻击。安全漏洞可能使他人非法获得系统访问特权，应通过可信渠道获取最新的安全情报。 风险等级 高 关键策略 安全漏洞可通过及时安装安全补丁的方式修复漏洞，以防恶意个人或软件非法利用从而破坏业务系统和数据。通过及时了解最新的华为云和业界的安全公告，实施对应消减建议，来保证工作负载的安全。 及时了解最新的华为云和行业安全建议。华为 云安全 公告包含有关安全性的最新信息。 漏洞扫描 和识别：利用华为云云服务对系统、应用程序进行定期扫描，以发现潜在的漏洞和安全弱点。 自动化扫描漏洞：使用自动化 漏洞扫描工具 对运行环境进行定期扫描，以发现潜在的漏洞和安全风险。 漏洞修复和补丁管理：制定漏洞修复计划，及时修复已确认的漏洞，并管理安全补丁的发布和应用过程。 在关键节点处检测和清除恶意代码：应在关键网络节点处对恶意代码进行检查和清除，并维护恶意代码防护机制的升级和更新。 相关云服务和工具 企业主机安全 HSS 安全云脑 SecMaster 漏洞管理服务 CodeArts Inspector 威胁检测 服务MTD：使用MTD持续发现恶意活动和未经授权的行为。MTD可识别各类云服务日志中的潜在威胁并输出分析结果，从而提升用户告警、事件检测准确性，提升运维运营效率。 父主题： SEC05 运行环境安全

通过可观测性进行持续改进 可观测性是指通过观察系统的外部输出，推断其内部状态的能力。一般来说，云上应用的可观测性通常使用三种核心手段，一：指标，指标是系统状态的定量度量，例如 TPS、请求延迟、调用量等。二: 日志：日志是系统事件的人可读记录，例如应用程序的运行信息，运行错误、安全事件等。三：跟踪（Trace)，跟踪可以追踪单个请求或事务在系统中的路径，帮助我们了解系统的执行情况。 对于构建在云上的应用，通过可观测性，可以快速发现和解决系统故障，从而提高系统从故障中的恢复速度。进一步地，可以提前发现系统的问题，例如性能，容量瓶颈，提前解决问题。更进一步地，您可以通过联动可观测性带来的告警和上文中的自动化流程，通过主动式响应，包括动态缩扩容，流控，主动切流，节点的迁移等，消灭问题于无形之间。

建立持续改进的团队文化和标准化运维体系 在卓越运营中，团队文化建设至关重要。运营是一门不断改进的艺术。只有不断从已有事故中学习经验，持续学习和改进，才能最终达到卓越运营。故而，团队应该培养持续学习和改进的文化，此外，在事故发生时，应该以对事不对人的态度，思考系统的改进，而不是惩罚或者指责个人。片面指责个人或者直接处罚的做法很容易引起一系列后果，例如后续的运维团队成员由于担心处罚，会隐瞒事故或者隐藏真正的事故原因，导致后续无法切实改进系统的运维能力和流程。一线的工程师也因为担心处罚，不愿意担责，不愿意做任何系统的改变。部门、组织之间由于担心事故影响部门、组织内部成员，导致了消极应对系统中隐藏的问题或者将问题推给了其他组织，部门。最终，这种文化上的高压导致整个组织和运维流程的僵化，以及系统不能持续迭代更新之后的代码、架构腐化，最终导致无法运维的系统。 故而，文化上，惩前毖后，应重在总结经验，明确改进责任主体组织，不责怪个人。 在总结经验上，应该将相关经验进行标准化的沉淀，即将经验总结成自动化工具，流程以及建立相应的组织体系，我们称之为标准化运维体系。非标是大规模运维的头号天敌，主要表现是运维无序，团队成员依靠自身技术各自为战，处于被动响应和疲于应付的工作状态，效率低下，人为失误多，故障处理难度大。标准化运维体系是对有效经验总结后，运维活动例行化的高效管理。通过对运维活动的标准化、流程化和工具化管理，实现从无序向有序演进，达到运维操作团队运作“最佳秩序”，简化运维交付工作，降低技能依赖，提高运维效率，降低运作成本。

通过CI/CD实现高效的频繁可逆的小规模变更 在软件开发过程中，应该尽量使需求分析，设计，开发，测试，部署的开发周期较小，使用频繁的小型迭代进行。一个典型的实践是使用微服务和CI/CD实践，微服务架构是一种更为灵活、可扩展和易于维护的架构风格，已经逐渐成为现代应用开发的主流选择。它通过将应用程序拆分为小的、自治的服务，每个服务都负责执行特定的业务功能，可以使用不同的技术栈，由独立的团队开发，测试，部署和扩展，并通过轻量级通信机制相互交互。而在CI/CD下，同一团队以流水线的方式集成整个微服务的开发，测试和进行不同地域的部署、发布和运维。 对于已经采用DevOps模式的组织，应该更进一步，不仅在软件项目的管理，而是从运维角度来看，小型频发的迭代有助于快速发现问题，一旦发现问题，也易于回滚到软件的上一版本，并降低部署失败时发生大规模问题的风险。

X即代码，尽量自动化所有流程 云上应用和传统应用的一大区别是，您可以将整个云上应用，包含应用程序自身、运行应用的云基础设施、安全策略、以及相应的运维操作视为代码。这意味着整个卓越运营的各种实践，都可以极大地使用代码自动化，例如定义应用的基础设施，部署应用自身，修改应用的配置，设置安全策略，甚至日常的运维操作，故障修复，都可以通过代码实现并执行。 自动化是沉淀运维经验，建立标准运维最重要的一环，通过自动化，可以避免人为错误，标准化流程并提高效率。 即使在部分自动化流程中依然需要人工干预，例如决策点。在决策点前的自动化流程依然可以确认人员权限，向人员提供必要的上下文和信息，以便做出明智的决策，比之纯手工流程，最大程度避免了错误。

RES10-02 应用系统多位置部署 通过将应用系统部署在多个位置，可以避免由于一个位置的基础设施故障而导致系统不可用。 风险等级 高 关键策略 将应用系统的数据和资源部署在多个AZ，可避免单个AZ故障影响业务。 对于可用性要求较高的应用系统，可部署在多个Region，避免单个Region故障影响业务。 当多AZ架构可以满足应用可用性需求时，无需采用多Region部署。 父主题： RES10 故障隔离

云运维中心(COC) 云运维中心（Cloud Operations Center，简称COC）为用户提供安全、高效的一站式智能运维平台，满足客户集中运维诉求。承载华为云确定性运维业务场景，提供变更管理、批量运维等核心特性，实现在安全合规的前提下，提升用户运维能力成熟度和云上运维效率。COC产品介绍： 统一资源管理 应用管理：提供应用和资源关联关系建模能力，满足用户云上资源的集中式管理要求，降低管理成本。 资源管理：同步并纳管用户在云平台上使用的资源实例，构筑资源运维能力底座。 配置管理：提供应用和资源视角的管理能力，以及参数配置集中式看护、全生命周期管理的能力。 合规性管理：资源运维提供批量的补丁扫描修复能力，安全合规先行，兼顾高效。 全方位变更管理 方案评审：支持变更方案标准化（Standard Operating Procedure，简称SOP），将变更方案明确并电子化，经评审后归档。支持规则和流程解耦，保证变更执行过程不走样，同时将变更方案沉淀。 变更审批：按照预设审批流程审批变更单，保障变更方案可靠性、时间合理性、流程合规性。 风险评估：基于场景规则、流程规则、业务规则对变更进行管控，提前识别和拦截变更风险；通过变更日历实现变更冲突检测，降低服务间变更依赖导致的变更风险。 实施保障：按预定方案执行变更，变更步骤标准化、可观测，变更异常及时介入处理，实现变更实施全过程可控、可视、可管。 确定性故障管理 统一事件中心：提供事件发现、事件处理、恢复验证及持续改进的全流程标准化机制。 承载Warroom和故障回溯能力：现网事件智能启动Warroom，缩短故障处理非必要耗时，指挥中心实时观测故障处理进展。故障回溯实现问题总结和经验沉淀，客户问题不重犯，缩短故障恢复MTTR。 支持响应预案：支持客户对已知故障制定响应预案，通过预案自动化帮助客户处理确定性问题，实现已知问题快速恢复。 故障模式：融合专业风险分析方法和专家知识库，积累故障模式库，帮助客户分析云应用存在的潜在风险、传承运维经验。 韧性中心优化 全生命周期风险管理：覆盖部署态和运行态两部分的风险治理，贯穿应用和资源全生命周期，将华为云多年沉淀的动态清零风险管理经验使能用户。 使能主动运维：通过性能压测、应急演练/混沌工程、韧性评估等主动运维手段提升客户关键业务的质量和韧性。 丰富的故障演练武器：沉淀华为云实践经验，内置50个+演练攻击武器，赋能客户模拟复杂多样的业务受损场景并制定应对策略。 降本增效：在不影响用户云上业务的同时，从专业的角度提供优化建议，帮助客户降本、增效和业务调优。 父主题： 卓越运营云服务介绍

金融类核心应用典型部署架构（99.999%） 金融类核心应用通常比较重要，要求非常短的恢复时间和数据丢失量，其可用性目标通常要求达到99.999%，即每年故障时间可以为5.26分钟。 假定故障中断与变更中断的时长分别如下： 故障中断：由于要求的故障中断时间很短，要求尽可能自动恢复，没有手动触发的恢复，假定每年故障中断4次，每次自动恢复时长为1分钟，则每年故障中断时长为4分钟。 变更中断：假定应用支持金丝雀部署或蓝绿部署，并自动完成，软件更新不中断业务。 按照以上评估，每年应用系统不可用的时长是4分钟，满足可用设计目标要求。 金融类应用典型架构为三层架构：前端Web集群+后台应用集群+后端数据库集群，其中前端无状态应用可采用ECS或CCE（以CCE为例），后端数据库通常采用RDS for MySQL提供更高性能与可靠性；为满足对应的可用性目标，建议方案如下： 类别 实施方案 冗余 ELB、CCE、DCS、Kafka、RDS、DDS等云服务实例均高可用部署。 备份 RDS、DDS数据库自动备份，在数据故障时使用最新备份数据恢复，可以满足可用性目标要求。 容灾 应用跨AZ部署，AZ故障时自动恢复；支持跨Region双活容灾，在出现Region级故障时可以自动切换在异地恢复业务。 监控告警 进行站点运行状态检查，在发生故障时告警；针对CCE、DCS、kafka、RDS、DDS等实例负载状态进行监控，在资源过载时需要告警。 弹性扩缩容 CCE集群支持工作负载的自动弹性伸缩。 变更防差错 软件更新采用金丝雀或蓝绿部署，部署过程自动完成，在部署过程中出现问题时自动回滚。 应急恢复处理 制定应急处理机制，指定应急恢复人员，以便在突发事件后能快速决策和恢复；并提供常见应用、数据库问题以及升级部署失败的相关解决方案，以便在出现问题后可以及时恢复；定期进行演练，及时发现问题。 根据以上方案，典型部署架构如下： 该架构的主要特点包括： 应用系统采用无状态应用+有状态数据库的分层部署架构。 应用系统在两个Region各部署一套完整系统，Region内跨AZ高可用部署，提供同城跨数据中心双活能力；Region间数据单元化部署，实现跨Region双活容灾，在任一Region故障的情况下能快速恢复业务。 接入层（外部GSLB、API网关）：通过外部GSLB进行域名解析与流量负载均衡，两个Region同时提供服务，在单个Region故障时自动将业务流量切换到另一Region；API网关支持流量纠正，以便将业务路由到正确单元。 应用层（负载均衡器、应用软件及容器）：对于无状态应用，通过 ELB负载均衡 器进行故障检测与负载均衡，并可通过容器进行弹性伸缩。 中间件层：Redis、Kafka集群跨可用区高可用部署。 数据层：MySQL数据库跨可用区高可用，通过DRS 数据复制服务 实现跨Region的双向数据库复制与容灾切换；并支持定期自动数据备份，在数据丢失时能快速恢复。OBS 对象存储服务 同样支持跨Region的双向复制能力。 为了保证数据的可靠性，RDS for MySQL、DDS数据库的数据定期自动备份。 父主题： 参考架构

SEC10-05 建立复盘机制 建立安全事件复盘机制可以帮助团队从过去的安全事件中学习经验教训，并改进未来的安全措施。 风险等级 中 关键策略 确定复盘的目的：在进行复盘之前，明确目的是非常重要的。确定您希望从这次安全事件中学到什么，以及如何改进未来的安全措施。 收集事实和数据：收集关于安全事件的所有相关信息和数据，可以用5W2H方法整理该事件，包括事件发生的时间、地点、责任人、事件的过程、原因、影响等。 组建复盘团队：邀请相关的团队成员和利益相关者参与复盘过程。确保涵盖各个关键领域的代表，如技术人员、安全运营人员等。 分析根本原因：通过结果追溯分析事件的根本原因，连续问几个为什么，找出导致事件发生的最根本的问题。这有助于避免将来类似事件的发生。 识别失误和缺陷：识别在安全事件中发生的失误、缺陷或不足之处。这包括技术、流程、人员等方面。 制定改进措施：基于复盘的结果，制定具体的改进措施和行动计划。这些措施包括人、流程、技术等方面。确保这些措施是可行的、具体的，并且能够有效地解决问题。 实施改进措施：将制定的改进措施付诸实施，并监控其执行情况。确保所有相关人员都了解并遵守这些改进措施。 定期检视和更新：定期检视复盘结果和改进措施的执行情况，并根据需要进行更新和调整。持续改进是一个持久的过程。 文档和分享：将复盘的结果和改进措施进行文档化，并与团队内部分享。这有助于确保所有人都能从中学习，并避免类似的错误再次发生。 培训和意识提升：通过培训和意识提升活动，确保团队成员了解安全事件复盘的重要性，并能够积极参与其中。 父主题： SEC10 安全事件响应

SEC09-01 实施标准化管理日志 对身份防线、网络防线、应用防线、主机防线、数据防线和运维防线等日志实施标准化管理，以监测系统和用户活动，实现日志的统一管理，并确保透明可追溯。 风险等级 高 关键策略 跟踪并监测对网络资源和关键数据的所有访问。通过系统的活动记录机制和用户活动跟踪功能可有效降低恶意活动对于数据的威胁程度。常见的安全日志如主机安全日志、操作系统日志、 堡垒机 日志、 IAM 日志、WAF攻击日志、CFW日志、VPC流日志、DNS日志等。当系统出现错误或安全事件时，通过执行彻底地跟踪、告警和分析，可以较快地确定导致威胁的原因。 确保日志存储时长满足需求。主机和云服务的日志数据上报至云日志服务（LTS）后，在默认存储事件过期后会被自动删除。因此，需要用户根据业务需求配置存储时长。对于需要长期存储的日志数据，应在 LTS中配置日志转储。 对于大型企业，涉及多账号统一安全管理和运营。集中收集来自多云环境、多账号和多云服务产品的日志、告警、配置、策略和资产数据等，提高安全运营和运维效率，实现企业的多账号与资源的统一管理。基于统一管理日志，可支持统一存储、统一分析、统一建模、统一威胁分析、统一编排响应、统一态势报告和统一安全策略管理等。 相关云服务和工具 云日志服务 LTS：使用LTS记录日志数据，快速高效地进行实时决策分析、设备运维管理以及业务趋势分析。 Web应用防火墙 WAF 安全云脑 SecMaster 父主题： SEC09 安全感知及分析

PERF04-03 性能测试步骤 风险等级 高 关键策略 1.确定验收性能指标 对被测系统从用户角色、开发角色、维护管理员等角色出发分析，结合生产环境系统当前情况，识别并定义业务指标、数据指标、资源指标三种维度指标需要达到的目标基线，指导系统能达到以最小的资源占用管理最大的数据并给用户提供最优的体验目标，输出系统各个场景所要达到的SLA。 2.创建测试方案 创建测试方案是指设计适合性能测试系统负载的特定场景或条件的过程，性能测试方案设计要求全面、无遗漏，使用测试设计模板把所有的组网场景要求全覆盖，根据性能测试需求、测试模型、测试组网图，罗列出业务测试要点，逐一去分解测试场景和步骤。创建测试方案以模拟真实的用户行为和系统负载， 这些方案为性能测试人员提供了一种方法来评估服务负载在不同条件下的性能，包括测试环境、测试工具、测试监控项等。 通过测试方案可以复制各种系统负载档位，例如并发用户访问、峰值负载时段或特定场景。 通过测试不同的负载档位，可以识别性能瓶颈并优化部署资源，输出件是可执行性能测试方案。 用户原子行为：识别测试场景，通过识别用户在与服务系统交互时大量执行的步骤和操作，模拟真实的用户行为和系统负载模式。 例如登录、执行搜索、批操场景、导入导出、提交表单或访问特定功能等活动。 将每个方案分解为表示用户与服务系统交互的特定场景步骤和操作。 可以包括页面、执行事务或与系统负载的各种混合场景。 确定数据模型： 确定运行测试方案所需的测试背景数据。 可以创建或生成各种场景、用户配置文件或数据量的实际数据集。 确保测试数据多样化并涵盖不同的场景数据，以提供全面的性能评估。 设计测试脚本： 创建执行定义的测试方案的测试脚本。 测试脚本通常包含一系列操作、HTTP 请求或与服务系统相关的 API 或用户界面的交互。 使用性能测试工具编写脚本，考虑参数化、动态数据处理等因素。 调试脚本，例如脚本错误、缺少或不正确的操作或与数据相关的问题，测试脚本的准确对于帮助确保准确可靠的性能测试执行至关重要。 配置测试变量和参数： 在测试脚本中配置变量和参数，以模拟真实场景请求。 包括多用户登录、查询数据或随机化等参数，以模拟不同的用户行为和工作负载响应。 脚本自动化： 脚本自动化，根据反馈、测试结果或更改要求不断优化和更改测试脚本。 考虑优化脚本逻辑、参数化和错误处理，或添加额外的验证和检查点，配置自动化脚本，迭代测试无需更改脚本。 3.配置测试环境 性能测试环境是指用于开展性能测试活动的环境，为性能测试服务，性能测试环境原则上与生产环境进行对标，在测试过程中需要保持其独立性，尽量避免其它因素对性能测试结果的影响，软件版本、系统组网、硬件规格等要保持与生产环境基本一致。 性能测试环境配置通常要考虑以下因素： 系统组网与架构：系统组网方式如主备、集群、分布式等组网，系统架构分析服务间依赖关系，确定周边依赖服务。 硬件规格：所需服务器的数量、规格以及硬件配置，包括 CPU 主频/核数、内存容量、磁盘类型与容量、存储池类型与容量，网卡带宽等。 软件环境：软件版本与配置，如操作系统版本、服务版本、数据库版本、以及影响性能的相关配置。 4.完成测试设计 在本步骤完成前文确认的系统负载、背景数据量与需要请求的用户数据模型等测试设计。 5.执行测试 使用所选的测试工具进行性能测试，测试涉及查看和记录性能指标、监控运行情况以及查看出现的任何性能问题，同时监控和收集性能指标，例如响应时间、吞吐量、CPU和内存利用率以及其他相关指标。 使用定义的测试方案将工作负载置于预期负载之下。在这些不同的负载条件下进行测试。例如，使用正常、峰值和压力级别等级别来分析各种方案中工作负载的行为。 6.分析测试结果 分析测试结果是指检查从性能测试结果收集的测试结果和记录的监控指标，由此分析服务的瓶颈点，分析确认是性能问题的，需要提单优化。从以下几个方面展开分析： 查看性能指标：查看性能测试期间收集的性能指标，例如响应时间、吞吐量、错误率、CPU 和内存利用率以及网络使用等。分析这些指标以了解服务的整体性能。 确定性能瓶颈：评估性能指标，以确定哪些性能指标是该场景测试的瓶颈点。评估包括高响应时间、资源使用、数据库问题、网络延迟和扩容限制等。确定服务场景的瓶颈点，有助于服务的优化改进与扩缩容处理。 性能关联指标：评估各种性能指标之间的关系和相关性。例如，背景数据量和资源利用率影响服务的响应时间，清楚这些关联关系可以为不同环境下的场景提供有价值的性能指导，在需要扩容的时候知道扩容哪部分节点给服务以数据支撑。 评估验收条件：将测试结果与预定义的验收条件SLA进行比较。评估服务当前性能是否满足生产环境所需的性能要求。如果不满足生产环境性能调用，需要优化服务或者扩容等手段进行处理 7.确定基线 性能基线是产品在系统形成时，所建立的一个基线库，性能基线按照分层原则，建立后通常在版本设计阶段就会归档与发布。基线提供了一个参考点，用于比较一段时间内的性能结果，基线应该是工作负载性能的参考 考虑工作负载目标，并记录性能，以便随着版本迭代比较基线和优化性能。使用这些基线度量作为未来性能测试的基准，并用它们来识别服务系统有无性能裂化。 若要为性能测试建立基线并将其用作未来性能测试的基准，请执行以下步骤： 确定性能指标：确定要度量和约定的性能指标。示例包括： 响应时间，或服务响应请求的速度。 吞吐量，或按单位时间处理的请求数。 资源利用率，例如CPU、内存和磁盘使用率。 记录性能相关的度量值：将测试期间获得的性能指标记录为基线度量值。这些度量与测试前约定的SLA比较值。 比较将来的测试：在后续性能测试中，将性能指标与已建立的基线和阈值进行比较。通过比较，可以识别有可能出现的性能裂化等。 性能基线管理的几个原则与要求： 性能基线不允许随意更改：性能基线已经发布后，则在同一个版本内不允许进行更改，如果要更改则需要与产品相关SE、产品经理对齐，重新进行发布。 性能基线则需要持续继承：性能基线的数值则在每个版本设计阶段进行确认完成，不能出现之前的基线内容全部推翻重来。 性能基线的维护主体：性能基线一经发布，则测试严格按照性能基线要求进行测试与评估。 非性能基线测试则有权进行拒绝验证：对于不合理的非产品基线内容测试则可以进行拒绝验证。 基线不合理内容测试则有权利进行质疑，并且能够根据测试数据、现网应用、客户规范、标准等要求与SE、产品经理进行评审，基线变更等。 父主题： 性能测试

RES13-04 支持主动扩容 当由于计划性活动而导致资源需求增加时，需要支持主动扩容，避免由于资源不足而导致业务受影响。 风险等级 高 关键策略 当发现应用系统业务需要更多资源时，可主动扩展资源以满足需求，而避免影响可用性。典型场景如产品促销前预测会有突发大流量，则可手工进行扩容处理。 华为云服务实例支持主动横向或纵向扩容功能；如对于ECS实例可以通过创建多个ECS实例实现横向扩容，也可升级ECS规格实现纵向扩容；对于RDS实例可升级RDS实例规格实现纵向扩容。 父主题： RES13 过载保护

SEC07-04 静态数据的加密 加密可以防止未经授权的人访问和窃取数据。应该默认对敏感的静态数据进行加密，以确保即使数据遭到未经授权访问或意外泄露，也能保持机密性。 风险等级 高 关键策略 启用默认加密。对云硬盘 EVS、关系数据库 RDS、对象存储服务 OBS、弹性文件服务 SFS等云服务配置默认加密，以自动加密存储的数据。启用RDS、DWS等数据库的加密，可降低拖库、数据泄露带来的安全风险。 针对敏感数据，采取加密、掩码、匿名化等方式进行保护。这样，即使敏感数据被非法窃取，也可降低这类数据泄露的风险。 应该监控加密和解密密钥的使用，并根据数据用途、类型和分类来选择不同的加密密钥。 相关云服务和工具 数据加密服务 DEW：DEW与OBS、云硬盘（EVS）、 镜像服务 （IMS）等服务集成，可以通过密钥管理服务（KMS）管理这些服务的密钥，并对云服务中的数据进行加密，还可以通过KMS API完成本地数据的加密。 父主题： SEC07 通用数据安全

OPS04-04 自动化工程运维任务 在日常开发工作中，尽可能自动化一切，以减轻管理负担并最大限度地减少人为错误。为了最大限度地提高自动化投资的价值，优先考虑简单、程序化且长期的任务。应用自动化并不是一种全有或全无的策略。即使需要人工干预的工作流(例: 决策点)，也可以从自动化中受益。 风险等级 高 关键策略 优先考虑从自动化中受益最多的任务： 专注于高度程序化且容易出现人为错误的任务：这些任务被明确定义，高度自动化，没有增加复杂性的变量，并且作为正常路径的一部分执行。示例包括：重新启动服务器、创建帐户以及将日志传输到数据存储。这些任务可能会按计划发生，作为对事件或监视警报的响应，或者根据外部因素的需要而发生。 可以解放运维工程师的任务：为应用的DevOps团队提供自动服务，通过运行的脚本自动执行运维操作步骤。例如，客户引入多租户解决方案时，数据库管理员经常收到创建新数据库的请求。如果为运营人员构建自助服务门户，则可以让他们自己安全地创建空数据库。 通过自动化显著提升效率的任务：高价值的自动化需要最少的管理开销，并显着提高效率。例如，如果可以通过自动化数据库条目每天为运营团队节省一个小时，那么就可以有更多时间实现自动化做持续改进。 设计建议 管道定义、执行和管理：使用持续集成和持续交付 (CI/CD) 工具（例如 华为云CodeArts Pipeline）自动定义管道及其运行方式. 部署：使用华为云 资源编排 服务 RFS 、Terraform 和 Ansible 等工具来自动化工作负载开发和发布流程。通过使用基础架构即代码 (IaC) 方法，可以使用相同的自动化平台部署并优化基础架构。 测试：许多工具可用于自动化测试过程。这些工具可以减轻质量保证团队的重大负担，并确保测试标准化且可靠。 扩展：使用平台提供的功能和其他工具（例如: 资源编排服务 RFS），在负载增加或减少时自动扩展基础架构。 监控和警报：使用云运维中心 COC和 云监控服务 CES 提供的工具自动注册新部署的资源并配置警报触发的操作，以帮助在出现问题时加快修复速度。 自我修复：使用云监控服务 CES生成的警报来自动执行操作并恢复出现故障的组件或作业。 配置管理：使用编排和策略工具确保所有资源运行相同的配置，并在整个工作负载中强制执行合规性要求。 其他管理任务：使用脚本自动执行重复性任务，例如更新数据库记录或 DNS 记录。 审批：使系统能够根据预定义规则自动做出审批决策，以提高具有审批关口的工作流程的效率。这种方法鼓励使用标准化表格和模板，从而提高流程的效率。在高环境下自动批准可能存在风险。密切关注并测试您的自动批准，以确保定义特定标准来授予批准。 新用户和新员工入职：您可以自动执行与新应用程序用户或新员工入职相关的许多任务，例如数据库更新和凭据创建。 相关云服务和工具 资源编排服务 RFS CodeArts Pipeline CodeArts Deploy 云运维中心 COC 云监控服务 CES 华为云命令行工具服务 KooCLI 父主题： OPS04 自动化构建和部署流程

RES02 备份 对于应用系统中的重要数据，需要提供备份功能，以便在病毒入侵、人为误删除、软硬件故障等场景，能够快速将数据恢复到备份点。 由于容灾通常对数据采用实时复制且没有多备份点，在主数据被误删或误改的情况下，错误数据会同步到备端，从而无法达到数据备份的效果，因此通常不能使用容灾来代替备份。 备份恢复时的RPO指标（即数据丢失量），与最近一个备份时间点相关；不同类型的数据，允许丢失数据量可以不同，即RPO不同；为了保证数据备份的RPO目标，需要采用定期自动备份，而不要依赖人工进行手工备份。 RES02-01 识别和备份应用中所有需要备份的关键数据 RES02-02 自动数据备份 RES02-03 定期进行备份数据恢复 父主题： 高可用设计

可用度及SLO 可用性目标用于衡量应用系统的运行时间和停机时间，其表现形式为应用系统正常运行的时间占总时间（通常是一个月或一年）的百分比（如99.9%），即： 可用度 = 可用时间 / 总时间 * 100% 常见的简单表达方式用“9”的数量或“9”的数量加“5”表示，如“三个9”表示“99.9%”，而“三个9一个5”表示“99.95%”。 系统可用性目标通过服务等级目标（SLO）定义。不同的应用系统对可用性目标是不同的，明确应用系统的可用性目标，对于衡量应用系统的韧性至关重要。常见IT系统SLO示意如下： SLO 每年最大不可用时间 典型IT服务 99% 3.65天 批处理，后台任务，数据抽取 99.9% 8.76小时 内部 知识管理 系统，项目跟踪系统 99.95% 4.38小时 客户账户管理，信息管理 99.99% 52.56分钟 电商，B2B web服务，大流量媒体/内容网站 99.999% 5.26分钟 银行，投资，金融，政府，电信，关键企业应用 系统的可用度依赖于系统内各业务单元的可用度。各业务单元之间典型的可靠性模型有两类： 串联模型：组成系统的所有单元中任一单元的故障都会导致整个系统故障的称为串联系统。 可靠性数学模型： 举例：假定系统存在2个串联单元，每个单元的可用度均为99.9%，则系统可用度为 Rs = 99.9% * 99.9% = 99.8%。 串联系统中系统可用度低于串联系统中任一单元的可用度。为提高系统可用度，设计时需考虑： 尽可能减少串联单元数目 提高单元可靠性，降低其故障率 并联模型：组成系统的所有单元都发生故障时，系统才发生故障的成为并联系统。 可靠性数学模型： 举例：假定系统存在2个并联单元，每个单元的可用度均为99.9%，则系统可用度为 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 ）。 父主题： 可用性目标定义

概念模型 华为云的客户在注册账号后，每个账号下可以创建多个IAM用户。 对于大型企业的客户，可能会管理多个账号，这些账号可以被统一管理。客户可通过一个企业主账号结合多个企业子账号来统一管理账号。 主账号与子账号中都可以再创建更小层级的IAM用户，这些IAM用户分别属于对应的账号，可以帮助账号管理资源。华为云企业中心提供了多个相互独立的华为账号之间形成企业主子账号关联关系的能力。 父主题： 基本概念

SEC02-04 一体化身份管理 在公司范围内构建统一的身份管理系统，统一管理私有云和公有云、公有云上多个账号的用户身份。 风险等级 中 关键策略 在公司范围内构建统一身份管理系统，集中存储用户身份信息。 统一身份管理系统与私有云、公有云平台的IAM系统进行身份联邦，统一身份管理系统中的用户身份可以同时访问私有云和公有云平台。 统一身份管理系统与公司的HR流程结合，当员工入职、调岗和离职时可以触发用户的创建、变更和删除。 针对Landing Zone搭建的云上多账号环境，利用IAM身份中心集中管理多个账号的用户身份，并集中为这些用户配置能够访问多个账号下云资源的权限，无需在每个账号的IAM系统分别创建IAM用户并配置权限，简化多账号环境下身份权限管理的工作量。 统一身份管理系统与IAM身份中心建立身份联邦，这样无需分别与每个账号的IAM系统进行身份联邦。 相关云服务和工具 IAM身份中心 IAM Identity Center 统一身份认证 服务 IAM 应用身份管理 服务 OneAccess 父主题： SEC02 身份认证