华为云用户手册

OPS03-01 推行开发者测试 风险等级 高 关键策略 开发者测试是现代软件工程中非常重要的一环，一般而言，开发者的测试代码可以在本地，或者构建阶段反复多次执行，依赖低，也是在软件系统运维之前成本最低的发现软件问题的方式，尤其是各种异常场景或者用户输入，开发者测试的过程实际上“强制”了开发者去思考线上业务可能出现的场景，从而有利于减轻后续运维阶段系统的负担。 此外，云上的软件是不断演进和重构的，很多时候我们不敢修改已有系统代码的原因，就是不知道它的影响范围，担心产生某种程度上的蝴蝶效应，影响了其它模块而造成线上系统的问题，有了开发者测试之后，只要在改完代码后运行一下测试就知道改动对整个系统的影响了，从而可以让我们放心的重构和演进代码。 同时，应该有一个适用于您软件的开发者测试标准，如代码覆盖率和分支覆盖率。 父主题： OPS03 完备的测试验证体系

COST08-01 按地域规划应用架构 风险等级 中 关键策略 国家已启动“东数西算”工程，将东部发达地区的数据，传输到西部算力资源丰富的地区进行运算、存储。西部数据中心综合成本有明显优势，低PUE低能耗，如贵阳资源价格比广州上海等区域低10%左右。企业可将灾备、离线分析、转码、运维等对网络要求低的系统部署在贵阳、乌兰察布，降低资源成本。 可以关注华为云新推出的云区域以及相关的服务，考虑多Region部署方案。 相关服务和工具 布局优化可以参考华为云不同Region的算力价格，尤其乌兰察布和贵阳等Region 父主题： COST08 进行架构优化

OPS06-06 实施分布式跟踪 Trace是一系列因果相关的分布式事件的表示，这些事件编码了流经分布式系统的端到端请求流。 风险等级 高 关键策略 当系统出现问题时，需要能够追踪系统中每个组件的行为和交互情况。通过在系统中实现分布式跟踪，可以快速定位问题并进行有效的故障排除。 设计建议 链路跟踪可以通过在系统中添加跟踪标识符来实现。当请求进入系统时，标识符将被添加到请求中，并在整个系统中传递。每个组件都可以将标识符添加到它们的日志中，以便在出现问题时进行故障排除。分布式跟踪可以使用开源工具Jaeger、Zipkin、skywalking或CAT等,华为云 APM 提供了调用链观测能力。 可参考APM最佳实践 父主题： OPS06 可观测性体系

COST02-01 建立云预算与预测流程 风险等级 高 关键策略 由于云资源天然的易申请，易缩扩容的特性，使用云可以提高效率、创新速度和灵活性，与此同时，也导致了云成本和使用模式的高度可变，客户应调整现有的组织预算和预测流程，以适应云的变化。 客户应密切关注历史消费趋势和不断变化的业务趋势，力求尽可能准确的预算规划。同时结合基于趋势（以历史支出作为输入）的预测和基于业务驱动因素（例如新业务上云或区域扩张）的预测，可以有效改进并提升企业的财务预测准确率。 相关服务和工具 使用成本中心的成本分析，可以根据客户的历史支出预测未来时间范围的成本。成本分析的成本和使用量预测，会参考不同的计费模式特征，结合机器学习和基于规则的模型来分别预测所有消费模式的成本和使用量。 使用成本分析确定基于趋势的预测之后，您还可以利用华为云的价格计算器，根据新业务上云或区域扩展所需的产品和使用量，自主搭配产品进行未来成本的估算。 父主题： COST02 实施预算规划管理机制

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

COST03-02 可视化成本分摊结果 风险等级 中 关键策略 将成本分配到责任团队，使各责任团队及时准确清晰的了解自己业务成本，加强团队成本意识，在构建方案时追求性能、可靠性和成本的平衡。 相关服务和工具 华为云支持您按照组织规划的方式分配成本。随着云服务的使用，规划的组织方式也会随着云服务的费用生成，体现在账单管理、成本分析等可视化工具的数据中。 您还可以使用成本单元，综合多种条件（产品类型、账单类型、关联账号、企业项目、成本标签），自定义规则，将成本按照业务语义分配到有意义的分组。基于成本单元的成本分配结果，支持在“成本分析”页面可视。 如果需要获取明细数据与自身云管平台进行集成，实现定制化的成本和使用分析，您还可以订阅账单明细数据、OBS转储成本明细或调用客户运营能力API。比如将成本和使用明细与企业的业务运营数据结合，生成业务单位成本KPI。 父主题： COST03 对成本进行分配

PERF05-02 通用算法优化 风险等级 中 关键策略 算法优化是提高程序性能的关键，可以通过改进算法的设计和实现方式来提高其效率和性能。以下是一些最佳实践： 使用正确的数据结构：选择合适的数据结构可以大辐提高算法的效率。例如，使用哈希表可以快速查找元素，使用数组可以快速访问元素。 减少内存分配：内存分配是一个耗时的操作。可以通过预先分配内存或者重复使用已分配的内存来减少内存分配。 减少循环次数：循环是一个常见的算法结构，但是循环次数过多会导致程序性能下降。可以通过使用更高效的算法来减少循环次数。 使用并行计算：对于一些计算密集型的算法，可以使用并行计算来提高程序性能。可以使用多线程或者分布式计算来实现并行计算。 父主题： 算法优化

COST03-01 制定成本分摊原则 风险等级 高 关键策略 成本分配支撑企业将成本分配到各业务团队中，使得各业务团队的成本清晰可见。这也是上文中明确的团队责任的基础。 根据清晰的成本，业务部门可准确 定价 ，并平衡成本、稳定性和性能，经济高效的提供领先方案。企业管理者基于数据决策各业务的云开支，保障核心业务和战略业务方向的支出，不超支，不浪费。 成本分配需匹配业务实质，具体有以下几个原则： 按实际使用者进行分配。即谁使用产生的成本分配给谁，而不是谁购买分配给谁。 基于实际消耗进行分配。比如客户1月份购买了一个包年资源，365元，按照实际支出这笔成本分配在1月份；如果按照实际消耗，那么就会在整个订购周期进行分配，每天分配1元。这种成本分配机制，更体现了成本责任制。 公共成本也应该在组织内进行分摊。比如企业内的共享资源、平台服务、支持计划、未及时标记的成本。只有将公共成本也分配下去，才能让业务团队关注这部分消费，从而合理化使用，减少不必要的浪费。 相关服务和工具 华为云成本中心提供包年包月、资源包成本按实际使用者和实际消耗的成本分摊（即摊销成本）。 父主题： COST03 对成本进行分配

