华为云用户手册

SEC07-01 识别工作负载内的数据 通过业务流程、数据流动方向、数据分布、数据的所有者等维度，对照合规要求评估数据的敏感度，对数据分级分类。 风险等级 高 关键策略 遵循以下步骤梳理、识别数据： 业务流程分析。 了解业务流程，对照业务流程图，明确在各个环节中产生、处理和存储的数据类型和用途。 与业务部门、开发团队、运维人员等进行交流，获取关于数据的详细信息。 确定数据的分布：需要确定数据存储在哪里，例如云硬盘、数据库、对象存储等。 评估数据敏感度。 确定数据的类型和内容，例如是否包含个人身份信息（如姓名、身份证号、地址等）、财务数据（如银行账号、交易记录等）、商业机密（如产品研发计划、客户名单等）或其他受法规保护的数据； 考虑数据的潜在影响。如果数据泄露或被滥用，会对个人、组织或社会造成多大的危害，包括经济损失、声誉损害、法律责任等。 参考相关的法律法规、行业标准和企业内部的合规政策。不同行业和地区对于敏感数据的定义和要求可能不同，例如医疗行业的患者数据、金融行业的客户交易数据等，都有特定的法规和标准来规范其保护。 结合组织的业务战略和风险承受能力。对于关键业务相关的数据，即使其本身不属于常见的敏感类型，也可能因其对业务的重要性而被评估为高敏感度。 借助数据发现和分类工具，自动扫描工作负载以识别数据。自动识别和分类数据可帮助您实施正确的控制措施。 创建并维护数据清单。将分级分类后的数据整理成清单，包括数据的名称、描述、来源、分布情况、数据敏感度、所属分类级别等详细信息。 相关云服务和工具 数据安全中心 DSC：DSC可根据敏感数据发现策略来精准识别数据库中的敏感数据，并支持从海量数据中自动发现并分析敏感数据使用情况，基于数据识别引擎，对结构化数据和非结构化数据进行扫描、分类、分级，解决数据“盲点”。 父主题： SEC07 通用数据安全

RES07-03 监控到异常后发送 消息通知 当对应用系统监控发现应用异常后，需要向相应的人员和系统发送实时通知消息和告警，以便及时处理。 风险等级 中 关键策略 采用实时快捷的消息通知方式，以便相关人员能及时得到消息。 消息发送人员需要涵盖运维人员，以便及时恢复。 运维人员需要有备份，避免单点风险。 SMN 消息通知服务可依据用户需求主动推送通知消息，方式可为短信、电子邮件等。 CES 、 AOM 、 CTS 、 APM 、LTS等服务均已经对接SMN消息通知服务，在阈值规则发生变化时，可以以邮件或短信等方式通知，以便您在第一时间发现异常并进行处理。 相关云服务和工具 消息通知服务 SMN 云运维中心 COC：支持人员管理、排班管理和通知管理，可以根据通知规则自动将消息发送给要通知的人员。 父主题： RES07 监控告警

SEC05-01 云服务安全配置 安全配置是一个信息系统的最小安全保障，云服务安全配置是云环境最基本的安全保证，是开展安全防护的基础。正确配置云服务可以帮助防止安全漏洞和数据泄露，提高整体系统安全性。如果云服务没有达到安全配置基线要求，云上业务及资产将面临巨大安全风险。 风险等级 高 关键策略 遵循华为 云安全 配置基线指南，包括对不同服务的安全配置建议，例如： 容器安全 ，例如容器安全配置，CCE里不安全的容器配置可能导致容器逃逸问题 系统漏洞，例如操作系统的版本有没有升到最新版，使用版本是否存在漏洞 开放必要的端口，例如系统是否对公网开放22，3306等高危端口 禁止将重要业务数据所在的OBS桶设置为公开桶或者配置为公共可读。 定期执行云服务安全配置的基线检查。 全面性检查：确保基线检查覆盖所有关键的云服务配置项，包括身份认证、访问控制、网络安全等关键配置。 定期与实时检查：设置定期自动检查计划，并提供实时检查功能，以便在需要时立即评估云服务的安全状态。 风险评估：对检查结果进行风险评估，识别不同级别的风险资源，如致命、高危、中危、低危和提示。 相关云服务和工具 华为云服务的安全特性：在云服务模式下，如何保障云上安全，成为大多数企业和客户的首要关注问题。华为云致力于保障其所提供的IaaS、PaaS和SaaS各类各项云服务自身的安全及基础设施安全，同时也为致力于为客户提供先进、稳定、可靠、安全的产品及服务。文档中说明了如何配置华为云服务以满足您的安全性目标。 华为云安全配置基线指南 配置审计 Config 安全云脑 SecMaster：使用安全云脑对云服务安全配置基线进行基线检查，持续保护客户的云服务安全。 企业主机安全 HSS：最新版本支持包含主机安全和容器安全（原CGS服务）的特性 父主题： SEC05 运行环境安全

