华为云用户手册

  • PERF02-02 容量规划 风险等级 中 关键策略 容量规划指根据业务需求和系统性能,包括用户数量、并发请求量、响应时间要求等,以此规划和配置系统所需的资源。容量规划对于任何组织来说都非常重要,有效的容量规划可以确保有足够的资源来满足预期的需求,同时避免浪费资源。 收集容量数据 收集容量数据有助于将业务目标转化为技术要求,并且对于预测容量至关重要。为了满足工作负载需求,收集容量数据需要包括系统资源消耗数据以及业务关键数据。 资源消耗数据:包括CPU、内存、磁盘空间、网络带宽等,以便确定系统的瓶颈所在。 业务关键数据:包括用户数量、用户行为模式、业务类型、业务时段等,以便确定业务需求对工作负载的影响。 预测需求 有效的容量规划需要为未来的业务需求做好准备,通常使用工作负载的数据来预测未来需求。预测需求是一个复杂的过程,涉及到多种因素,包括市场趋势、消费者行为、竞争环境等。通过多种方法的组合,如历史数据分析、资源分析、趋势分析等,以此作为预测需求的基础,并结合人工智能机器学习算法,以便更准确地预测未来的需求,评估工作负载的资源需求。 使预测与工作负载目标保持一致 为了确保预测与工作负载目标保持一致,需要定期对预测进行评估,比较实际结果与预测结果,根据需要对容量预测模型进行调整。例如新的应用或服务添加到系统中,那么容量预测模型就需要考虑这些新的容量需求。预测与工作负载目标的一致性,可确保充分预配资源,防止资源浪费或工作负载过载。 确定资源需求 根据需求和预测分析的结果,进行容量评估和规划。确定系统所需的计算资源、存储资源和网络带宽等资源,以满足系统的性能要求。 计算资源:根据预测的需求,计算所需的CPU、GPU、内存等计算资源,并根据实际情况进行选择和配置。 存储资源:根据预测的需求,计算所需的存储空间,例如需要存储大量的数据,可能需要选择分布式存储系统。 网络带宽:根据预测的需求,计算所需的网络带宽,例如需要进行大规模的数据传输或者实时的网络通信,可能需要选择高速网络 了解资源限制 容量规划时了解和合理使用资源限制非常重要,常见的资源限制包括进程、线程、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支持的监控指标。 父主题: 消息队列性能优化
  • SEC08-04 数据收集合规性 数据收集合规性是指数据控制者在收集个人数据时需遵守相关的法律法规和隐私保护准则,确保数据收集活动符合法律规定并尊重数据主体的权利。 风险等级 高 关键策略 收集个人数据必须获得数据主体授权。 收集敏感个人数据必须获得数据主体明示同意。 个人数据收集范围、使用目的、处理方式不得超出隐私声明,且遵循最小化原则。 收集到同意之后也需要向数据主体提供撤销或修改同意的途径。 父主题: SEC08 数据隐私保护
  • PERF04-05 应用性能数据采集 风险等级 中 关键策略 应用程序的性能数据(吞吐量、延迟和完成时间),通常需要通过代码采集,例如嵌入代码片段或将工具集成到应用程序代码中。通过应用的性能数据,可以识别性能瓶颈、评估系统行为、识别可用性风险、规划容量等指标。 常用应用性能监控策略有: APM 工具:可用使用云上APM 工具或者开源的APM工具和分析性能数据(指标、日志、调研链) 使用基于日志调用链框架:这些框架具备日志生成、日志格式化、日志上下文关联分析登能力。 通过框架引入到代码库中,可以在运行时采集相关的性能数据。 自定义检测:仅当平台指标不足时,才建议开发人员可以添加自定义代码采集独有的性能指标。 使用业界可观测的标准。请考虑使用围绕业界标准构建的工具,例如OpenTelemetry。 建议:使用分布式的调用链技术,可以识别多个服务和组件之间请求链路;通过收集调用链数据实现数据流端到端的分析,产品阻塞瓶颈点或者效率低下的请求片段,从而进行针对性的优化。 相关云服务和工具 应用运维管理 AOM 应用性能管理 APM 云日志服务LTS 父主题: 性能数据采集
  • COST05-01 分析业务趋势和优化收益 风险等级 高 关键策略 云成本是一个综合工程,也是一个定期审核、回顾和执行的流程,除了考虑优化带来的收益以外,还需要考虑相关成本,例如,因为优化带来的人员和时间成本。 为了降低整体成本,优化的工作量必须与潜在的节省额成比例。优化可以从应用占成本的比例考虑。 例如,与占总成本 5% 的应用相比,应更经常、更彻底地审核占总成本 50% 的应用。优化时要考虑的另一个因素是实施更改的工作量。如果测试和验证变更的成本很高,优化的频率应该降低。您应该反方向考虑是否可以通过替身自动化测试和验证能力,从而进一步降低人力成本。 此外,由于成本优化带来可能带来的资源冗余度的下降,故而也应该综合考虑业务的趋势。 比如一个快速增长的业务组织更多地可能会偏向于提升业务的速度,而设计一个比较宽松的云成本优化策略,而稳定的业务组织则可以以成本效率为主要考量,设计比较严格的云成本优化策略。如果应用服务于特定的地理位置或市场领域,并且您已预测出该领域会出现的对云业务使用量的降低,则提高优化频率可能会更有利于节省成本。 父主题: COST05 优化指定策略和目标
  • 问题和检查项 在迈向卓越运营的过程中,推荐使用如下问题寻找自身可以改进的点,并参考检查项/最佳实践进行改进,以下所有的检查项,也是最佳实践建议,将在下一章节进行详细描述。 问题 检查项/最佳实践 OPS01 您是否已经建立持续改进的团队文化和标准化运维体系? 1. 建立持续学习和改进的文化 2. 规划标准化的运维组织 3. 规划标准化的运维流程与运维工具 OPS02 您是否通过CI/CD实现高效的频繁可逆的小规模变更? 1. 进行需求管理与迭代开发 2. 关联源代码版本和部署的应用版本,使用代码质量最佳实践 OPS03 你是否有完备的测试验证体系? 1. 推行开发者测试 2. 使用多个环境进行集成测试,构建和生产环境相同的预生产环境 3. 性能压测 4. 生产环境拔测 5. 混沌测试和演练 OPS04 自动化构建和部署流程是否完备? 1. 有效落地持续集成 2. 采用持续部署模型 3. 基础设施即代码 4. 自动化工程运维任务 OPS05 是否有运维准备和变更管理体系? 1. 进行生产准备度评审 2. 进行变更风控 3. 定义变更流程 OPS06 是否建立了完备的可观测体系? 1.建立可观测体系 2.定义可观测对象 3.制定和实施可观测性指标 4. 规范化应用日志 5. 实施依赖项遥测 6. 实施分布式跟踪 7. 通过可观测性指标引入自动化措施 OPS07 是否进行故障分析与管理? 1. 创建可操作的告警 2. 创新监控看板 3. 支持事件管理 4. 支持故障恢复流程 OPS08 是否有运营状态度量和持续改进机制? 1. 使用度量指标衡量运营目标 2. 进行事故复盘和改进 3. 知识管理 父主题: 卓越运营支柱
  • PERF05-01 设计优化 风险等级 中 关键策略 快速通道模式 通过减少支配性工作量负载的处理量,只剩下必要的部分,来改进响应的时间。一个软件可以有多项功能,只有几个是被经常使用的,经常使用的功能构成支配性工作量负载。快速通道模式减少这些功能的处理量,或简化其处理过程。快速通道通过简化执行路径的方式来实现,简化路径即是快速通道。 快速通道的前提是识别出支配性工作量,可以根据某项功能的使用频率来选择。常见的快速通道如,页面快速导航键、DB的索引等。 重要事情优先 把资源优先用于或者集中在重要的任务处理上,确保重要任务的完成;如果不能在可用的时间内完成所有事情,被忽略的是最不重要的任务。主要用于处理瞬时突发负载导致超出系统处理的容量的情况,一般给重要任务赋予高优先级,最重要的行为优先得到处理。只适用于暂时超载的情况,如果超载不是暂时的,需要减少处理量,或者升级系统。如在性能过载场景下,按照功能优先级进行熔断间接,保证主要功能可用。 聚合 将大多数场合在一起使用的功能组合在一起,以减少调用的交互次数。 本模式要求将组合调用居多的一些子功能,合并起来使用。聚合这个模式要求尽量将相关或紧耦合的功能放到一个对象中,使用本地接口,避免在外部接口或重开销的接口(如CORBA接口),呈现小粒度对象。聚合模式使用更粗粒度的对象,经常被访问的数据应当组合成一个聚合物,以消除对少量信息的频繁请求。如,帐户类CustAcct可以提供访问函数getName(),getAddress(),getZip(),如果经常用到该类的任务是创建邮件标签,可以使用一个新函数genMailLableInfo(),以便调用一次取得所有信息,减少交互次数。 批处理 把经常性的服务请求合并到一起,节省请求的初始化、传输、终止的处理开销。当请求的任务初始化、传输、终止的开销较大时,系统的额外开销可能超过真正的处理时间。通过将请求合并为批处理,开销处理为一批请求所分摊,不再是单独分别执行一次,从而提高处理效率。如DB的批量保存、Redis的popeline方式都是常用的批处理操作 批处理过程模型 替代路由(Bypass) 从空间上分散对高使用率对象的请求,将请求分散到其他对象或者对象的其他位置,以降低争用延时.类似于通过一条替代路线,绕开交通瓶颈,到达目的地。具体方案一是对目标对象进行空间划分,划分成小粒度对象,操作分散到不同物理位置;二是增加单独线程,每个线程更新自身的数据区域。 比如进程必须与下游单个进程协作时,只有一个下游进程,在高负载的情况下跟不上,造成交通堵塞。可以使用多个下游进程,每个进程只更新其自身的数据区域。 弹性时间 在时间上分散对高使用率对象的要求,分散到不同的时间段上,减少对这些对象的争用延时。 很多请求在某一时刻同时发出,导致要求返回的结果激增,响应缓慢。而在其他时间,很少或者没有请求。当处理请求以特定频率出现,或者在一天中的某个特定时间出现,就会产生这种情况。识别那些定期的,以特定间隔反复处理的功能,然后修改他们的处理时间,在给定时间范围内,随机分散到不同时间,以解决这个问题。 空间换时间 通过使用更多的存储空间,以节省执行时间。 空间换时间包括简单地预先存储结果,或者存储经常被访问的数据以方便计算;另一种空间换时间则包括选择特定的算法,如HASH算法就是一种典型的空间换时间的算法。另一种是OLAP技术,在此技术中,数据被按照一定的层级关系预先汇总,这样会大辐降低后续查询的耗时。 比如在慢SQL优化的时候,常用收段是识别频繁访问的字段并且设置索引,通过索引来缩短访问时延。 处理有效负载 识别出必须要处理的数据,排除对其他数据的重复处理。在一项处理数据的操作中,并非所有的处理数据都是必须处理的,可以通过分析,识别出必须处理的数据。可以有多种方式,来减轻负载的方法,如增量处理、变化通知等。 增量处理 变化通知 有效减负的反模式是“负载过重”,是在处理过程中,处理了大量不必要的处理数据,大辐增加了处理负载。出现这种情况的原因,有时为了简化处理过程,有时候是没有做必要性分析。可以通过对待处理数据进行分析,筛选出必须处理的数据,重新设计处理方案。 串行同步衔接 给线程/进程间的串行衔接设计紧密的衔接和同步措施,减少同步等待延时。 将一个串行处理通过划分多个线程并行处理,但各线程的处理又有一定的顺序和同步关系,需要设计合适的衔接和同步措施。同步方式可以是定时查询,也可以选择消息同步,或Event关联,选择的原则是衔接时间缝隙满足性能目标要求。 这个方法最佳的效果只是让整体性能略等于处理环节中最差的一个环境的性能(忽略线程切换及信号量等切换时间)。 父主题: 设计优化
  • SEC01-04 分隔工作负载 分隔工作负载是一种架构上进行分治的思想,通过将整个系统的工作负载分割成更小的部分,每个部分独立运行和管理,从而提高系统的安全性和可维护性。 风险等级 高 关键策略 一个企业特别是大型企业往往有多个不同类型(如生产环境、开发环境、测试环境)或不同组织单元(OU)下的工作负载,多个组织单元之间或多个工作负载之间要进行隔离。 分隔工作负载在云环境中是非常重要的。从安全治理角度,主要基于以下几个理由: 安全性:分隔工作负载可以降低潜在的安全风险。通过将不同的工作负载隔离在独立的环境中,可以减少一种工作负载受到攻击或故障时对其他工作负载的影响。 合规性:在一些行业和法规中,对数据隔离和访问控制有严格要求。通过分隔工作负载,可以更容易地满足合规性要求,保护敏感数据和确保数据隐私。 管理性:通过分隔工作负载,可以更轻松地管理和维护系统。每个工作负载都有独立的配置和管理需求,分隔可以简化管理流程并降低操作风险。 灵活性:分隔工作负载可以提供更大的灵活性和可扩展性。组织可以根据需要调整和扩展不同工作负载的资源,而不会影响其他部分。 华为云提供了以下几种工作负载的分隔机制: 通过多VPC分隔工作负载:将不同的工作负载部署在不同的VPC中,每个VPC具有独立的网络空间,实现网络隔离。 通过企业项目分隔工作负载:企业项目是云服务资源的逻辑集合,将工作负载部署在不同的企业项目中,实现资源的分组管理和权限控制。 通过多账号分隔工作负载:将不同的工作负载部署在不同的华为云账号中,每个账号具有独立的身份验证、访问控制和资源隔离。这种方法可以实现更严格的隔离和安全性。为每个账号分配最小必要权限,避免权限过度赋予。这有助于减少潜在的安全风险和权限滥用。针对需要跨账号访问的情况,使用适当的身份验证和授权机制,如跨账号委托、资源共享等。 多者结合:同时使用以上的两种或多种方式分隔工作负载。 相关云服务和工具 虚拟私有云 VPC 企业项目 EPS 统一身份认证 服务 IAM 华为云Landing Zone解决方案 组织 Organizations 资源治理中心 RGC 资源访问管理 RAM 父主题: SEC01 云安全 治理策略
  • 软件开发生产线(CodeArts) 软件开发生产线(CodeArts)是一站式、全流程、安全可信的DevSecOps平台,开箱即用,内置华为多年研发最佳实践,助力效能倍增和数字化转型。 CodeArts由以下几个主要服务构成: 需求管理:提供需求管理与团队协作服务,内置多种开箱即用的场景化需求模型和对象类型(需求/缺陷/任务等),可支撑IPD、DevOps、精益看板等多种研发模式,还包含跨项目协同、基线与变更管理、自定义报表、Wiki在线协作、文档管理等功能。 代码托管:基于Git提供分布式代码管理和协同开发能力,包括成员管理、权限控制、代码托管、代码检查、代码审核、代码追溯、持续集成等功能,助力不同规模企业的研发质量和效率提升。 流水线:提供可视化、可定制的持续交付流水线服务,实现缩短交付周期和提升交付质量的效果。 代码检查:为用户提供代码风格、通用质量与网络安全风险等丰富的检查能力,提供全面质量报告、便捷的问题闭环处理帮助企业有效管控代码质量,助力企业成功。 编译构建:基于云端大规模分布式加速,为客户提供高速、低成本、配置简单的混合语言构建能力,帮助客户缩短构建时间,提升构建效率。 部署:支持主机、容器等多种部署形态,部署能力覆盖Tomcat、Springboot等多种语言和技术栈。基于其对部署功能的插件化封装和编排能力,帮助您实现软件的快速、高效发布。 测试计划:覆盖测试计划、测试设计、测试用例、测试执行和测试评估等全流程,旨在帮助企业协同、高效、可信的开展测试活动,保障产品高质量上市。 制品仓库:用于管理源代码编译后的构建产物,支持Maven、Npm等常见制品包类型。可以与本地构建工具和云上的持续集成、持续部署无缝对接,同时支持制品包版本管理、细粒度权限控制、安全扫描等重要功能,实现软件包生命周期管理,提升发布质量和效率。 CodeArts IDE Online:基于云计算的轻量级WebIDE,通过浏览器即可实现环境快速获取和环境访问,完成编码、构建、调试、运行、访问代码仓库和命令执行等工作,支持第三方业务集成,支持插件扩展并提供独立插件市场。 开源镜像站:由华为云提供的开源组件、开源操作系统及开源DevOps工具镜像站,目前已提供Maven、NPM、NuGet、CentOS、Ubuntu、Debian等镜像下载服务。 父主题: 卓越运营云服务介绍
  • RES02-03 定期进行备份数据恢复 通过定期恢复测试,可以验证备份数据的完整性与恢复处理过程是否可用,且数据丢失时间以及恢复时间符合数据的RPO与RTO指标要求。 风险等级 高 关键策略 定期执行备份数据恢复,以验证备份的完整性。 为了避免备份恢复对生产业务造成影响,可以构建一个测试环境,并使用已有的备份数据进行恢复处理。 华为云云服务提供了手工恢复功能,用户可定期执行恢复操作,以进行恢复测试。 相关云服务和工具 云备份 CBR 云数据库 RDS 分布式缓存服务 D CS 父主题: RES02 备份
  • COST04-02 主动监控成本 风险等级 中 关键策略 不要只在出账后或收到异常通知时再查看成本和用量,应使用工具定期检查成本。定期监控和主动分析成本,有助于您及时识别成本趋势,避免异常发生。 相关服务和工具 创建预算提醒,将预算设置为提醒阈值,在预测或实际成本超出预算时,及时获取超预算通知,防止潜在成本超支。 创建成本监控,华为云成本中心的成本监控引入机器学习,对客户历史消费数据进行建模,对于不符合历史数据模型的成本增长,识别为异常成本记录,同时提供异常增长的Top潜在原因。客户可设置监控提醒,定期获取影响成本高的异常记录提醒,进而快速做出反应,维持预期的成本支出。 在费用中心设置可用额度监控,在可用额度余额低于阈值时预警,避免客户额度耗尽,业务中断。 使用资源包监控,在资源包剩余不足预警,避免资源包用尽自动转为按需计费。 使用成本分析预置报告或创建常用的成本分析报告,定期快速了解成本分布和趋势。 父主题: COST04 持续进行成本治理
  • RES03-04 支持容灾管理 提供容灾管理功能,实现容灾状态及RPO监控,及异常场景下的业务切换。 风险等级 高 关键策略 实时监控容灾状态,了解容灾运行状态。 支持应用级数据校验,比较AZ间数据同步差异,监控及PO指标。 典型确定性故障场景下自动容灾或切换,无需人工接入,业务不受影响,满足RPO/RTO指标。 典型亚健康故障场景,支持业务降级或主动切换,业务不持续受损。 相关云服务和工具 多活高可用服务 MAS 父主题: RES03 跨AZ容灾
  • OPS06-04 规范化应用日志 日志是随时间推移发生的不可变、记录时间戳的离散事件。系统需要记录关键事件和故障,以帮助诊断问题和解决故障。 风险等级 高 关键策略 对于一个系统来说,日志是非常重要的。它可以记录在系统中发生的一切,包括成功的操作、错误的操作、警告信息等等。因此,日志记录是可观测性设计中最基本的需求之一。通过将事件和错误信息记录到日志文件或数据库中,可以方便地进行故障排除和问题诊断。但是,仅仅记录日志并不足够,还需要对日志进行有效的管理和分析。如果日志太多,将会成为一个负担,因为它们需要占用存储空间,并且需要花费很长时间来查找有用的信息。因此,需要对日志进行过滤和归档,以便更好地管理它们。 设计建议 可参考LTS最佳实践 父主题: OPS06 可观测性体系
  • RES03-01 集群跨AZ部署 应用内所有组件均采用跨AZ容灾部署,以避免单AZ故障时业务中断。 风险等级 高 关键策略 云服务实例具备跨AZ高可用实例时,优先使用云服务实例自身的跨AZ高可用实例。 云服务实例只支持发放单AZ实例,不支持跨AZ高可用实例时,需要借助其他云服务或应用层实现跨AZ容灾;以ECS为例: 对于无状态ECS实例,可利用AS弹性伸缩服务的跨AZ伸缩能力,或ELB跨AZ负载均衡能力,实现跨AZ高可用,在一个可用区故障时能自动快速切换。 对于有状态ECS实例,或BMS实例,建议从应用层实现跨AZ容灾,支持跨AZ自动切换或通过容灾管理工具实现自动化容灾切换,减少灾难发生时的人工操作。 对于已部署的应用系统改造为跨AZ实例的实施步骤: 确定应用系统的关键组件;所谓关键组件是指一旦故障,会导致整个应用系统或其中的关键功能受损。 针对关键组件,检查其跨AZ高可用能力,即在一个AZ故障的情况下,是否能自动故障转移到另外一个AZ,进行业务恢复。 针对未支持跨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数据库 等。 父主题: RES03 跨AZ容灾
  • PERF05 性能优化 性能优化工作中,需警惕“过早优化”的问题。我们的基本指导策略还是首先让系统运行起来,再考虑怎么让它变得更快。一般只有在我们证实某部分代码的确存在一个性能瓶颈的时候,才应进行优化。除非用专门的工具分析瓶颈,否则很有可能是在浪费自己的时间。另外,性能优化的隐含代价会使我们的代码变得难于理解和维护,这一点也是需要权衡和关注的。 设计优化 算法优化 资源优化 父主题: 性能效率支柱
  • SEC08-07 数据主体有权访问其个人隐私数据 数据主体有权访问其个人隐私数据是指根据相关的隐私保护法律和规定,个人拥有权利要求数据处理者提供关于其个人数据的访问权限。 风险等级 高 关键策略 向用户提供查询、更新个人数据的功能,且必须是实时、无成本,符合主体参与原则。 数据主体访问个人数据之前必须有认证机制。 记录数据的录入或者更新的时间。 建议提供必要的校验措施,比如通过Web页面的输入框录入e-mail地址的时候,校验e-mail地址格式的合法性等。 针对用户的注册信息,必须为用户提供修改其注册信息的途径。 用户修改隐私偏好的设置和选项要便于用户发现和使用。 对于收集、处理、存储个人数据的系统,应提供数据主体限制其个人数据处理机制。 对于收集、处理、存储个人数据的系统,应提供数据主体提供的个人数据导出的机制。 父主题: SEC08 数据隐私保护
  • 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 父主题: RES03 跨AZ容灾
  • RES05-01 网络连接高可用 应用系统对外提供服务时,需要确保对外网络连接的高可用,避免单个网络连接中断而导致业务不可用。 风险等级 高 关键策略 网络链路冗余:网络连接需要支持多路径,以实现高可用能力,以避免在一条网络路径中断的情况下,业务能切换到其他路径继续通信。 网络链路快速倒换:需要定期检查网络链路的连通性,但检测到失败时需要尽快切换到正常路径。 公有云组网场景可通过多EIP 弹性IP及DNS 域名 解析实现网络连接的高可用;对可用性要求较高的场景,需要支持智能DNS功能,能对EIP进行异常监控和自动切换;此外DNS自身也需要冗余容错,避免由于DNS故障而导致域名解析失败,业务中断。 混合云组网场景链路冗余与倒换方案: 双DC专线冗余:用户数据中心与华为云VPC之间采用两条DC专线互通;其中两条物理专线接入同区域的两个华为云专线接入点,并通过BGP路由协议接入同一个VPC,用户可设置虚拟接口的优先级以决定业务的主备链路。具体的方案参见“用户通过双专线双接入点BGP协议访问VPC”。 双VPN冗余:用户数据中心与华为云VPC之间采用两条VPN连接保证可靠性;当其中一条VPN链接故障时,系统可以切换到另一条VPN连接,保证网络不中断。两条VPN连接可以是双活或主备部署。具体的方案参见“通过VPN实现云上云下网络互通(双活模式)”与“通过VPN实现云上云下网络互通(主备模式)”。 DC专线/VPN主备:用户数据中心与华为云VPC之间同时部署DC专线和VPN两条网络链路,互为主备,并通过企业路由器,可以实现DC和VPN主备链路的自动切换,不需要手工切换双联路,不仅避免业务受损,同时降低维护成本。具体的方案参见“通过企业路由器构建DC/VPN双联路主备混合云组网”。 相关云服务和工具 云专线 DC 虚拟专用网络 VPN 父主题: RES05 网络高可用
  • 电商类应用典型部署架构(99.99%) 电子商务类应用用于外部客户,需要提供较高的可用性,并能承受组件故障,其可用性目标通常要求达到99.99%,即每年故障时间可以为52.56分钟。 假定故障中断与变更中断的时长分别如下: 故障中断:假定每年故障中断3次,每次应急恢复决策时长为10分钟,恢复处理时长为5分钟,则每年故障中断时长为45分钟。 变更中断:假定应用支持金丝雀部署或蓝绿部署,并自动完成,软件更新不中断业务。 按照以上评估,每年应用系统不可用的时长是45分钟,满足可用设计目标要求。 电子商务类应用典型架构为前端无状态应用层+后端数据库,其中前端无状态应用可采用ECS或CCE;后端数据库基于不同业务类型可采用不同数据库,通常采用RDS for MySQL;同时通常还会使用DCS、Kafka等中间件及DDS文档数据库;为满足对应的可用性目标,建议采用以下方案。 单Region方案 双Region方案 父主题: 参考架构
  • 选择合适的计算资源 评估计算要求涉及评估工作负载的特定计算需求,包括实例类型、可伸缩性和容器化等因素。不同的计算服务具有不同的功能和特征,可能会影响工作负载的性能。选择最佳计算服务以确保工作负载高效运行。请考虑以下策略: 了解实例类型 不同的实例类型针对不同的工作负载进行优化,例如CPU优化、内存优化和GPU优化,选择符合需求的实例类型。 考虑自动缩放 如果工作负载的需求不定,请考虑具有自动缩放功能的计算服务,该功能可根据需求自动调整计算容量。自动缩放有助于确保在高峰期拥有足够的资源,并防止在低需求时段过度预配。 考虑容器化 与非容器化工作负载相比,容器具有性能优势。如果适合体系结构需求,请考虑使用容器化。容器可以通过隔离、资源效率、快速启动时间和可移植性来提高计算性能。 使用容器时,请考虑设计因素,例如将所有应用程序组件容器化。将基于Linux的容器运行时用于轻型映像。为容器提供较短的生命周期,使其不可变且可替换。从容器、容器主机和基础群集收集相关日志和指标。使用此数据监视和分析性能。容器只是整体体系结构的一个组件。选择适当的容器业务流程协调程序(如Kubernetes),以进一步增强性能和可伸缩性。 PERF03-01 选择合适类型的计算云服务 PERF03-02 选择合适规格的虚拟机和容器节点 PERF03-03 使用弹性伸缩 父主题: PERF03 性能建模
  • SEC05-05 证书安全管理 证书的常见用途包括传输数据的加密和系统间的身份认证场景。集中管理每个证书的用途、有效期等信息,并及时对证书替换。 风险等级 中 关键策略 集中管理证书: 建立中心化的证书管理系统,用于存储、跟踪和管理所有证书。 确保每个证书都有清晰的标识,包括用途、所有者、有效期等信息。 有效期管理: 定期检视证书的有效期,并确保及时对即将到期的证书进行更新或替换。 避免使用过期证书,以防止安全漏洞和服务中断。 安全存储: 将证书存储在安全的位置,只允许授权人员访问。 对私钥进行额外保护,如使用硬件安全模块(HSM)来存储私钥。 加密传输: 在证书的传输过程中使用加密通道,如SSL/TLS,以防止证书被篡改或窃取。 避免在不安全的网络中传输证书,确保传输的安全性。 相关云服务和工具 云证书管理服务 CCM:CCM提供SSL证书的申请、签发、查询、吊销等一站式管理服务。 父主题: SEC05 运行环境安全
  • SEC07-03 对数据操作实施监控 根据数据的分级分类,应对数据的修改、批量操作等行为实施限制措施或建立监控机制。 风险等级 高 关键策略 对数据的修改、批量操作等行为实施限制措施或建立监控机制。 使用数据库安全服务DBSS对数据库行为进行审计。数据库安全审计提供旁路模式审计功能,通过实时记录用户访问数据库行为,形成细粒度的审计报告,对风险行为和攻击行为进行实时告警,对数据库的内部违规和不正当操作进行定位追责,保障数据资产安全。 启用数据库安全审计告警。通过设置告警通知,当数据库发生设置的告警事件时,用户可以收到 DBSS 发送的告警通知,及时了解数据库的安全风险。 使用 云堡垒机 服务CBH识别并拦截数据库高危命令。CBH提供数据库控制策略功能,用户可设置预置命令执行策略,动态识别并拦截高危命令(包括删库、修改关键信息、查看敏感信息等),中断数据库运维会话。同时自动生成数据库授权工单,发送给管理员进行二次审批授权。 相关云服务和工具 数据库安全服务 DBSS 云 堡垒机 CBH 父主题: SEC07 通用数据安全
  • SEC08-06 向第三方披露个人数据合规性 在将个人数据分享、转移或提供给第三方时,数据控制者必须遵守相关的法律法规和隐私保护准则,以确保数据转移活动符合法律规定并尊重数据主体的权利。 风险等级 高 关键策略 产品需评估是否存在将个人数据推送给第三方应用。评估是否存在高度敏感的用户数据在未获得用户明示同意便推送。同时应该对齐第三方应用,是否对共享的数据设置了合理的保护机制。 用户个人数据转移给第三方前须经过用户同意,符合合法性原则。 转移的目的和范围不能超出收集时所声明的目的和范围。 必须保证个人数据的准确性、完整性和最新状态,保证在任何阶段和环节不能随意篡改、删除、滥用个人数据。 输出者必须获得接收者的明确承诺,保证个人数据的完整性、准确性和安全性,防止滥用及不正当披露。 高影响个人数据(包括口令,银行帐号,批量个人数据等)的传输须采用安全传输通道或者加密后传输。 如涉及数据的跨境传输,需遵从当地的法律法规。 父主题: SEC08 数据隐私保护
  • OPS03-01 推行开发者测试 风险等级 高 关键策略 开发者测试是现代软件工程中非常重要的一环,一般而言,开发者的测试代码可以在本地,或者构建阶段反复多次执行,依赖低,也是在软件系统运维之前成本最低的发现软件问题的方式,尤其是各种异常场景或者用户输入,开发者测试的过程实际上“强制”了开发者去思考线上业务可能出现的场景,从而有利于减轻后续运维阶段系统的负担。 此外,云上的软件是不断演进和重构的,很多时候我们不敢修改已有系统代码的原因,就是不知道它的影响范围,担心产生某种程度上的蝴蝶效应,影响了其它模块而造成线上系统的问题,有了开发者测试之后,只要在改完代码后运行一下测试就知道改动对整个系统的影响了,从而可以让我们放心的重构和演进代码。 同时,应该有一个适用于您软件的开发者测试标准,如代码覆盖率和分支覆盖率。 父主题: OPS03 完备的测试验证体系
  • COST01-04 指定云资源管理策略和相应的权限管理机制 风险等级 高 关键策略 由于成本优化是跨组织多个业务部门的事项,而云资源是云上成本的主要开销,故而应该制定策略,确定您的组织应该如何管理资源。如上文所说的,可以使用账号隔离不同组织/部门的资源,甚至于在同一个组织/部门内部,开发,测试,核心业务,非核心业务,也使用不同的账号和环境。 然而即使账号/环境是分散的,云资源管理策略和权限管理机制应该是集中的。 企业的中心团队,如上文所提的云业务办公室、云卓越中心或 FinOps 团队需要为各个账号环境实施与策略一致的组和角色,控制每个组中谁可以创建、修改或停用实例和资源。同时依据企业的业务环境,创建统一的资源/成本视图,统一管理企业的账单和成本。 相关服务和工具 客户可通过统一身份认证服务IAM的细粒度权限管理,精细化控制账号下用户的资源访问权限,实施最小授权。 对于多账号场景,客户可通过Organization的服务控制策略(Service Control Policy),集中控制每个账号可执行的操作。 父主题: COST01 规划成本优化相应的组织机构和流程
  • COST03-03 公共成本分配 风险等级 中 关键策略 跨团队共享使用的CDN、直播带宽应按照各业务团队的实际带宽占比,将带宽费用拆分到不同的业务团队。 跨团队共享使用的CCE集群服务,应按照各团队分配和使用的CPU/内存等比例,将容器集群成本(包含CCE、ECS、EVS等服务成本)拆分到各个业务团队。 以上公共成本,以及其他共享资源&平台服务&服务支持&未及时标记产生的未分配成本,也可以按照一定的比例规则,比如平均分配、按消费比例分配、按约定比例分配等规则,拆分到各个业务部门,从而满足各团队或业务部门公平分配公共成本的需求 相关服务和工具 华为云成本中心的成本单元提供按比例的公共成本分拆方式。 华为云成本中心提供共同成本分拆,支持CDN、Live按照域名流量进行成本分拆。 华为云CCE服务提供细化的按照Pod Level的成本分拆,并可以卷积到Workload,Service等各种标准K8S模型层级。 父主题: COST03 对成本进行分配
  • 责任共担模型 基于华为在安全、合规、隐私及数据保护领域积累多年的技术和治理能力,华为云为您提供安全、可靠、可信赖的基础设施和服务。华为云提出“七层防线+一个中心”的网络安全建设框架,通过多重、多方面的安全防线来成体系保障云上业务的安全性。 华为云把安全合规作为首要任务,安全是华为云和您之间的共同责任。在云服务模式下,华为云与客户共同承担云环境的安全保护责任,为明确双方的责任,确定责任边界,华为云制定了责任共担模型。华为云负责云的安全性,华为云客户负责云上的安全性。 详细内容见:华为云责任共担模型 父主题: 概述
  • 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会主动隔离异常节点,虽然业务会在正常节点上分担,但应用系统实际已损失了部分处理容量。因此,云服务状态监控必不可少。 云服务具体指标因功能特性而异。站在功能提供者的层面,通常同样需要重点关注延迟、流量、错误率、利用率等指标。此外,服务实例的动态伸缩、过负荷控制、故障自愈或迁移等可靠性关键事件也是服务健壮性的表征,如有异常需要预先干预。关键事件监控可以使用 CTS 服务,或自行搭建。 CES服务支持ECS、EVS、OBS、VPC、ELB、AS等IaaS服务,以及RDS数据库,DCS、DMS等高可用中间件的主要指标监控,支持用户上报自定义监控指标。如果用户自行搭建监控系统,也可以通过CES SDK获取指定服务的监控指标。 AOM服务提供了微服务应用和节点的关键指标监控能力。云容器工作负载关键指标在CSE服务中查看。函数服务关键指标在FunctionGraph控制台中查看。 3、资源监控 资源监控通常用于识别资源瓶颈分析系统性能问题。对应用系统资源进行监控时,需要先定义资源的关键指标以及对应的阈值,以便快速有效的发现业务表现和系统状态,以便在异常状态下尽早干预恢复,或定位改进系统缺陷。 关键指标需要与系统内工作负载的关键性能指标相关,并能确定为系统性能下降的早期警告信号,如系统处理的API数量及成功率,相比CPU利用率、内存利用率等基础指标,能更真实的指示系统性能问题。 常用USE方法(Utilization Saturation and Errors Method)对资源监控,包含: 使用率Utilization:覆盖系统资源,包括但不限于CPU、内存、网络、磁盘等。 饱和度Saturation:针对资源的饱和度,如CPU队列长度,注意与业务监控的黄金指标相区分。 错误Errors:资源处理错误,如网络丢包率等。 CES主动监控提供了虚机细粒度的监控能力,其他服务监控指标也不同程度涉及到资源使用率和错误监控。如果云服务现有能力不能满足系统要求,用户可使用CES或AOM服务的自定义指标监控能力。用户若自行搭建监控系统,需要覆盖主机资源、网络设备和Apache、Java、MySQL等第三方组件,开源的Zabbix是常见选择。 相关云服务和工具 云监控服务 CES 应用运维管理 AOM 应用性能管理 APM 父主题: RES07 监控告警
  • 什么是应用韧性 应用韧性是应用系统在运行过程中面对各种异常场景,如基础设施故障(如数据库异常)、外部攻击(如网络DDoS攻击超出预定限额流量)、外部依赖故障(如依赖系统访问超时或不可用)、地域灾难(如大面积停电、洪水)等,仍能提供和维持可接受的服务水平的能力,对系统至关重要。 系统韧性设计主要涉及以下两个方面: 确保系统具有高可用的架构,如无单点故障 各种故障场景下的恢复能力,如数据丢失、设备或站点故障等场景均能恢复 相对于传统数据中心,华为云可以提供具备高可用、弹性伸缩、自动备份、跨AZ容灾、跨Region容灾等高可用能力的基础设施与云服务,便于客户构建高可靠的系统。例如: EVS云硬盘、OBS对象存储采用分布式存储,可避免单个硬盘、单个服务器或单个机架等硬件故障的影响。 RDS数据库提供自动数据备份、跨AZ和跨Region的数据复制与切换。 不过,即使应用系统利用云平台能力具有了这些高可用能力,要实现较高的可用性,仍需要构建针对各种偶发故障下的恢复能力,如: 由于硬件故障导致的高可用切换或跨AZ切换过程中,导致瞬时链接中断,需要应用系统具备链接中断重试的功能。 由于外部流量突发导致业务过载,需要应用系统具备流量控制的能力。 部分强依赖于硬件的负载,如依赖本地硬盘、GPU等,由于硬件故障导致服务中断,需要应用系统自身构建高可用的能力。 不同的应用系统,可用性要求可能不同,采用的韧性恢复方案会有差异。 父主题: 基本概念
  • RES05-04 预留IP资源以便扩展及高可用 云上网络需要满足可扩展以及高可用需求,以便在云上资源弹性伸缩或业务扩展时,有足够网络资源支撑业务发展。 风险等级 高 关键策略 云上网络规划设计应满足以下原则: 针对每个Region,根据业务需要规划不同的VPC,每个VPC使用独立的地址空间;并需要预留IP地址空间用于新建VPC。 针对每个VPC中,需要根据业务需要规划子网和IP地址空间;并需要预留IP地址空间用于新建子网。 针对每个子网,需要预留IP地址空间用于网络扩容。 当涉及与其他网络(如VPC、IDC或其他云)互连时,需要确保IP地址空间不重叠。 父主题: RES05 网络高可用
共100000条