问题和检查项 在企业进行成本优化的过程中，推荐使用如下问题寻找自身可以改进的点，并参考检查项/最佳实践进行改进，以下所有的检查项，也是最佳实践建议，将在下一章节进行详细描述。 问题 检查项/最佳实践 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探索 父主题： 成本优化支柱

数据库性能优化 以下章节我们结合一些具体建议和案例来说明如何针对数据库的使用进行性能优化： 1.优化数据库配置实践 数据库的配置参数应从具体业务诉求着手，根据实际需要进行设计；华为云在各个数据库云服务中均提供了默认的配置参数，以满足最普遍的业务需要。 华为云提供了多款数据库服务，不同服务的优化方式和注意事项均有差异，此方面需求，建议使用华为云提供的专业服务。 2.观测性能指标实践 性能监控有助于实时了解业务和系统的负载情况以及资源使用情况，结合告警规则的设置，云服务可自动对负载异常部分进行告警，以便更好地使用和维护云数据库系统。以GeminiDB 为例，您可以通过管理控制台，直观地查看GeminiDB Redis的各项监控指标。 3.设置数据分区实践 GaussDB数据库 支持的分区表为范围分区表，列表分区表，哈希分区表。分区表和普通表相比具有如改善查询性能、增强可用性、便于维护、均衡I/O等优势。 普通表若要转成分区表，需要新建分区表，然后把普通表中的数据导入到新建的分区表中。因此在初始设计表时，请根据业务提前规划是否使用分区表。 4. GaussDB SQL语句调优实践 根据数据库的SQL执行机制以及大量的实践，总结发现：通过一定的规则调整SQL语句，在保证结果正确的基础上，能够提高SQL执行效率。如果遵守这些规则，能够大幅度提升业务查询效率，如使用union all代替union、join列增加非空过滤条件、not in转not exists等都可以提升查询速度。 5.GaussDB语句下推调优实践 目前，GaussDB优化器在分布式框架下制定语句的执行策略时，有三种执行计划方式：生成下推语句计划、生成分布式执行计划、生成发送语句的分布式执行计划。在第3种策略中，要将大量中间结果从DN发送到CN，并且要在CN运行不能下推的部分语句，会导致CN成为性能瓶颈（带宽、存储、计算等）。在进行性能调优的时候，应尽量避免只能选择第3种策略的查询语句。 执行语句不能下推是因为语句中含有不支持下推的函数或者不支持下推的语法。一般都可以通过等价改写规避执行计划不能下推的问题。 语句下推典型场景包含单表查询语句下推与多表查询语句下推，一些特殊场景如语句中带有with recursive子句，列存表等不支持下推。 6.GaussDB子查询调优实践 应用程序通过SQL语句来操作数据库时会使用大量的子查询，这种写法比直接对两个表做连接操作在结构上和思路上更清晰，尤其是在一些比较复杂的查询语句中，子查询有更完整、更独立的语义，会使SQL对业务逻辑的表达更清晰更容易理解。GaussDB根据子查询在SQL语句中的位置把子查询分成了子查询SubQuery、子链接SubLink两种形式。 7..GaussDB算子级调优实践 一个查询语句要经过多个算子步骤才会输出最终的结果。由于各别算子耗时过长导致整体查询性能下降的情况比较常见。这些算子是整个查询的瓶颈算子。通用的优化手段是EXPLAIN ANALYZE/PERFORMANCE命令查看执行过程的瓶颈算子，然后进行针对性优化。 8.云数据库 TaurusDB读写分离最佳实践 读写分离是指通过一个读写分离的连接地址实现读写请求的自动转发。创建实例后，您可以 开通读写分离 功能，通过云数据库 TaurusDB的代理地址，写请求自动访问主节点，读请求按照读权重配比或者活跃连接数情况分发到各个节点。 开通读写分离时，需选择加入代理的节点（包括主节点和只读节点）。 9.云数据库 TaurusDB持锁长事务导致后续业务报等锁超时的解决实践 由于持锁长事务长时间未提交或回滚导致后续操作阻塞，如果持锁长事务已经阻塞了后续的业务，需要将长事务KILL，后续业务侧尽量避免持锁长事务。 10.云数据库 TaurusDB长事务产生大量临时表导致内存超限的解决实践 考虑升级实例规格，将内存利用率维持在合理范围，防止业务突增导致实例OOM，或根据业务实际情况优化慢查询。 11.云数据库 TaurusDB联合索引设置不当导致慢SQL的解决实践 查询变慢首先确认是否由于CPU利用率达到性能瓶颈导致执行慢，考虑升级资源规格；或是库表结构设计不合理，索引缺失或索引设置不恰当，应进行语句调优。 12.云数据库 TaurusDB使用INSTANT方式快速添加列 云数据库 云数据库 TaurusDB兼容开源MySQL 8.0.22，支持使用ALGORITHM=INSTANT快速添加列，避免造成锁等待影响业务或者SQL执行超时无法新增成功。 13.DAS数据诊断优化性能问题实践 DBA智能运维功能基于运行数据结合算法对实例进行诊断，并对异常项提供具体的诊断结果以及优化建议。 14.观测性能指标（GaussDB为例） 指标ID 指标名称 指标说明 rds001_cpu_util CPU使用率 该指标用于统计测量对象的CPU使用率。 rds002_mem_util 内存使用率 该指标用于统计测量对象的内存使用率。 rds003_bytes_in 数据写入量 该指标用于统计测量对象对应VM的网络发送字节数，取时间段的平均值。 rds004_bytes_out 数据传出量 该指标用于统计测量对象对应VM的网络接受字节数，取时间段的平均值。 iops_usage IOPS使用率 当前IOPS与磁盘最大IOPS比值。 rds007_instance_disk_usage 实例数据磁盘已使用百分比 该指标用于统计测量对象的实例数据磁盘使用率，该值为实时值。 rds010_disk_usage 磁盘已使用百分比 该指标用于统计测量对象的节点数据磁盘使用率，该值为实时值。 更多指标与其他数据库指标信息可参考官方文档。 父主题： 云服务性能优化介绍