SEC10-04 安全事件演练 安全事件演练是一种模拟性的活动，旨在让组织成员在一个模拟的安全事件场景下进行实际操作和应对，以测试和提高其应对安全事件的能力。通过安全事件演练，组织可以评估其安全事件响应计划的有效性，发现潜在的问题并进行改进，提高团队的准备性和反应能力。 风险等级 高 关键策略 按照“三化六防”（实战化、体系化、常态化，动态防御、主动防御、纵深防护、精准防护、整体防护、联防联控）的安全要求，实战化攻防演习将成为常态，以攻促防是实现精确防御、精准防护的有效方法。 事件演练为了高度模拟真实攻击场景，其攻击链与实际的网络战一样，包括信息搜集、边界突破、武器投送和横向扩散等，在实际攻击当中，利用率最高的是弱口令（简单口令、重复口令）爆破、流行漏洞利用和钓鱼。 攻防演习是有规则的，约定开展时间、确定靶标系统、设定战果分数、限制影响面大小等，但实际攻击没有规则，所以常态化的安全建设要求必须高于攻防演习特定要求，才能真正提升整体能力。 攻击战法分析： 0day攻击、后门利用、VPN漏洞、邮件钓鱼、社工。随着攻击强度的提升、攻击资源的投入，0day攻击的占比增加、社工手段的多样性增加，大部分攻击都是内网渗透、正面入侵很少。整体攻击战法更贴近于真实的网络入侵，符合“以攻促防”的目标。 防守要点变化： 从单点防护开始转变为多点协同防护；从大范围的黑名单拦截转变为有技巧性的联动防护；从边界的纵深拦截延伸到内网的异常监控；从被动的监控防御延伸到主动的诱捕溯源。 用户需求变化 产品层面：除传统的入侵防御、WAF和漏扫之外，对资产测绘、APT检测、安全情报和蜜罐的需求在不断增加。 服务层面：除保障期间的安全加固和值守服务外，对日常的安全巡检、安全培训和内部攻防演习需求不断增加。 父主题： SEC10 安全事件响应

PERF06-02 性能劣化自动定界定位 风险等级 中 关键策略 通过建立的分层性能模型，判断系统是否会出现性能劣化的情况。当出现劣化事件时，需要通过自动化手段快速定位定界发现根因。可以通过应用模型建设三维的拓扑，把架构-空间-时间数据关联起来。这里面的关键是架构模型的建立及分层指标的聚合可视化能力，需要依赖持续的资源治理和 数据治理 。 相关云服务和工具： 优化顾问 OA 云监控服务 CES 应用运维管理 AOM 父主题： 性能看护

SEC05-06 使用托管云服务 将计算、数据库、存储等资源使用华为云云服务进行托管，避免自行构建增加的开发和运维成本。 风险等级 低 关键策略 实施用于托管资源的服务以便在责任共担模式中减少安全维护任务。例如使用华为云的数据库服务而不是自建关系型数据库的实例。 使用Serverless架构的云服务，将计算资源的安全交给华为云处理，减免了用户自行运维服务器带来的工作量和人为错误，减少了安全漏洞的风险。这样，用户能够将更多精力集中在业务逻辑和应用的安全性上。 相关云服务和工具 云数据库 RDS for MySQL 云数据库 GaussDB 函数工作流 FunctionGraph 云容器实例 CCI 事件网格 EG 父主题： SEC05 运行环境安全

COST07-02 释放闲置资源 风险等级 中 关键策略 持续监控资源的闲置情况（如ELB无流量，EVS盘无挂载，EIP没有绑定到虚机），释放资源，或者监控资源使用只是在某个固定的时间(如每天的十二点，每个周末），可以使用自动化的方式定期申请资源，使用后释放 相关服务和工具 华为云优化顾问，提供成本维度的巡检，识别E CS 、EIP、EVS、ELB等闲置资源。 华为云成本中心，除识别ECS、EIP、EVS、ELB等闲置资源外，还基于历史消费提供节省评估。您可参考系统给出的利用率信息、预估月度节省，结合业务团队意见，采取资源优化行动。 父主题： COST07 管理和优化资源

概念表 概念 解释 韧性 (Resilience) 系统从故障中保持在已知运行状态（甚至降级）的能力。在遭遇故障后快速恢复核心功能和数据，且在业务需要的时间窗内恢复到有效运行状态。 可靠性 (Reliability) 产品在规定的条件下和规定的时间内完成规定功能的能力。它的概率度量称为可靠度。 可用性 (Availability) 产品在任意随机时刻需要和开始执行任务时，处于可工作或可使用状态的程度。它的概率度量称为可用度 云服务指标 SLI Service level Indicator，面向服务的指标，如：请求响应成功率 云服务目标 SLO Service Level Object，面向服务的目标，如：一定时间范围内的请求响应成功率大于XX%，或正常运行时间的百分比 云服务协议等级 SLA Service Level Agreement，面向用户的协议等级，涉及不满足时的补偿 数据恢复点目标 RPO Recovery Point Objective，主要指的是业务系统所能容忍的数据丢失量 恢复时间目标 RTO Recovery Time Objective，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。 业界对韧性没有统一的定义。狭义韧性，指的是自动或快速从故障中恢复运行的能力；而广义韧性，除了从故障中恢复运行的能力外，还包括故障容忍能力。故障容忍（fault tolerance，简称“容错”），是使系统在其某些组件中出现一个或多个故障时能够继续提供服务的能力，从客户的角度来看，该服务仍能完全正常运行，或可能降级运行。 而可靠性同样分为狭义可靠性与广义可靠性。狭义可靠性工程的目标是提高系统无故障运行的能力，即提高可靠性。而广义可靠性工程的目标除了提高可靠性外，还包括提高从故障中恢复运行能力，即维修性（maintainability），同时还包括其他围绕故障展开的各种能力，如可用性（availability）、保障性（supportability）等。 因此，从广义韧性与广义可靠性的定义来看，并没有显著区别。只是可靠性和韧性的侧重点不同。可靠性工程的目标是尽可能减少系统中的故障，保证系统无故障运行。而韧性工程，接受故障总会发生的现实，关注的是如何降低故障带来的损失以及如何从故障中恢复。 父主题： 基本概念

OPS06-03 制定和实施可观测性指标 风险等级 高 关键策略 指标是对时间周期内的测量数据的数值表示。可观测性指标是围绕发现率、定级准确率、定界时长、覆盖率、有效率、 一致率打造可观测能力，将可观测设计规范统一发布，统一设计要求与运维管理要求。 设计建议 整体技术方案会变成标准并进行发布，各个业务系统架构师在设计时遵循这套标准，这样可以保证能力能够从设计态开始，包括运行态、高可用架构等场景中得到应用。 可观测指标可以通过监控工具来实现，并允许在发生异常时发送警报。有很多监控工具可以使用，例如Prometheus、Grafana、Zabbix等，以及华为云提供的 云监控 服务CES。这些工具可以定期收集指标，提供可视化的指标报告，并且可以发送警报，以帮助组织及时发现问题。 可参考CES的最佳实践，https://support.huaweicloud.com/bestpractice-ces/ces_14_0002.html。 父主题： OPS06 可观测性体系

SEC06-03 实行代码白盒检视 代码白盒检视是一种软件质量保证方法，通过检视源代码的内部结构、逻辑和实现细节，以确保代码符合最佳实践、编程规范和安全标准。在代码白盒检视中，团队成员会检查代码的质量、安全性、可读性等方面，以发现潜在的问题和改进空间。 风险等级 中 关键策略 制定检视计划： 确定检视的频率和时间安排，以确保代码检视是持续的活动。 确定检视范围，例如可以是每次提交、每个功能完成后，或者定期的大规模检视。 培训团队成员： 提供培训以确保团队成员了解如何进行有效的代码检视。 确保团队了解代码检视的目的和重要性，以及如何识别常见问题和潜在的安全漏洞，建议将常犯的TOP问题整理成清单，在开发人员编写代码后自检以及他人检视时进行对照。 选择合适的工具： 使用代码检视工具来辅助检视过程，例如静态代码分析工具，以帮助发现潜在的问题。 确保团队熟悉并能有效使用这些工具。 设定清晰的标准和准则： 制定明确的代码检视标准和准则，以便检视者能够一致地评估代码质量。 着重关注安全性方面。 分配角色和责任： 确定谁将参与代码检视，例如开发人员、架构师、安全专家等。 确保每个团队成员了解其在检视过程中的角色和责任。 记录检视结果： 记录检视过程中发现的问题、建议和决定，以便后续跟踪和改进。 确保问题得到适当的跟进和解决。 鼓励合作和讨论： 鼓励团队成员之间进行合作和讨论，分享经验和观点，以提高检视质量。 创建开放的氛围，使团队成员能够提出问题和建议，促进共同学习和成长。 持续改进： 定期评估代码检视过程，收集反馈意见，并进行必要的调整和改进。 着眼于提高检视效率和质量，以确保团队不断提升代码质量和安全性。 父主题： SEC06 应用安全性

Kafka性能优化 Kafka性能优化 优化客户端配置 生产者配置建议 可参考配置建议。 消费者配置建议 参数 推荐值 说明 max.poll.records 500 消费者一次能消费到的最大消息数量，默认为500，如果每条消息处理时间较长，建议调小该值，确保在max.poll.interval.ms时间内能完成这一批消息的处理。 max.poll.interval.ms 300000 两次消费拉取请求允许的最大时间间隔，默认为300秒，超过这个时间会认为消费者异常。 fetch.min.bytes 根据业务调整 默认为1，每次FETCH请求最少返回数据量。增加该值可以提高吞吐量，同时也会产生一定延迟。 观测性能指标 Kafka提供了以下性能相关监控指标，从这些指标可以帮助分析消息堆积、分区数据倾斜、流量倾斜等问题。 指标ID 指标名称 指标说明 broker_disk_usage 磁盘容量使用率 该指标为从Kafka节点虚拟机层面采集的磁盘容量使用率。 broker_cpu_core_load CPU核均负载 该指标为从Kafka节点虚拟机层面采集的CPU每个核的平均负载。 broker_memory_usage 内存使用率 该指标为Kafka节点虚拟机层面采集的内存使用率。 broker_cpu_usage CPU使用率 统计Kafka节点虚拟机的CPU使用率。 group_msgs 堆积消息数 该指标用于统计Kafka实例中所有消费组中总堆积消息数。 topic_messages_remained 队列可消费消息数 该指标用于统计消费组指定队列可以消费的消息个数。 broker_messages_in_rate 每秒消息生产速率 统计Kafka节点每秒生产速率。 broker_connections 连接数 统计Kafka节点连接数。 优化数据分区 Kafka将Topic划分为多个分区，所有消息分布式存储在各个分区上。每个分区有一个或多个副本，分布在不同的Broker节点上，每个副本存储一份全量数据，副本之间的消息数据保持同步。Kafka的Topic、分区、副本和代理的关系如下图所示： 在实际业务过程中可能会遇到各节点间或分区之间业务数据不均衡的情况，业务数据不均衡会降低Kafka集群的性能，降低资源使用率。 业务数据不均衡原因 业务中部分Topic的流量远大于其他Topic，会导致节点间的数据不均衡。 生产者发送消息时指定了分区，未指定的分区没有消息，会导致分区间的数据不均衡。 生产者发送消息时指定了消息Key，按照对应的Key发送消息至对应的分区，会导致分区间的数据不均衡。 系统重新实现了分区分配策略，但策略逻辑有问题，会导致分区间的数据不均衡。 Kafka扩容了Broker节点，新增的节点没有分配分区，会导致节点间的数据不均衡。 业务使用过程中随着集群状态的变化，多少会发生一些Leader副本的切换或迁移，会导致个别Broker节点上的数据更多，从而导致节点间的数据不均衡 使用数据压缩 在客户端CPU资源情况可控的情况下，使用压缩算法对数据进行压缩。 常用的压缩算法包括：ZIP，GZIP，SNAPPY，LZ4等。选择压缩算法时，需考虑数据的压缩率和压缩耗时。通常压缩率越高的算法，压缩耗时也越高。 压缩方式 压缩比 客户端CPU占用 服务端CPU占用 磁盘占用 broker带宽占用 gzip 中 中 低 中 低 lz4 中 中 中 中 中 zstd 高 中 低 低 低 snappy 低 高 高 高 高 如果追求高TPS，建议采用lz4压缩算法；如果追求较低的网络I/O或希望较低的客户端/服务端CPU占用，建议采用zstd压缩算法。这里通常推荐使用lz4压缩算法，同时不建议使用gzip算法，因为它会是一种计算敏感的压缩算法。同时针对一批数据（batch)消息压缩，更好的运用批处理可以获得更高的TPS。 父主题： 消息队列性能优化