Spark性能优化 概述 Spark是基于内存的分布式计算框架。在迭代计算的场景下，数据处理过程中的数据可以存储在内存中，提供了比MapReduce高10到100倍的计算能力。Spark可以使用HDFS作为底层存储，使用户能够快速地从MapReduce切换到Spark计算平台上去。Spark提供一站式数据分析能力，包括小批量流式处理、离线批处理、SQL查询、数据挖掘等，用户可以在同一个应用中无缝结合使用这些能力。 Spark的特点如下： 通过分布式内存计算和DAG（无回路有向图）执行引擎提升数据处理能力，比MapReduce性能高10倍到100倍。 提供多种语言开发接口（Scala/Java/Python），并且提供几十种高度抽象算子，可以很方便构建分布式的数据处理应用。 结合SQL、Streaming、MLlib、GraphX等形成数据处理栈，提供一站式数据处理能力。 完美契合Hadoop生态环境，Spark应用可以运行在Standalone、Mesos或者YARN上，能够接入HDFS、HBase、Hive等多种数据源，支持MapReduce程序平滑转接。 集群服务部署规划 服务规模与业务容量参数配置对照表 Spark作为内存计算引擎，需要更多的内存和CPU。用户在规划规格时，应根据当前的业务容量和增长速度，规划合理的内存和CPU资源，特别需要关注以下几点： 当程序运行在yarn-client模式下时，需要关注在driver端汇聚的数据量大小，根据自己的业务场景，为driver设置合理的内存。 根据自己的业务目标，规划CPU资源和内存资源。规划时，需要结合当前的数据分布情况，业务复杂度，设置“executor-memory”，“executor-cores”，“Executor-num”，并在此基础上，规划需要的CPU核数和内存大小。 在规划内存时，要预留一定量的内存空间作为操作系统的buffer cache，一般预留20%。 从HDFS中读入数据时，要考虑block解压缩后的数据膨胀。 规划一定的磁盘作为缓存空间，包括缓存数据、日志、Shuffle数据。 调优原则 提高cpu使用率同时减少额外性能开销。 提高内存使用率。 优化业务逻辑，减少计算量和IO操作。 典型业务的调优 优化代码逻辑：在进行Spark参数调优之前，要进行相应的规划设计，优化代码逻辑。 Spark任务跑的比较慢，cpu利用率低：检测室executor线程不能全部吃满，此时应减少每个executor的core数量，增加executor个数，同事增加partition个数。 任务容易出现内存溢出：部分数据分片较大，单个task处理数据过大，或者executor中并行度不足，单个task内存不足导致。此时应减少executor数量，增大数据分片。 数据量少，但小文件数量多：减少数据分片，在reduce算子后执行coalesce算子，以减少task数量，减少cpu负载。 使用spark sql查找一个大表，表列数较多，但是查找的列较少：尽量使用rcfile或parquet格式，减少文件读取成本，同时选择合适的压缩格式，减少内存负载。 指标观测方法 性能衡量指标包括吞吐量、资源利用率、伸缩性。 吞吐量：在相同资源环境下，执行相同计算任务，查看任务的完成速度 资源利用率：执行计算任务，查看在不同负载情况下，cpu、内存、网络的使用率。 伸缩性： − 横向扩容带来的性能提升曲线：增加资源，执行相同计算任务，查看性能提升比率。 − 增加系统负担带来的性能下降曲线：在相同资源环境下，增加计算负载，查看性能下降比率 父主题： 大数据性能优化

RabbitMQ性能优化 保持尽可能短的队列长度 太多的消息堆积在队列中会造成内存负载过高，为了释放内存，RabbitMQ 会把消息转存到磁盘，转存过程会耗费大量时间，造成消息处理速度下降或直接阻塞生产流程。因此队列中堆积过多的消息容易对 broker 产生负面效应。除此之外，如果节点崩溃后重启，过多的数据会使得重建索引需要消耗大量时间，集群模式下的节点间同步数据也会非常耗时。 使用惰性队列提升稳定性 惰性队列（lazy queues）是 RabbitMQ 3.6 之后新增的特性。惰性队列的消息会自动存储到磁盘，因此减少了内存的使用率，但是会增加I/O开销，影响吞吐量。使用惰性队列能够更好的把控性能，并且使得集群更加的稳定。和非惰性队列不同，消息不会积累在内存中然后等到内存不足再一次性刷到磁盘，造成队列性能不稳定。如果你需要一次发送大量消息，或者消费速度长时间赶不上生产速度，那么我们推荐使用惰性队列。 请注意，以下情况不建议使用惰性队列： a. 追求高性能 b. 队列无明显积压 c. 队列设置了 max-length 策略 通过TTL或者max-length限制队列长度 可以通过设置消息 TTL、队列 TTL 和 max-length 来限制队列长度。如果队列长度达到 max-length 值，队列头部的消息会被丢弃或进入死信队列。消息的生存时间到期也会被丢弃或者进入死信队列。 关注队列个数 在 RabbitMQ 中，一条队列是由一个线程处理的。利用服务器的多核特性和分布式特性建立多条队列，将不同队列分布到不同 CPU 或不同节点，以此来获取高吞吐量。同时需要注意，过多的队列可能会对 CPU 和内存造成较高的负担，RabbitMQ management 接口的响应速度也会受到影响。 自动为临时队列分配队列名 如果使用临时队列（包括排他队列、自动删除队列、非持久化队列），可以调用不带参数的接口queueDeclare()让 RabbitMQ 自动为你分配一个队列名。 根据需要使用自动删除队列 如果不再使用的队列资源长期保存在服务端，可能对 RabbitMQ 性能造成影响，可以通过三种方法自动地删除队列：为队列设置 TTL 属性、为队列设置 auto-delete 属性、为队列设置 exclusive 属性。 控制优先级队列的使用 每一个优先级会在Erlang VM中使用一个内部队列，这会消耗一定的资源。大多数场景下，使用最多5个优先级就够了。 如何确定消息大小 如何选择发往RabbitMQ的消息长度是一个常见问题。记住，每秒钟发送的消息数比消息大小更容易达到瓶颈。虽然发送大消息不是一个好的做法，但是发送多条小的消息也可能不是一个好的选择。更好的方法是生产者把多条小消息封装成一条大消息，然后由消费者来拆开处理。然而，如果一条大消息封装了太多的子消息，处理速度将会受到影响。如果一条子消息处理失败，整个大消息都需要重传。因此，当选择消息大小时，需要考虑带宽和业务架构。 连接和通道 每条连接（connection）大约占用 100KB 内存（启动 TLS 则会占用更多）。数以千计的连接会对 RabbitMQ 服务端造成较大的负担，极端情况下会因为 OOM 而崩溃。AMQP 协议可以在单条 TCP 连接上进行多路复用。建议一个进程只创建一条 TCP 连接，每个线程复用这条连接创建各自的通道（channel）。连接应该保持长生命周期，因为 AMQP 建立连接需要一定的开销（至少 7 个 TCP 包）。相反，通道则允许较为频繁的开启和关闭，但在发布消息时复用通道也是一个好的习惯，不要每发送一条消息都开启一个新的通道。同时需要注意如下几点： 多线程不要共享通道，因为你很难实现线程安全。 不要频繁的开启或关闭连接和通道，否则会造成更高的延迟。 生产者和消费者使用独立的连接，来提高吞吐量。 大量的连接和通道可能会影响管理接口的性能，造成请求超时。 消息确认 消费者使用确认（Acknowledgment）机制避免消息因为连接问题而丢失，客户端可以在收到消息或者处理完消息后回给服务端一个 ack 消息。消费者确认机制会对性能造成影响，如果单纯追求高吞吐量，应该关闭手动确认功能。如果消息对于业务来说比较重要，那么应该在消息被处理完之后才确认该条消息。生产者使用 Confirm 机制来实现类似的功能，当服务端收到生产者发来的消息，它会返回一个 ack 消息，以此来实现最少一次（at-least-once）的投递语义。注意，Confirm 机制同样会影响性能。 控制未确认消息个数 所有未确认的消息都会暂存在内存中，太多的未确认消息可能造成服务 OOM。为了限制未确认消息的规模，你可以在消费者端开启prefetch功能来限制消息拉取上限。 持久化资源 为了防止因为服务宕机、重启、硬件问题等原因造成的消息丢失，请使用持久化队列和消息。持久化消息涉及到写磁盘操作，如果使用了惰性队列也会将所有消息写入磁盘，包括非持久化消息。如果单纯追求高性能，可以使用非持久化消息。 开启TLS连接 你可以在 AMQP 之上使用 TLS 连接 RabbitMQ。因为数据需要加解密，所以 TLS 对性能有一定的影响。 如何正确选择 QoS 值 如果只有单个或少量消费者，并且消费速度很快，那么建议 QoS 设置的大一点，使得客户端保持忙碌状态。 如果客户端的消息处理速度和带宽保持不变，简单的用公式RTT / 单条消息处理时间就可以估算出应该设置多大的 QoS 值。 如果消费者数量较多并且消息处理速度较快，那么建议 QoS 设置的小一点。 如果消费者数量较多并且消息处理速度较慢，那么建议 QoS 设置为 1，让消息平均的分发到所有消费者。 请注意，如果客户端使用拉模式或者开启了自动确认（auto-ack），预拉取功能将会失效。一个常见的错误是不限制预拉取消息个数，所有消息全部发送给一个消费者，造成消费者 OOM 崩溃和消息重复投递。更多关于 RabbitMQ 预拉取功能的信息可以参考这里。 观测性能指标 指标ID 指标名称 指标说明 channels 通道数 该指标用于统计RabbitMQ实例中的总通道数。 queues 队列数 该指标用于统计RabbitMQ实例中的总队列数。 connections 连接数 该指标用于统计RabbitMQ实例中的总连接数。 connections_usage 连接数使用率 当前节点实际连接数占最大连接数比率。 rabbitmq_disk_usage 磁盘容量使用率 统计Rabbitmq节点虚拟机的磁盘容量使用率。 rabbitmq_cpu_usage CPU使用率 统计Rabbitmq节点虚拟机的CPU使用率。 rabbitmq_memory_usage 内存使用率 统计Rabbitmq节点虚拟机的内存使用率。 rabbitmq_cpu_core_load CPU核均负载 统计Rabbitmq节点虚拟机CPU每个核的平均负载。 全量指标可参考RabbitMQ支持的监控指标。 父主题： 消息队列性能优化

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。 父主题： 消息队列性能优化

COST05-03 定期回顾和审核 风险等级 高 关键策略 为了让云上应用始终最具成本效益，推荐您定期对其进行回顾和审核，以了解是否有机会实施新的优化措施。 回顾和审核可以基于成本分配的原则，在应用级别执行，持续审核组织为每个云上应用付出的总体成本。通过综合考虑云资源成本，研发成本，运营管理成本（如托管服务 vs 非托管云服务）来计算总拥有成本。审核工作量应该体现可能带来的好处（例如分析时间与应用成本成正比）以及相应的成本是否带来正向的营收。 回顾和审核的频率应该综合考虑多种因素，包括成本优化在企业或者组织中的重要性，测试和验证成本，应用的复杂性和优化变更的难易程度。同时，在每次回顾和审核时，持续改进流程，例如，通过降低测试和变更的成本从而提升整体的优化频率。最后，在云厂商新的服务、资源类型和配置推出后，也可以启动流程，对它们进行评估，以优化您的工作负载成本。 父主题： COST05 优化指定策略和目标

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

PERF05 性能优化 性能优化工作中，需警惕“过早优化”的问题。我们的基本指导策略还是首先让系统运行起来，再考虑怎么让它变得更快。一般只有在我们证实某部分代码的确存在一个性能瓶颈的时候，才应进行优化。除非用专门的工具分析瓶颈，否则很有可能是在浪费自己的时间。另外，性能优化的隐含代价会使我们的代码变得难于理解和维护，这一点也是需要权衡和关注的。 设计优化 算法优化 资源优化 父主题： 性能效率支柱