RES09-02 客户端需要根据综合评估是否要重试 当客户端请求超时或收到错误响应时，客户端需要决定是否重试；重试有助于客户端在请求失败时，通过重复消息来获得预期的结果，避免业务失败，但也会消耗更多的服务器时间来获取所需的成功响应。 风险等级 高 关键策略 请求超时，可能是链路闪断或其他临时性故障导致消息丢失，可以进行重试。 根据错误响应码进行有针对性的重试；对于临时性故障，如错误码指示为系统繁忙时，可等待一段时间后重试，否则无需重试。 请求SDK中内置了消息重试时，客户端无需重复重试。 多层业务栈一般只在源端重试，避免逐层重试。 父主题： RES09 故障重试

RES06-02 面向所有故障进行检测 针对所有故障场景，都需要能自动检测，以便及时发现和恢复故障。 风险等级 高 关键策略 所有故障都必须有检测。 支持按不同维度进行故障检测，如Region、AZ、服务、方法、实例或容器ID等，检测维度与故障恢复方式对齐。 检测到故障后需及时告警或自动恢复。 针对具体故障进行检测时，根据检测的类型通常可以分为资源检测、功能检测和业务检测。 资源检测：云环境中一般指虚拟化后的物理硬件资源及其对应的软件资源，具体包含CPU、内存、网络和磁盘资源等。 功能检测：对组成产品系统的各个内部模块对象进行检测的过程，确定模块功能是否满足设计的需求。当产品系统的功能发生故障时，对外的呈现即为功能输出和预期不一致。在产品上线之前，通过功能相应接口，开发者和测试人员需要多次检测以保证模块功能的正确性。功能检测可以使用传统日志跟踪技术、调用链技术来进行检测，如华为云APM。 业务检测：模拟用户的业务操作过程，获得完成业务的操作过程性能数据和操作结果数据；业务检测使用拨测技术来完成检测，由于拨测需要占用网络资源，对于长周期拨测，一般选择在空闲时间段进行，属于抽样检测，而如果是短周期拨测（如5分钟周期），则可例行进行；与功能检测的联系是，业务检测也可以采用调用链来完成。 故障检测方法根据类型有很多种，下面是一些在高可用性系统中常用的故障检测方法。 数值范围检查：在大多数应用中，一个操作的结果必须处于某个范围之内。对这些边界条件可以进行一些测试来验证数据是否满足预期要求。 数据完整性检查：每当数据被从一个单元传递给另一个单元时，该数据可能会被破坏。对于在硬件单元间传递的数据尤其如此。然而，由于软件层可以隐藏本地内存传送和跨远程链路的传送间的差异，因此需要在多个点进行数据完整性检查。可以采用很多方法来验证数据的完整性，其中大多数方法都依赖于冗余或者包含在数据中的摘要信息。有些方法采用足够的冗余，不仅能检测错误，而且能纠正错误。但大多数方法中都只包括足够的额外信息来检测数据是否有效。典型的方法如奇偶校验和CRC（循环冗余校验）。 比较测试：当系统具有冗余时，可以使两个系统并行进行计算，然后对结果进行比较，如果结果不匹配则认为发生了故障。这种概念也称为表决。比较可以在系统的任何层次上进行，包括在一条内存总线上的cycle by cycle的比较，到最终发送到网络上结果的比较。 时间检测：时间检测是故障检测的一种简单形式。如果一个事件预期应在某个时间段内发生，而却没有在该时间段发生，就检测到了一个故障。时间检测的一种特殊方法通常称为心跳方法。它采用以某个规定的周期频率执行的某些类型的消息握手。该技术可以用于验证单元或子系统是否仍然能够维持某些等级的功能。 父主题： RES06 故障检测