COST01-01 规划企业组织，将组织结构，流程和成本管理相匹配 风险等级 高 关键策略 在成本优化过程中，一个很重要的原则是需要将组织结构，流程和成本管理相匹配。需要建立“责权分明”的体系，否则即使用再好的成本优化工具，也无法将成本优化落到实处。一个比较好的实践是在初始的时候，创建一个团队（云业务办公室、云卓越中心或 FinOps 团队），负责在整个组织内建立并维护成本意识。成本优化的负责人可以是了解整个组织和云财务的个人或团队。而整个团队的成员需要包含相关决策部门和实施部门的人员，典型的团队成员通常包括来自企业的核心决策者（CXO），财务、开发，运维/运营，数据分析团队的人员。 这个团队可以是一个虚拟团队，该团队在企业开始实施成本优化的时候，建立相应的成本管理流程，例如，将成本支出纳入应用、业务全生命周期的关键评估指标，推动各个分歧（如成本归属）的解决。 最终定义企业中成本相关完善的问责机制，落实机制。 父主题： COST01 规划成本优化相应的组织机构和流程

PERF05-01 设计优化 风险等级 中 关键策略 快速通道模式 通过减少支配性工作量负载的处理量，只剩下必要的部分，来改进响应的时间。一个软件可以有多项功能，只有几个是被经常使用的，经常使用的功能构成支配性工作量负载。快速通道模式减少这些功能的处理量，或简化其处理过程。快速通道通过简化执行路径的方式来实现，简化路径即是快速通道。 快速通道的前提是识别出支配性工作量，可以根据某项功能的使用频率来选择。常见的快速通道如，页面快速导航键、DB的索引等。 重要事情优先 把资源优先用于或者集中在重要的任务处理上，确保重要任务的完成；如果不能在可用的时间内完成所有事情，被忽略的是最不重要的任务。主要用于处理瞬时突发负载导致超出系统处理的容量的情况，一般给重要任务赋予高优先级，最重要的行为优先得到处理。只适用于暂时超载的情况，如果超载不是暂时的，需要减少处理量，或者升级系统。如在性能过载场景下，按照功能优先级进行熔断间接，保证主要功能可用。 聚合 将大多数场合在一起使用的功能组合在一起，以减少调用的交互次数。 本模式要求将组合调用居多的一些子功能，合并起来使用。聚合这个模式要求尽量将相关或紧耦合的功能放到一个对象中，使用本地接口，避免在外部接口或重开销的接口（如CORBA接口），呈现小粒度对象。聚合模式使用更粗粒度的对象，经常被访问的数据应当组合成一个聚合物，以消除对少量信息的频繁请求。如，帐户类CustAcct可以提供访问函数getName()，getAddress()，getZip()，如果经常用到该类的任务是创建邮件标签，可以使用一个新函数genMailLableInfo()，以便调用一次取得所有信息，减少交互次数。 批处理 把经常性的服务请求合并到一起，节省请求的初始化、传输、终止的处理开销。当请求的任务初始化、传输、终止的开销较大时，系统的额外开销可能超过真正的处理时间。通过将请求合并为批处理，开销处理为一批请求所分摊，不再是单独分别执行一次，从而提高处理效率。如DB的批量保存、Redis的popeline方式都是常用的批处理操作 批处理过程模型 替代路由（Bypass） 从空间上分散对高使用率对象的请求，将请求分散到其他对象或者对象的其他位置，以降低争用延时.类似于通过一条替代路线，绕开交通瓶颈，到达目的地。具体方案一是对目标对象进行空间划分，划分成小粒度对象，操作分散到不同物理位置；二是增加单独线程，每个线程更新自身的数据区域。 比如进程必须与下游单个进程协作时，只有一个下游进程，在高负载的情况下跟不上，造成交通堵塞。可以使用多个下游进程，每个进程只更新其自身的数据区域。 弹性时间 在时间上分散对高使用率对象的要求，分散到不同的时间段上，减少对这些对象的争用延时。 很多请求在某一时刻同时发出，导致要求返回的结果激增，响应缓慢。而在其他时间，很少或者没有请求。当处理请求以特定频率出现，或者在一天中的某个特定时间出现，就会产生这种情况。识别那些定期的，以特定间隔反复处理的功能，然后修改他们的处理时间，在给定时间范围内，随机分散到不同时间，以解决这个问题。 空间换时间 通过使用更多的存储空间，以节省执行时间。 空间换时间包括简单地预先存储结果，或者存储经常被访问的数据以方便计算；另一种空间换时间则包括选择特定的算法，如HASH算法就是一种典型的空间换时间的算法。另一种是OLAP技术，在此技术中，数据被按照一定的层级关系预先汇总，这样会大辐降低后续查询的耗时。 比如在慢SQL优化的时候，常用收段是识别频繁访问的字段并且设置索引，通过索引来缩短访问时延。 处理有效负载 识别出必须要处理的数据，排除对其他数据的重复处理。在一项处理数据的操作中，并非所有的处理数据都是必须处理的，可以通过分析，识别出必须处理的数据。可以有多种方式，来减轻负载的方法，如增量处理、变化通知等。 增量处理 变化通知 有效减负的反模式是“负载过重”，是在处理过程中，处理了大量不必要的处理数据，大辐增加了处理负载。出现这种情况的原因，有时为了简化处理过程，有时候是没有做必要性分析。可以通过对待处理数据进行分析，筛选出必须处理的数据，重新设计处理方案。 串行同步衔接 给线程/进程间的串行衔接设计紧密的衔接和同步措施，减少同步等待延时。 将一个串行处理通过划分多个线程并行处理，但各线程的处理又有一定的顺序和同步关系，需要设计合适的衔接和同步措施。同步方式可以是定时查询，也可以选择消息同步，或Event关联，选择的原则是衔接时间缝隙满足性能目标要求。 这个方法最佳的效果只是让整体性能略等于处理环节中最差的一个环境的性能（忽略线程切换及信号量等切换时间）。 父主题： 设计优化

COST01-03 明确团队责任，建立和维护成本意识文化 风险等级 中 关键策略 成本优化的流程中落实成本意识、都需要明确团队责任。一种比较好的实践是使用一组明确定义的 KPI 指标，提供团队级别的报告，实现成本透明度和成本问责制，这些指标可以包含收益/成本比率，单位商品成本，核心资源利用率等等。 值得注意的是，成本优化不是一锤子买卖，团队对责任的接受，实施包括指标自身的完善都需要一个过程。 KPI指标应该随着阶段的演变而演变，以建立不断成功，不断进步的心态，而不是一次性推动成熟。在实施过程中，更多应该将错误视为学习和改进流程的机会，这将减少不成熟的团队和管理团队对成本优化的恐惧心理。指标自身也需要不断优化，一开始可以从比较保守的目标开始推动，避免IT成本迅速下降造成的业务风险。而后不断迭代预算分配、IT 支出和预测，不断优化这些指标。 最后，需要在流程中提高成本意识，在员工培训中贯彻成本意识。 父主题： COST01 规划成本优化相应的组织机构和流程

COST05-01 分析业务趋势和优化收益 风险等级 高 关键策略 云成本是一个综合工程，也是一个定期审核、回顾和执行的流程，除了考虑优化带来的收益以外，还需要考虑相关成本，例如，因为优化带来的人员和时间成本。 为了降低整体成本，优化的工作量必须与潜在的节省额成比例。优化可以从应用占成本的比例考虑。 例如，与占总成本 5% 的应用相比，应更经常、更彻底地审核占总成本 50% 的应用。优化时要考虑的另一个因素是实施更改的工作量。如果测试和验证变更的成本很高，优化的频率应该降低。您应该反方向考虑是否可以通过替身自动化测试和验证能力，从而进一步降低人力成本。 此外，由于成本优化带来可能带来的资源冗余度的下降，故而也应该综合考虑业务的趋势。 比如一个快速增长的业务组织更多地可能会偏向于提升业务的速度，而设计一个比较宽松的云成本优化策略，而稳定的业务组织则可以以成本效率为主要考量，设计比较严格的云成本优化策略。如果应用服务于特定的地理位置或市场领域，并且您已预测出该领域会出现的对云业务使用量的降低，则提高优化频率可能会更有利于节省成本。 父主题： COST05 优化指定策略和目标

性能数据采集 收集性能数据是收集指标和日志的过程，这些指标和日志提供有关工作负载性能的信息。 此数据包括数值，称为指标。 指标描述系统在特定时间点的状态。 它还包括包含组织成记录的不同类型的数据的日志。 通过收集性能数据，可以监视和分析工作负载的性能。 可以使用此信息来识别性能瓶颈、解决问题、优化资源分配，以及做出数据驱动的决策，以提高工作负载的整体性能效率。 影响：如果没有数据驱动的见解，你可能不知道潜在的性能问题或优化机会。 潜在结果包括响应时间变慢、吞吐量降低、资源使用率增加，最终用户体验欠佳。 此外，由于缺少性能数据，因此难以及时诊断和排查问题，从而导致停机时间延长并降低工作效率。 PERF04-04 资源性能数据收集 PERF04-05 应用性能数据采集 父主题： PERF04 性能分析

PERF04-05 应用性能数据采集 风险等级 中 关键策略 应用程序的性能数据（吞吐量、延迟和完成时间），通常需要通过代码采集，例如嵌入代码片段或将工具集成到应用程序代码中。通过应用的性能数据，可以识别性能瓶颈、评估系统行为、识别可用性风险、规划容量等指标。 常用应用性能监控策略有： APM 工具：可用使用云上APM 工具或者开源的APM工具和分析性能数据（指标、日志、调研链） 使用基于日志调用链框架：这些框架具备日志生成、日志格式化、日志上下文关联分析登能力。 通过框架引入到代码库中，可以在运行时采集相关的性能数据。 自定义检测：仅当平台指标不足时，才建议开发人员可以添加自定义代码采集独有的性能指标。 使用业界可观测的标准。请考虑使用围绕业界标准构建的工具，例如OpenTelemetry。 建议：使用分布式的调用链技术，可以识别多个服务和组件之间请求链路；通过收集调用链数据实现数据流端到端的分析，产品阻塞瓶颈点或者效率低下的请求片段，从而进行针对性的优化。 相关云服务和工具 应用运维管理 AOM 应用性能管理 APM 云日志服务LTS 父主题： 性能数据采集

COST01-02 规划IT治理体系，提高管理效率 风险等级 高 关键策略 实施与您的组织对应的IT治理结构。这有助于在整个组织内分摊和管理成本。随着经营范围和规模的不断扩张，不断建立子公司、分公司，大部门也逐步拆分成多个小部门，组织结构的层级也就越来越多。企业的IT治理架构也会受到组织结构的影响，需要匹配企业管理模型，帮助企业以多层级组织的方式管理人、财、物，所有资源都可以找到责任团队。企业根据组织结构合理规划IT治理架构后，可将成本分配到业务团队，让各业务团队为使用的云服务成本负责。 相关服务和工具 对于大型企业或集团公司，推荐优先使用企业组织+多账号的方式，通过账号隔离资源和成本，方便业务快速拓展。 中小型企业以及单账号客户，可以使用企业项目来映射组织。如果存在更多维度、更细粒度规划的诉求，可以使用标签作为组织规划的补充。比如用标签来区分资源归属的产品团队、应用和负责人。 企业组织采用企业主子多账号形式进行成本管理时，企业主子关系可以分为财务托管和财务独立两种。 财务托管模式下，企业主账号可以统一管理企业主+企业子的成本，包括统一成本分析、统一预算跟踪、统一异常监控、统一成本建议等，使用该模式可大幅提升管理效率。 财务独立模式下，企业主子各自管理各自账号下的成本，包括成本分析、预算跟踪、异常监控、成本建议等。如果企业子向企业主授权了查看消费信息，则企业主也可以统一分析企业主+企业子的成本。 父主题： COST01 规划成本优化相应的组织机构和流程