概述 本章节以典型Web应用为例，介绍不同可用性目标要求下部署的典型架构示例。针对每种场景，从以下几个维度进行设计，来达成可用性目标。 类别 应用可用性影响 冗余 应用内组件的高可用能力，在应用内部分节点故障时业务自动恢复能力 备份 应用数据被破坏的情况下的恢复能力 容灾 在Region/AZ/IDC或其他云站点发生灾难的情况下的恢复能力 监控告警 应用系统故障后的检测和告警能力 弹性扩缩容 应用容量不足时的自动恢复能力 变更防差错 变更对应用业务中断的影响 应急恢复处理 应用在故障情况下的应急恢复能力 父主题： 参考架构

SEC01-03 梳理资产清单 梳理工作负载涉及的服务器、IP地址、 域名 、数据库、证书等全量云资源的资产清单，给资源打上标签，从而在出现安全事件时，能快速定位到有安全风险的资源。 风险等级 高 关键策略 设计态与运行态一致性：对照设计态的架构图、架构文档实施云服务资源。工作负载运行时的架构始终保持与设计态一致。 自动化资产盘点：使用安全云服务或工具来自动发现和记录云上资源，包括主机、存储、数据库、网络等。这样可以确保资产清单的及时性和准确性。 标签和元数据：使用标签和元数据来对云资源进行分类和描述，以便更好地组织和管理资源清单。通过标签可以快速识别和过滤资源，有助于监控和安全审计。 相关云服务和工具 解决方案工作台 InnoStageWorkbench：使用解决方案工作台辅助进行云上架构的可视化设计。 安全云脑 SecMaster：安全云脑支持对云上资产全面自动盘点，也可灵活纳管云外各种资产，点清所有资产，并呈现资产实时安全状态。 配置审计 Config 标签管理服务 TMS 父主题： SEC01 云安全治理策略

SEC08-05 数据使用、留存和处置合规性 数据使用、留存和处置的合规性是指数据处理者在处理个人数据的过程中，包括数据的使用、保留和销毁阶段，需遵守相关的法律法规和隐私保护准则，确保数据处理活动符合法律规定并尊重数据主体的权利。 风险等级 高 关键策略 使用个人数据前必须获取数据主体授权，使用范围及方法不能超出收集目的。 系统应将隐私保护的功能默认设置成保护状态。 使用个人数据过程中，必须保证个人数据的安全，如记录运营运维阶段对个人数据增删改、批量导出等操作。 用于问题定位的日志中记录个人数据遵循最小化原则。 对于数据控制者，数据主体撤销同意之后，产品必须禁止继续收集和处理其相应个人数据。 对于提供用户画像的系统应为用户提供退出用户画像分析的机制。 相关云服务和工具 数据安全中心DSC：用户可以通过DSC的预置脱敏规则，或自定义脱敏规则来对指定数据库表进行脱敏，DSC支持RDS，ECS自建数据库等云上各类场景。另外，DSC可基于扫描结果自动提供脱敏合规建议，支持一键配置脱敏规则。 数据库安全服务 DBSS：使用数据库安全服务DBSS进行数据脱敏。当需要对输入的SQL语句的敏感信息进行脱敏时，客户可以通过开启DBSS的隐私数据脱敏功能，以及配置隐私数据脱敏规则来对指定数据库表以及来自特定源IP、用户和应用的查询进行脱敏。 父主题： SEC08 数据隐私保护