人工智能性能优化 1.训练优化模型性能提升实践 参数调优策略：调整模型flash attention、并行切分策略、micro batch size、重计算策略等参数。 尽可能充分利用显存和算力，通过参数调优，初步优化性能。 性能拆解 参数调优后性能仍然与转商目标有较大的差距，需要考虑进行profiling，采集性能数据后从更底层的算子、通信、调度和内存等维度将性能进行拆解分析，训练脚本中加入profiling代码。具体步骤：生成profiling数据目录结构；利用att工具，将NPU与竞品之间的数据进行端到端耗时对比分析；Tracing分析。 算子分析 通过生成profiling中的summary文件对具体的算子进行分析，考虑算子层面向FA与MM算子方向优化。 2.路由规划加速最佳实践 ranktable路由规划是一种用于分布式并行训练中的通信优化能力，在使用NPU的场景下，支持对节点之间的通信路径根据交换机实际topo做网络路由亲和规划，进而提升节点之间的通信速度。本案例介绍如何在ModelArts Lite场景下使用ranktable路由规划完成Pytorch NPU分布式训练任务，训练任务默认使用Volcano job形式下发到Lite资源池集群。详细步骤可参考最佳实践文档。 训练显存优化实践 pytorch的内存池基本管理策略 pytorch的内存池以block为粒度来进行管理，block池分为小内存池与大内存池，block是pytorch向device驱动申请内存的粒度，整存整取。用户/Pytorch代码向内存池申请内存的接口归一为tensor的申请释放（这点最开始也不是很好理解，也就是说：任何一个pytorch代码申请内存的地方，均表现为一个tensor的申请释放）。 tensor的生命周期使用类似智能指针的引用计数方式来管理，且打通了Python与C++的通道，即：一个Python的tensor对象关联一个C++的tensor对象，Python的tensor对象的消失会触发C++的tensor对象析构释放内存。一个在C++环境里创建的tensor对象可以返回成一个Python的tensor对象。 C++的tensor对象分为两部分：一部分是viewTensor，包含tensor的各种meta信息：shape, stride, dataType等，一部分是storageTensor，包含具体的内存addr，offset，对外呈现的是viewTensor，这是pytorch做view类操作后，多个tensor对应同一块内存的基本支撑。在storageTensor申请时，向pytorch的block池申请一块内存，找到空闲块之后，视实际要求对block进行切分使用并返回address指针。 pytorch的内存的跨流复用策略 如果一个stream上的内存池里申请的tensor需要给另一个stream使用，那么则需要进行recordStream操作，将这个tensor的所属block标识上新stream的信息，在这个tensor的生命周期消失触发address释放时，发现其所属block有其他stream信息，此时会给对应stream下发一个event_record task然后返回。 在之后本stream在每一次新申请内存时，均做一下event_query操作，如果发现event已经被record则其他stream上的task已经执行完成，此时可以放心地回收这个block。 Pytorch的内存统计信息说明 pytorch的内存一般看三个峰值信息：allocated / active / reserved。allocated对应host上的tensor实际申请了但是没释放的内存（注意：是在host上申请释放，不代表device状态）。active对应host上还未释放的内存+还在被别的流占用的内存。 举例，一个tensor在streamA上申请了，让供streamB做allreduce的集合通信操作，然后tensor进过一次add后被释放，此时：释放会减去allocated值，但是不会减去active 值，直至这个allreduce真实执行之后，通过query_event查询到结果之后触发释放，才会减去active值。 reserved对应pytorch向device申请了的内存，比如申请了100M，然后释放了，然后又申请了20M，还未释放，此时的allocated 为20M，reserved为100M。真实网络里，reserved里存在大量block被切小了的可使用内存但是当申请一个大块内存时又无法复用，这种会导致reserved 与 allocated 的较大差值，通常称为内存碎片。 pytorch的内存碎片影响因素 一个step里更多的内存申请释放内存次数理论上一定会导致更多的内存碎片，为什么说是一个step呢？因为pytorch内存池只取决于host上的训练脚本逻辑，而每个step的训练脚本逻辑是相同的，所以一般第一个step之后内存状态可以稳定下来。 不同生命周期的tensor交替地申请释放，因为pytorch向驱动申请是整存整取，所以：一个常规的优秀做法是把长生命周期放在最开始申请，这样不易形成碎片。而workspace内存由于可以绝对意义上地串行复用，因此对此单独做一个定制的内存池策略可以减少对内存碎片影响，在NPU上常见的非连续转连续操作，就是一个相对GPU来说较多的内存申请。 显存优化策略 由于大模型的参数成倍数的增长，远超出了单GPU物理显存所能承载的范围，大模型训练必然需要进行显存优化。显存优化要么是优化算法本身，降低模型算法的显存消耗；要么是去扩大显存，通过一些置换方式获得“额外“空间，由于显存物理大小一定，我们获得额外空间的方式不外乎两种：时间换空间和空间转移。其中，时间换空间通常会消耗算力、带宽；空间转移主要是消耗I/O带宽，有一定的时延，可能会降低吞吐。 观测性能指标 指标ID 指标名称 指标说明 cpu_usage CPU使用率 该指标用于统计ModelArts用户服务的CPU使用率。 mem_usage 内存使用率 该指标用于统计ModelArts用户服务的内存使用率。 gpu_util GPU使用率 该指标用于统计ModelArts用户服务的GPU使用情况。 gpu_mem_usage GPU显存使用率 该指标用于统计ModelArts用户服务的GPU显存使用情况。 npu_util NPU使用率 该指标用于统计ModelArts用户服务的NPU使用情况。 npu_mem_usage NPU显存使用率 该指标用于统计ModelArts用户服务的NPU显存使用情况。 disk_read_rate 磁盘读取速率 统计ModelArts用户服务的磁盘读取速率。 disk_write_rate 磁盘写入速率 统计ModelArts用户服务的磁盘写入速率。 全量指标可参考ModelArts支持的监控指标文档。 父主题： 云服务性能优化介绍

COST04-01 建立规范，持续提升成本分配比例 风险等级 中 关键策略 成本是否准确有效的分配，是后续进行成本监控和优化的基础。客户应关注并提升成本分配比例，奠定成本治理的基础。 标签作为一种常见的成本分配方式，可以灵活匹配组织内多种分配场景（比如产品、应用、责任人），但在实施标签过程中，企业会发现有各种不利因素导致标签的标记覆盖率下降，例如： 实施标签工作量大：云上创建的资源不断增加，资源数量巨大，且每个资源需打多个标签 标签实施不一致：业务部门执行进展不一、添加的标签key&value错误、部分资源无人认领未打标签 环境和诉求变化：部门&应用调整、管理层&财务等利益相关人诉求变化 针对这些不利因素，需要引入运营，定期审视标签覆盖率，并通过治理持续提升。一些可选的方法有： 制定KPI指标支撑改进: 成本标签核心目的是成本分配，建议将KPI定为成本可分配比例，用于衡量标签的覆盖率。可分配成本比例越高，成本分配和报告效率越高，成本数据越可信任。在标签治理过程中，通过可分配成本比例趋势的上升和下降，检查组织内标签的标记覆盖率是在提升还是在下降 识别标签缺失和错误：在确定需要进行标签治理后，需要首先识别所有未打标签的资源和标签key&value错误的资源，然后从费用最高的资源开始逐步治理。建议利用云厂商提供的工具或者自建工具，通过自动化规则的方式，在资源创建的时候，就判断标签是否规范。另外一个更好的方式通过权限管理，识别资源创建人和组织，自动为资源打上标签。 定期审查和优化规范：变化不可避免，良好的标签管理不是一个一劳永逸的过程。通过定期审查和优化规范，确保成本标签适应环境和诉求变化。管理层&财务等利益相关人诉求变化，他们可能会对更细粒度的提出请求，定期和利益相关人确定并更新规范。 相关服务和工具 企业可在成本中心查看可分配成本比例，并通过该指标诊断标签覆盖率和牵引企业内部治理标签。 企业可通过成本中心、TMS、云服务控制台来识别和治理未打标签资源，标签Key&value错误 客户可通过Config服务预设的资源合规策略，识别资源标签为空等不合规场景。 客户可通过Organization服务，设置标签策略，帮助您在组织账号中对资源添加的标签进行标准化管理。 父主题： COST04 持续进行成本治理

PERF05-03 WEB场景资源优化 风险等级 中 关键策略 对于已经配置好的资源，可以通过优化来提高性能。例如，优化操作系统的设置、调整网络带宽、优化数据库查询等。 云服务资源性能优化步骤包括: 识别性能瓶颈: 通过监控和分析云服务资源使用情况，找出性能瓶颈。 优化资源配置: 根据性能瓶颈，调整云服务资源的配置，如 CPU 、内存、网络等。 使用缓存: 使用缓存技术，如 CDN 、 Redis 等，提高数据访问速度。 代码优化: 对云服务资源使用的代码进行优化，提高代码执行效率。 数据库优化: 对云服务资源使用的数据库进行优化，如索引优化、查询优化等。 负载均衡: 使用负载均衡技术，将请求分发到多个云服务资源，提高系统的处理能力。 监控和调整: 持续监控云服务资源的性能，根据实际情况进行调整，以保持最佳性能。 父主题： 资源优化

PERF04-04 资源性能数据收集 风险等级 中 关键策略 每个华为云提供的云服务都有一组特定于资源功能的指标，用于呈现有关资源的使用情况。通过收集资源性能数据，可以深入了解工作负载的运行状况和行为。 指标作用： 帮助你了解资源的运行状况和性能， 在 云监控 平台上配置对应的告警策略和配置指标看板。 通过跟踪分析网络路径上的流量来优化网络性能。 相关云服务和工具 云监控服务 CES 父主题： 性能数据采集

成本优化支柱简介 成本优化支柱专注于帮助企业高效地使用云服务来构建工作负载，面向工作负载的整个生命周期不断完善和改进，减少不必要的开支并提升运营效率，让云上应用始终最具成本效益。 成本优化实践不意味着只有降本，它是安全合规、韧性等维度的平衡，也是达成业务目标的最优投入。 华为公司结合云业务成本运营经验和业界最佳实践总结并提炼出体系化实践与建议，包括：提升成本管理效率、合理选择与分配云资源、建立预算管理机制、持续成本治理、提升资源效率及架构优化等。 父主题： 成本优化支柱

COST06-02 为工作负载选择合适的计费模式 风险等级 中 关键策略 分析工作负载的每个组件。确定组件和资源是长时间运行（应享受承诺折扣，包年包月或购买资源包），还是短时间动态运行（采用 Spot 或按需定价）。使用成本管理工具中的建议对工作负载执行分析，并对这些建议应用业务规则以实现高回报。 相关服务和工具 为提高成本效率，华为云根据您过去的使用情况，为您提供多项计费模式的优化建议，帮助您在不改变资源性能的情况下，通过调整计费模式来节省成本。您可以重点关注高节省低风险的节省建议（“预计月度节省”高且“盈亏平衡时间”短） 按需转包年包月成本优化评估：自动识别客户长期按需使用的资源（比如ECS、EVS、RDS、ELB、SFS Turbo），生成按需转包年包月的优化建议和节省评估。 资源包购买建议：自动分析客户按需资源消耗和华为云在售资源包商品（比如OBS标准存储单AZ存储包、OBS标准存储多AZ存储包、OBS公网流出流量包、SFS存储资源包）的覆盖情况，生成相应的资源包购买建议和节省评估。 父主题： COST06 使用不同计费模式优化成本

COST01-04 指定云资源管理策略和相应的权限管理机制 风险等级 高 关键策略 由于成本优化是跨组织多个业务部门的事项，而云资源是云上成本的主要开销，故而应该制定策略，确定您的组织应该如何管理资源。如上文所说的，可以使用账号隔离不同组织/部门的资源，甚至于在同一个组织/部门内部，开发，测试，核心业务，非核心业务，也使用不同的账号和环境。 然而即使账号/环境是分散的，云资源管理策略和权限管理机制应该是集中的。 企业的中心团队，如上文所提的云业务办公室、云卓越中心或 FinOps 团队需要为各个账号环境实施与策略一致的组和角色，控制每个组中谁可以创建、修改或停用实例和资源。同时依据企业的业务环境，创建统一的资源/成本视图，统一管理企业的账单和成本。 相关服务和工具 客户可通过 统一身份认证 服务 IAM 的细粒度权限管理，精细化控制账号下用户的资源访问权限，实施最小授权。 对于多账号场景，客户可通过Organization的服务控制策略（Service Control Policy），集中控制每个账号可执行的操作。 父主题： COST01 规划成本优化相应的组织机构和流程