PERF03-06 选择合适的消息队列 风险等级 中 关键策略 三种不同版分布式消息服务的适用场景如下： Kafka：兼容开源Kafka，适用构建实时数据管道、流式数据处理、第三方解耦、流量削峰去谷等场景，有大规模、高可靠、高并发访问、可扩展且完全托管的特点。 RocketMQ：兼容开源RocketMQ，提供顺序、延迟、定时、重投、死信、事务与会话消息等功能，适用电商、金融场景。 RabbitMQ：兼容开源RabbitMQ，支持广播、事务消息、消息路由、死信队列、优先级队列等，适用于秒杀、流控、系统解耦等场景。 详细版本对比可参考官方文档。 相关云服务和工具： 分布式消息服务Kafka版 分布式消息服务RocketMQ版 分布式消息服务RabbitMQ版 父主题： 选择合适的应用中间件云服务资源

RES12-01 组建应急恢复团队 为了应对紧急故障场景，需要组建应急恢复团队，明确责任人，并进行培训。 风险等级 高 关键策略 组建应急恢复团队：其中包括应急恢复主席及所有组件及关键依赖项的恢复责任人。 应急恢复主席：在出现问题后及时组织应急恢复团队进行快速恢复处理。 组件或关键依赖项运维责任人：负责问题定位和应急恢复处理。 制定应急恢复管理方案：所有应急恢复团队人员都需要进行应急恢复培训，熟悉应急恢复处理流程和恢复方法。 父主题： RES12 应急恢复处理

RES03-03 对接容灾仲裁，支持自动切换 针对有状态的主备类型业务，在跨AZ部署并支持自动切换时，需要对接容灾仲裁，以避免出现双主或双备，从而在AZ间链路中断的情况下，业务能自动切换到一个AZ提供服务而不受影响；对于集群类业务不涉及。 风险等级 高 关键策略 面向有状态主备类型业务提供容灾仲裁，站点间链路中断不双主，不破坏数据完整性。 应用内所有相关组件对接一致性仲裁，在链路中断的情况下所有组件均能切换到同一个站点，实现端到端的业务可用性 父主题： RES03 跨AZ容灾

RES04 跨Region/跨云容灾 为了预防区域级灾难发生，或业务跨云容灾需求，需要构建容灾系统提供较为完善的数据保护与灾难恢复能力，以便在站点级灾难发生时，可以保证生产系统的数据尽可能少的丢失，业务系统能在最短时间内由灾备中心接替，恢复业务系统的正常运行，将损失降到最小。 对于跨Region容灾场景，应用系统可在多个Region中部署，并将数据从一个Region复制到另一个Region，以便在发生地区级服务中断或数据丢失时可进行灾难恢复。 对于跨云容灾场景，当应用系统已部署在IDC或其他云中，可以在华为云中另外部署一套系统并将数据从IDC或其他云复制到华为云中，以便在发生整IDC或整朵云服务中断或数据丢失时可以进行灾难恢复。 RES04-01 定义应用系统的容灾目标RPO与RTO RES04-02 部署容灾系统以满足容灾目标 RES04-03 容灾恢复过程自动化 RES04-04 定期进行容灾演练，以检查恢复能否满足容灾目标 父主题： 高可用设计

高可用设计 单点故障会导致整个系统崩溃、主要功能受到影响、任务延误的系统轻度损坏或存在较大的故障隐患，因此系统的高可用设计非常关键。 高可用设计的主要手段是冗余，甚至是多级冗余的组合，包括异地容灾方式保证灾难情况下无单点： 冗余机制：只要条件允许，需要考虑关键组件的冗余，甚至是多级冗余的组合（例如：1+1冗余、n+1冗余、N-Way冗余等） 异地容灾：例如，两地三中心，保证灾难的情况也可以提供业务。 数据冗余：可以通过定期备份和多副本备份等方式实现以提高数持久度，并确保数据一致性。 冗余的增加，意味着成本的增加；因此在应用高可用设计时需要综合考虑冗余对成本的影响。

故障快速恢复 故障恢复指恢复产品执行规定功能的能力，一般情况下恢复越快影响越小。 结合业务情况，综合考虑技术实现难度、技术方案复杂度、成本等设计合适的故障恢复方案： 自动恢复：对于影响业务的故障，系统应尽可能自动恢复自愈，如保护倒换、局部复位或系统服务等。 优先恢复：优先对故障发生概率高、故障影响大的故障进行恢复。 分级复位：提供分级复位设计，尽可能在更小级别进行复位，以减少对业务的影响。 无耦合恢复：尽可能做到系统局部故障或各部件启动顺序不影响系统成功启动。 分层保护：系统故障保护要考虑网络分层，下层的故障保护倒换要比上层灵敏，防止系统出现乒乓倒换。 通过检测系统运行状态，或监控系统载关键指标，来判断系统是否发生故障，并针对故障可进行自动恢复处理。 可以通过故障分析方法分析各种故障模式、影响及危害，设计对应的可靠可用方案，提供冗余、隔离、降级、弹性等能力；并通过故障注入测试（FIT）验证可靠可用方案的有效性，最大程度提高业务的可靠性和可用性。 对于某些故障，即使通过各种技术手段进行冗余和自动恢复处理，但仍会导致业务中断，需要人工干预，如备份恢复或灾难恢复处理，因此需要建立高效的故障应急恢复处理流程和平台，以便在故障发生时，能快速恢复业务，减少故障影响。

过载控制 在系统请求超过系统容量时，会由于资源饱和而导致系统请求失败，在云中，可以监控系统和工作负载的利用率，来自动添加或删除资源，以维持最佳级别来满足业务需求，而无需过度配置或配置不足。 控制业务流量一般通过动态资源管理来实现，不建议简单的使用静态门限来达到防过载的目的，有可能造成资源大量浪费，过载设计应该考虑以下方面： 动态限流：根据系统资源消耗情况动态调整流控门限。 弹性扩缩容：自动检测系统资源利用率，自动进行添加或删除资源。 先负载均衡后流控：多个并行处理单元场景下，优先考虑负载均衡，避免单个处理单元资源受限导致业务受损；然后进行过载控制保护，使得整个系统的处理能力最大化。 及早控制：系统过载时，应尽可能在业务流程处理前端或业务处理较早的处理模块或底层协议层次上控制业务接入，避免中间控制带来不必要的性能消耗。 优先级保障：系统过载时保证高优先级的业务能够优先获得资源，优先得到处理，从而保证社会效益最大化。

变更防差错 当对系统进行升级部署、配置变更时，需要防止变更过程中由于人因差错导致系统和业务受损或失效。 通常采用防呆的方式来减少人因差错。防呆是一种预防矫正的行为约束手段，运用防止错误发生的限制方法，让操作者不需要花费注意力、也不需要经验与专业知识，凭借直觉就可准确无误地完成操作，在许多场景下可以提升效率和使用体验，也防止损坏更换的成本，因此优良的产品中防呆设计极为基础而普遍。 变更防差错通常采用以下方案： 角色约束：通过权限控制设计预防对不同角色的配置范围进行约束，避免越权配置导致错误。 查改分离：通过产品界面设计将配置界面分层分级，查看与修改分离等降低人为配置失误风险。 配置校验：通过配置生效机制设计确保在配置生效前进行必要的检查，避免错误配置生效。通过使用自动化方式进行配置变更处理，可减少人因输入错误的可能。 删除保护：在删除资源时增加保护机制，防止误删，如：删除前运行状态检查保护，资源锁定防止误删除，回收站机制等。

故障全面检测 故障检测是故障管理的前提，检测全面与检测快速都很重要，通常情况下故障检测全比故障检测快重要。 故障检测涉及以下方面： 检测范围：识别并跟踪检测所有组件，有重大影响的故障模式需要重点检测。 亚健康检测：对不引起系统故障却导致系统或服务KPI下降的亚健康异常需要能检测，如网络时延变大、磁盘变慢、内存泄露等亚健康故障。 备用检测：冗余系统中，主备用模块的故障都需要检测，避免静默故障。 有特殊寿命器件：应及时监控有特殊寿命（如本地硬盘）要求的期间健康状态，通过提前预警采取维护错误，避免故障的突然发生造成严重影响。 检测速度：需要根据业务综合要求，确定合适的检测速度。 检测影响：故障定时检测的周期，需综合考虑对CPU占用率的影响和检测延迟对业务恢复速度的影响。 检测模块要简单：故障检测系统、模块要比被检测系统、模块简单。 在检测到问题后，需要通过监控系统及时发现，迅速处理。

PERF04-02 选择合适的测试方式 风险等级 高 关键策略 性能测试的常见方式如下，需要注意的是，各种测试方式并不是正交的，而是有耦合关系的： 性能验收：性能验收测试的运行环境必须是确定的，验证系统在确定的场景条件下是否达到了其宣称的能力规格。 负载测试：是在被测系统上进行负载阶梯加载，直至摸到系统性能极限，一般用来测试系统性能容量或调优。 压力测试：是检查系统处于超负载压力下的性能表现，可以考察系统的流控机制和极限场景下的性能。 长时间稳定性测试：该测试需要在负载压力下进行，是考察性能表现稳定性的重要手段，经常结合压力测试开展。 配置测试：通过对被测系统软硬件配置的调整以及业务模型调整，了解不同配置对系统性能的影响，从而找到系统资源的最优分配原则、不同业务模型的性能趋势。 并发测试：通常通过构造多用户或多任务并发的手段来暴露可能隐藏的进程死锁、资源泄露或其他性能问题。 相关云服务和工具 性能测试 CodeArts PerfTest 父主题： 性能测试

OPS01-02 规划标准化的运维组织 风险等级 高 关键策略 承载卓越运营，应该建立适应您实际的运维组织。运维组织的团队之间具有明确的流程，规定了团队之间的协作方式，例如规定不同团队的响应时间、服务级别目标（SLO) 或服务等级协议(SLA），同时应该记录团队间沟通信息，确保有足够的数据用于后续的改进。 例如一种运维组织设计是：将运维组织分为一线、二线和三线阶梯型运维支持团队，一线受理客户的服务请求，第一时间将大部分的服务请求闭环。二线处理一线升级的服务请求和监控发现的客户的问题，按照SLA完成闭环，涉及到软件版本缺陷类问题升级到三线进行解决，大部分时间处理告警、事件和故障的恢复，其余时间开展转维验收、应急预案与演练等主动运维活动，对现网的稳定性和可用性负责。三线聚焦解决软件版本缺陷问题。 此外也可以使用DevOps模式，由开发工程师直接运维系统，而保留一个小而精干的卓越运营使能团队，用于负责组织整体的卓越运营流程改进和相应的流程工具落地。 无论如何设立组织，应该确保具有一个整体的流程，在流程中的每个团队和成员都有自己明确的责任。 同时可以使用明确的方式（如收集运营/运维数据）分析团队工作对业务成果的影响，从而可以在实际工作中确定不同任务的优先级，并适时改进。 父主题： OPS01 建立持续改进的团队文化和标准化的运维体系

RES11-02 压力负载测试 通过施加超出系统容量的业务压力，验证云服务的过载保护、业务隔离和优雅降级等能力。为全面验证系统整体的容量规划和业务依赖，云服务应用通常采用全链路压测进行测试。 风险等级 高 关键策略 模拟大量接口消息进行压力测试。 模拟各种业务场景进行压力测试。 持续自动测试。 性能发生偏差时自动告警，以便及时定位和处理。 相关云服务和工具 性能测试 CodeArts PerfTest：针对HTTP/HTTPS/TCP/UDP/HLS/RTMP/ WEBSOCKET/HTTP-FLV等协议构建的云应用提供性能测试的服务，其支持快速模拟大规模并发用户的业务高峰场景，通过自定义报文内容、时序、多事务组合等复杂场景，帮助用户测试验证业务高峰下的服务表现。 父主题： RES11 可靠性测试

RES08-03 减少被依赖项故障的影响 被依赖项自身的可用性需要增强，以减少对依赖它的组件的影响。 风险等级 中 关键策略 对于被依赖项本身，为减少由于服务故障或运行缓慢对依赖它的组件的影响，需要考虑使用以下技术和原则： 减少被依赖项本身的外部依赖。 优化性能，减少消息响应时延和负载。 使用优先队列，优先处理高优先级用户的请求，以便在流量过载时不影响应用系统的核心功能。 流量过载时支持功能逐步降级。 被依赖项本身的功能受损时，提供缺省处理，以便应用系统仍可继续正常运行；由于缺省处理可能与实际配置有差异，此时需要告警以便通知系统管理员解决问题。 父主题： RES08 依赖减少与降级

SEC08-03 数据主体的选择和同意 数据主体的选择和同意是指在个人数据被收集、处理或使用之前，数据处理者需要获得数据主体（个人）的明确同意，并且数据主体有权选择是否同意其个人数据被处理的过程。 风险等级 高 关键策略 收集或使用个人数据前，须明确提示用户，并获得用户的同意，并且允许用户随时关闭对个人数据的收集和使用。 从数据主体系统中传出包含个人数据的错误报告之前，必须提供机制告知数据主体，并获得其同意。 若需要将个人数据用于营销、用户画像、市场调查，数据控制者和设备供应者必须提供机制单独获取数据主体明示同意，并提供随时撤销同意的机制。 设置或读取在数据主体系统上的Cookie前（如用于营销或广告），应提供获取数据主体同意及撤销的机制。 修改用户个人空间的行为（如系统或应用配置变更、下载软件、对用户系统或软件升级），须得到用户的同意。 对未成年人提供服务或收集了包含年龄信息的个人信息时，需要实现从未成年人的监护人处获取同意的功能。 数据控制者应提供对用户的同意和撤销同意行为进行记录的机制。 父主题： SEC08 数据隐私保护