华为云用户手册

PERF01-01 全生命周期性能管理 风险等级 高 关键策略 指定性能目标 从性能角度来看，最好为性能场景定义具体的、量化的、可测量的性能目标。若要设置这些目标，需要充分了解业务要求以及预期将提供的服务质量。 需要与业务利益干系人共同关键功能的体验要求，而不是只关注技术指标。通过明确地说明性能需求来控制性能，说明要足够明确，以便可以定量地确定软件系统是否满足该目标。具体要求： 定义明确的性能需求目标 避免使用定性的、模糊的性能目标 为每个性能场景定义一个或多个目标 性能指标项的粒度要合适 功能够用 在业务初期的设计阶段，要考虑简化组件/模块/方法/类的功能设计，避免设计面面俱到的多功能组件/模块/方法/类；调用功能时，避免功能过剩、并对性能影响较大的调用；选择云服务的时候，选择合适的云服务，结合业务的特征选择合适的云服务类型和规格，利用好云弹性的特性的优势。设计功能过于复杂的组件，有时候是为了通用，有时候则是一种不好的软件设计习惯。够用原则适用于自己设计或者调用已有的功能，使用时注意避免过度设计。 性能可观测 在业务系统开发维护阶段，采取措施（例如在关键点插入代码，探测器）使测试和分析负载场景、资源需求、性能目标达成一致。使用监控工具来分析历史趋势，并识别支配性占比的数据流和代码实现路径。本原则强调采取措施使性能指标可测试，可以利用商用工具测试质量指标，也可以在设计时考虑相关性能指标的可测试性措施。需要测试的数据包括响应时间，处理容量，也包括功能/模块被执行频度等指标。 通过优化提高效率 在初始阶段设置的目标考虑到各种约束和业务目标，随着业务的增长应不断进行调整。为了进一步优化性能效率，需要清楚地了解系统的使用方式、演变过程，以及平台或技术是如何随时间变化的。需要预留足够的时间来进行持续的性能优化，可以构建性能驱动的优化文化，让团队成员主动监视性能数据；通过指标数据驱动改进，使用新的设计模式和新的技术来优化体系结构。 性能优化成熟度模型 父主题： 全生命周期性能管理

RES10 故障隔离 当系统某个单元发生故障时，如果不采取措施，故障可能会大规模扩散，从而造成整个系统失效。故障隔离技术的核心思想是将一个工作负载内的故障影响限制于有限数量的组件内，降低故障影响范围，防止产生级联故障。 通过划分故障隔离域，限制工作负载的影响，可有效进行故障隔离。 RES10-01 应用控制平面与数据平面隔离 RES10-02 应用系统多位置部署 RES10-03 采用Grid架构 RES10-04 健康检查与自动隔离 父主题： 故障快速恢复

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

DMS分布式消息服务 DMS分布式消息服务支持以下各种消息类型： Kafka版：基于开源社区版Kafka提供的消息队列服务，向用户提供计算、存储和带宽资源独占式的Kafka专享实例。 RabbitMq版：完全兼容开源RabbitMQ，提供即开即用、消息特性丰富、灵活路由、高可用、监控和告警等特性，广泛应用于秒杀、流控、系统解耦等场景。 RocketMQ版：低延迟、弹性高可靠、高吞吐、动态扩展、便捷多样的消息中间件服务。 可靠性功能 常见故障模式 父主题： 云服务可靠性介绍

事前规划，做好成本模型，预算规划和成本预测 理解每个组织，项目的成本并非易事，尤其是很多云资源是事实上的跨组织和项目的公共资源，故而，在一开始的时候，就需要建立一个基础的，得到管理团队认可的成本模型，用于在以后的成本优化执行过程中确保整体的成本可追溯性。 在确定成本模型之后，则需要设立一个预算规划，同时在各种基于云的项目一开始的时候，就引入该预算规划和成本管理，同时设定不同层次的预算开销的阈值，用于成本的预警 。 最后，对于使用了一段时间华为云的账号，华为云也提供了成本预测工具，基于用户的实际上云成本，提供了未来的预测，善用这些工具，云用户可以根据预算情况，设立基于预测的告警。

持续监控，了解账单和资源使用情况 成本优化不是一个“一锤子买卖”，随着业务的发展，云资源的申请和释放是不停变化的，使用云的软件/服务的架构也是随时在演进。 企业应建立定期的云成本监控和审查机制，并根据实际情况调整和完善云成本优化策略。比如一个快速增长的业务组织更多地可能会偏向于提升业务的速度，而设计一个比较宽松的云成本优化策略，而稳定的业务组织则可以以成本效率为主要考量，设计比较严格的云成本优化策略。 企业还可以借助华为云成本中心提供的云成本管理工具和平台来实现自动化的成本监控和优化。

节省和优化，使用不同的计费模式，资源优化和架构优化 云支出的主要影响因素是费率和用量，结合云化业务模型和成本数据分析，可以使用不同的优化措施。从费率上，云服务存在按需、包年包月、资源包、竞价实例等多种计费模式，不同的计费模式有着不同的适用场景。企业可以根据自己的需要，合理选择各种计费模式来适配不同的业务形态和降低费率，实现成本节省。从用量上，企业可以通过资源优化，释放闲置资源，降配等降低资源用量，或者通过离在线混部，弹性缩扩容等架构方案实现资源复用和闲时释放，也达到了资源用量的节省。费用优化、资源优化和业务架构优化代价逐步增高，对业务的影响也依次增大。企业可以根据业务目标、对业务影响、优化代价和收益的评估，确定优化目标和优化措施优先级。确定优化措施。

组织，流程和成本管理相匹配 在成本优化过程中，一个很重要的原则是需要将组织结构，流程和成本管理相匹配。需要建立“责权分明”的体系，否则即使用再好的成本优化工具，也无法将成本优化落到实处。 流程上，需要把成本管理作为各个上云流程中必备的一环； 组织上，需要投入适当的时间，资源和人力用于建立 云财务管理 的能力。 例如，在云账号申请和云资源申请的时候，就需要建立完善的流程，以便于将组织，项目和其所使用的云账号，云资源进行关联，并确保每个部门或团队都对其使用的资源负责。而在最终的企业财务层面，引入云财务管理的能力，也有助于理解企业的每个子部门的产出和成本的关系，甚至于清晰地了解企业每挣一块钱，最终的云成本是多少，这样企业不至于为了完成本优化，而牺牲自身真正的产出。 在最终实际的优化实施阶段，由于成本优化往往需要运营，运维，研发等多个部门的参与，也涉及到平台部门和业务部门的合作，故而需要确定一个各个组织成员都参与的完善流程，如释放空闲资源的流程。 企业也可以定期生成报告，并同步给干系人；同时联席例会，如组织多角色参与的例会(如月度例会)，审视预算执行情况、讨论风险应对策略、总结优化经验和计划下一步重点工作等；

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

SEC06-05 执行渗透测试 渗透测试是一种安全评估方法，模拟攻击者的行为，通过模拟真实的攻击场景来评估系统、应用程序或网络的安全性。渗透测试旨在发现系统中的安全漏洞、弱点和潜在的安全风险，以帮助组织改进其安全措施、加固防御，并保护系统免受真实攻击的威胁。 风险等级 高 关键策略 建议在开发周期的后期执行渗透测试，使系统功能接近预期发布状态，但也要留有足够的时间来解决发现的问题。 采用结构化流程：使用结构化流程确定渗透测试的范围，基于威胁建模的模型保持场景相关性，以确保全面评估系统的安全性。 自动化测试：利用工具自动执行常见或可重复的测试，以加快渗透测试的速度，并提高效率。 分析测试结果：对渗透测试结果进行深入分析，以确定系统性安全问题，并为进一步的自动化测试和开发者培训提供有用信息。 为构建者提供培训：提供培训，让开发者了解从渗透测试结果中可以期待获得什么，以及如何获取有关修复的信息，以促进问题的及时解决。 父主题： SEC06 应用安全性

RES04-02 部署容灾系统以满足容灾目标 针对不同应用系统的容灾目标，需要综合考虑中断概率、容灾成本等因素，来决定采用什么样的容灾方案来实现这些目标。 风险等级 高 关键策略 面向跨Region/跨云容灾场景，可基于不同的可用性目标要求，采用不用的容灾方案，如远程备份、主备容灾、双活容灾等，其中生产站点根据场景不同可能为其他云或IDC或华为云Region： 远程备份：生产站点内的重要数据，备份到异地华为云灾备Region，当生产站点发生灾难时，需要在异地灾备Region新部署一套业务系统并使用最新备份数据恢复数据，并恢复业务。 主备容灾：生产站点与华为云灾备Region各部署一套业务系统，并将生产站点的重要数据异步复制到灾备Region；平常只有生产站点提供业务，当生产站点发生灾难时，将灾备Region提升为主，并将业务流量切换到灾备Region并由其提供业务。 双活/多活容灾：生产站点与华为云灾备Region各部署一套业务系统，并将各自站点的重要数据异步复制到其他站点；每个站点都同时提供业务，通过全局负载均衡器进行流量分发；当一个站点发生灾难时，则将业务流量全部分发到其他站点来接管其业务。 以跨Region主备容灾为例，对于已在一个Region部署应用系统后，增加支持跨Region主备容灾能力的实施步骤建议如下： 选择另一个Region作为灾备Region，部署一套相同的应用系统，包括工作负载、数据库实例等。 针对应用系统内的关键数据，利用云服务或应用系统自身实现跨Region的数据复制。 若云服务实例支持跨Region容灾，则配置生产站点与灾备Region之间的复制，如对于RDS数据库实例，需申请DRS实例对主Region与灾备Region的数据库进行实时复制；对于OBS桶，需要配置主Region中的OBS桶到灾备Region中OBS通的复制。 若云服务实例不支持跨Region容灾，但数据比较关键，则需要应用层实现跨Region的数据双写，以进行数据同步。 接入侧主Region与灾备Region各自申请外部IP，并通过DNS 域名 解析到主Region，在主Region故障时，将DNS域名对应IP地址修改为灾备Region中的外部IP。 申请MAS多活高可用服务，进行容灾编排，以便在灾难场景快速主备切换恢复业务。 相关云服务和工具 云备份 CBR：支持跨区域复制与恢复 数据复制服务 DRS：支持RDS for MySQL、 GaussDB for MySQL等数据库的实时灾备，支持跨Region/跨云容灾场景 对象存储服务 OBS：支持跨区域复制与双活 父主题： RES04 跨Region/跨云容灾

PERF03-11 选择合适的非关系型数据库 风险等级 中 关键策略 华为云数据库提供了DDS、GeminiDB两种非关系型数据库服务。 DDS：文档数据库服务（Document Database Service）完全兼容MongoDB协议，提供安全、高可用、高可靠、弹性伸缩和易用的数据库服务，同时提供一键部署、弹性扩容、容灾、备份、恢复、监控和告警等功能，适用于游戏、物联网业务、互联网应用等多个场景。 GeminiDB Redis接口：GeminiDB Redis接口是一款基于华为自研的计算存储分离架构，兼容Redis生态的云原生NoSQL数据库，基于共享存储池的多副本强一致机制，支持久化存储，保证数据的安全可靠。具有高兼容、高性价比、高可靠、弹性伸缩、高可用、无损扩容等特点，适用于游戏、推荐、GIAmgGAP、推送等场景。 GeminiDB Influx接口：GeminiDB Influx 接口是一款基于华为自研的计算存储分离架构，兼容InfluxDB生态的云原生NoSQL 时序数据库 。提供大并发的时序数据读写，压缩存储和类SQL查询，并且支持多维聚合计算和 数据可视化 分析能力。具有高写入、灵活弹性、高压缩率和高查询等特点，适用于IoT、金融、软硬件设备实时监控、数据采集等场景。 GeminiDB Cassandra接口：GeminiDB Cassandra 接口是一款基于华为自研的计算存储分离架构，兼容Cassandra生态的云原生NoSQL数据库，支持类SQL语法CQL。具有安全可靠、超强读写、弹性扩展、便捷管理等特点，适用于互联网应用、工业数据采集等场景。 GeminiDB Mongo接口：GeminiDB Mongo 接口是一款基于华为自研的计算存储分离架构，兼容MongoDB生态的云原生NoSQL数据库。具有企业级性能、灵活弹性、高可靠、可视化管理等特点，广泛应用于游戏应用等场景。 GeminiDB HBase接口：GeminiDB HBase接口是一款兼容HBase生态的分布式NoSQL数据库，在Apache HBase的基础上进行扩展和优化，具有高性能、高可靠性、强大的扩展性和灵活的伸缩性等特点，适用于金融、电信、物流、游戏等场景。 同关系型数据库一样，非关系型数据的选择同样主要基于兼容性与场景评估两个原则： 场景一：基于兼容性原则 考虑平滑上云，上云前系统中数据库的选型已经过业务实践的检验，建议选取生态相同的关系型数据库服务进行平替，避免出现数据库层与应用层不兼容或数据库切换对业务架构中其他组件产生负面影响。 场景二：基于场景评估 如果是在云上新建业务系统或基于同数据库不同服务中选取时，建议结合业务的实际需要选取合适的数据库服务，如考虑性能、安全性等因素，产品详细介绍与规格信息可参考官方文档。 父主题： 选择合适的数据库资源

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

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

SEC01-06 识别并验证安全措施 根据团队制定的安全基线以及威胁建模分析的结果，对工作负载中涉及的安全措施进行验证，以确保它们按照预期方式运行并有效地保护系统，从而缓解或消除安全威胁。 风险等级 高 关键策略 依据系统的安全设计文档，通过验证确保安全措施被正确地集成到系统中，并符合最佳实践和标准。 尽早检视系统的代码（此过程称为代码白盒安全检视），确保代码符合安全最佳实践，避免在后续阶段发现严重的安全漏洞。 利用安全测试工具进行静态代码分析、动态代码分析、 漏洞扫描 等测试，以发现潜在的安全问题。 使用模拟攻击工具或技术，尝试模拟攻击者的行为，以评估系统的安全性和弱点。 父主题： SEC01 云安全 治理策略

RES04-01 定义应用系统的容灾目标RPO与RTO 在进行容灾设计前，需要根据应用系统的重要性，明确其容灾目标，通常以RPO和RTO指标来定义： RPO：允许的数据丢失量，与数据的周期性复制周期或连续性复制延时相关。 RTO：允许的业务恢复时长，即业务中断时长，与灾备端业务的部署与切换方式相关。 风险等级 高 关键策略 不同的业务系统重要性不一样，针对应用系统内的各种业务，需要明确其重要性及对应的RPO/RTO指标要求。比如对于核心业务，通常需要保障业务的连续性，允许业务中断的时间会比较少，从而需要保障故障场景下的业务快速恢复，可采用双活/多活容灾；对于重要业务，允许一定的业务中断时间，可采用主备容灾；对于一般业务，允许中断的业务时间可达到天级，则可采用远程备份；对于一些不重要的业务，其业务中断对外部客户没有影响，则不需要进行容灾。 父主题： RES04 跨Region/跨云容灾

RES12-04 出现问题后尽快恢复业务 应用系统出现故障后，需要能尽快发现，尽快响应。 风险等级 高 关键策略 可以通过以下途径实现故障的快速发现： 监控：应用系统需要提供业务监控信息，以便实时了解系统运行状态；维护团队需要有专人观测，并在发现故障发生时，需要及时响应。 告警：应用系统在检测到故障后需要及时告警，并能通过短消息、邮件等方式发送给所有相关人员，确保使相关人第一时间得知故障信息，以便快速组织应急响应。 预测：维护团队需要根据系统运行现状，通过数据分析、机器学习等方式，预测系统的风险情况，提前进行预防和处理。 在进行应急恢复处理时，通常需要尽快缓解或恢复业务，快速结束业务中断对客户的影响，然后再启动问题定位和修复处理流程，以减少业务中断时间。 组织协调：故障发生后，应急恢复主席需要迅速组织相关人员快速恢复业务。 应急恢复处理：系统发生故障后需要快速问题分析并按照事先制定的应急预案进行恢复处理。 父主题： RES12 应急恢复处理

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

OPS06-01 建立可观测性体系 可观测性（observability）最初是系统理论中的一个概念，指系统的状态能否被外部观察到和重现。随着云原生、微服务架构的发展，IT系统对可观测性的需求日益增强。业界对可观测性的定义：通常是指基于对复杂系统外部输出的了解，能够了解其内部状态或状况的程度。系统越可观测，定位问题根本原因的过程就越快速越准确，而无需进行额外的测试或编码。 风险等级 高 关键策略 可观测体系是围绕确定性恢复命题展开的，决定了确定性恢复能力构建与 SLO 达成。可观测体系能够直接决定一些故障的恢复时长，如下图所示，MTTR 平均恢复时长由平均发现时长、平均定界时长和平均处置时长三部分构成，而可观测能决定的是发现时长和定界时长（经验值占比 1/2 左右）。在一个事件里，MTTR 的恢复时长越短，那么它的整体 SLO 达成可能性就越高。 MTTR平均恢复时长=平均发现时长+平均定界时长+平均处置时长 设计建议 面向 MTTR的可观测体系设计的核心逻辑就是寻找最短恢复路径。如下图所示案例，在故障恢复 MTTR 的逻辑中，当业务发生故障，从故障发现、到故障定级和影响面分析、再到故障定界定位和故障恢复，几乎全部依赖人工处理。要想缩短时间，本质上是监控即发现、监控即定级、监控系统定界、定界即恢复——如果能达成这样的设计就能够形成 MTTR 的最短路径。 父主题： OPS06 可观测性体系

内部 知识管理 类应用典型部署架构（99.9%） 内部知识管理类应用通常用于内部操作，且在故障时只会对内部员工造成影响，可以承受较长的恢复时间和恢复点，其可用性目标通常要求达到99.9%，即每年中断时间可以为8.76小时。 导致业务中断的时间包含故障中断时间及由于升级配置维护等导致的中断时间，假定分别中断时间如下： 故障中断：假定每年故障中断4次，每次应急恢复决策时长为30分钟，恢复处理时长为30分钟，则每年故障中断时长为240分钟。 变更中断：假定应用离线更新，每年更新8次，每次更新时长30分钟，则每年更新时长为240分钟。 按照以上评估，每年应用系统不可用的时长是480分钟，满足可用设计目标要求。 内部知识管理类应用典型架构为前端无状态应用层+后端数据库，其中前端无状态应用采用E CS ，后端数据库基于不同业务类型可采用不同数据库，通常为RDS for MySQL；基于业务需要，通常还会使用DCS、Kafka等中间件及DDS文档数据库；为满足对应的可用性目标，建议方案如下： 类别 实施方案 冗余 ELB、RDS、DCS、Kafka、DDS等云服务实例均采用高可用部署。 备份 RDS、DDS数据库自动备份，有状态ECS通过CBR自动备份，在数据故障时使用最新备份数据恢复，可以满足可用性目标要求。 容灾 应用使用支持跨AZ的服务进行跨AZ部署，ELB、RDS跨AZ部署，AZ故障时自动恢复。有状态ECS通过SDRS进行跨AZ容灾，在AZ故障时手工切换。 监控告警 进行站点运行状态检查，在发生故障时告警；针对ECS、RDS实例负载状态进行监控，在资源过载时需要告警。 弹性扩缩容 针对内部用户场景，资源足够，无需自动弹性伸缩；针对ECS，通过ELB实现ECS实例的故障检测与负载均衡，并可根据ECS监控情况随时添加和移除ECS实例来扩展应用系统的服务能力；针对RDS，可根据RDS负载监控情况，在维护时段更改实例类型或增加只读节点。 变更防差错 软件更新采用离线更新，在位替换，根据runbook进行应用的自动部署与回滚。每1~2个月更新一次软件。 应急恢复处理 制定应急处理机制，指定应急恢复人员，以便在突发事件后能快速决策和恢复；并提供常见应用、数据库问题以及升级部署失败的相关解决方案，以便在出现问题后可以及时恢复。 根据以上方案，典型部署架构如下： 该架构的主要特点包括： 应用系统采用有状态虚拟机+有状态数据库的分层部署架构。 该应用系统在华为云单个Region部署一套完整系统，采用跨AZ部署，其中有状态虚拟机采用跨AZ主备复制，可以实现云内应用层跨数据中心主备容灾。 接入层（外部DNS）：通过外部DNS进行域名解析与流量负载均衡，单个AZ故障对业务没有影响。 应用层（负载均衡器、应用软件及虚拟机）：对于有状态应用，通过SDRS服务实现跨AZ的虚拟机数据复制与容灾切换，并可通过CBR服务进行自动数据备份。 中间件层：Redis、Kafka集群跨可用区高可用部署，单个AZ故障对业务没有影响。 数据层：RDS与DDS数据库及OBS对象存储跨可用区高可用部署，单个AZ故障对业务没有影响。 为了保证数据的可靠性，RDS数据库的数据定期自动备份到OBS，在数据丢失时可以快速恢复。 父主题： 参考架构

参考架构 为了构建安全、可信、合规的云上工作负载，华为云提供了大量的与安全相关的云服务。华为云客户基于Well-Architected架构的最佳实践会组合使用到这些云服务。我们的解决方案架构师在与客户进行沟通时，客户通常会提出以下疑问： 是否有一个全局性的视图可以表达构建安全工作负载的整体情况？ 在多账号环境以及单账号环境中应该使用哪些云服务？ 如何从全局到局部、自顶向下及从不同视角考虑工作负载的安全？ 基于以上诉求，我们构建了安全参考架构。安全参考架构旨在帮助客户有效地使用华为云服务构建出安全工作负载的指南。它提供了不同层次视角下的架构图、安全云服务分组的方法和云服务集成参考。需要说明的是，安全参考架构是一个参考范式，而不是绝对的标准。客户需要根据其具体情况和需求进行定制和实施。 组织级参考架构 工作负载级参考架构 父主题： 安全性支柱

RES09 故障重试 当应用系统部署在云中，虽然云具有一定的高可用和故障自动恢复能力，但对外仍会导致短时间的故障，需要应用系统能针对这种短时间故障进行适配处理，主要是采用重试机制。 云中故障需要重试的典型场景有： 实例主备切换时可能会导致连接中断，如DCS、RDS实例由于某些原因主备切换时，会导致连接中断，需要客户端重试。 实例由于故障重启可能会导致通信中断，如ECS所在物理服务器由于硬件原因故障时，ECS重启或在其他物理服务器中自动恢复，恢复过程中与ECS的通信会中断，需要重试。 实例由于过载导致无法及时响应，需要重试。 RES09-01 API及命令调用需要设计为可重试 RES09-02 客户端需要根据综合评估是否要重试 RES09-03 重试需要避免造成流量压力 父主题： 故障快速恢复

基于LTS采集多类端侧日志，问题全链路追踪分析和业务运营分析 某公司核心业务专注于IT信息传播、技术交流、教育培训和专业技术人才服务。拥有超过3200万注册会员、超过1000家企业客户及合作伙伴。 客户痛点： 端侧采集工具不统一，不支持自定义域名上报，问题定位复杂 Web、IOS、安卓、百度小程序、微信小程序等多类端侧日志无法使用同一家厂商工具采集，问题定位分析时，需在多个工具间需来回切换，增加了定位复杂度，且无法自定义日志上报的服务端域名，合规性受到部分用户质疑 端侧日志上报慢且易丢失：上报速度小时级，也极易出现丢失，对问题端到端定位分析、业务完整性分析均造成一定影响 业务挖掘分析难：日志数据无法直接写入 DLI ，需投递到Kafka后，再被DLI消费，链路长，且成本高 解决方案： 业务价值： 端侧日志全面采集接入，自定义域名上报：集成LTS提供的多端SDK，全面采集端侧日志，接入LTS，且支持上报服务端域名自定义，在用户面保持了业务一致性与合规性，降低了问题定位复杂度，提升了运维效率 端侧日志数据毫秒级上报，数据0丢失：端侧采集日志后，毫秒级完成上报，且无数据丢失，支撑客户快速完成从前端到后端对问题做全链路追踪分析，同时，也支持对业务做完整性分析 便捷低成本获取日志，助力业务挖掘分析：DLI-Flink简易集成Connector，定点从LTS实时消费日志，做实时业务计算分析；简易化配置LTS日志转储到OBS，供DLI快速从OBS读取日志，做离线业务计算分析 父主题： 参考案例

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

PERF03-10 选择合适的关系型数据库 风险等级 中 关键策略 华为云数据库提供了多款关系型数据库服务，包含GaussDB、GaussDB（for MySQL)、RDS（MySQL、PostgreSQL、SQL Server、MariaDB）；其中GaussDB、GaussDB（for MySQL）是华为推出的基于openGauss生态和MySQL生态的企业级关系型数据库，性能表现更好；RDS数据库服务可支持四种开源数据库引擎，RDS依托 云计算平台 ，为用户提供了更稳定、更弹性、运维更便捷的在线云服务。 适用场景： GaussDB：基于华为主导的openGauss生态推出的企业级分布式关系型数据库，具有云上高可用、高可靠，高安全、弹性伸缩、一键部署、快速备份恢复等能力，适用于高并发、大数据量、以联机事务处理为主的交易型应用，如政务、金融、电商、O2O、电信CRM/计费等。 GaussDB（for MySQL) ：华为自研的最新一代企业级高扩展高性能云原生关系型数据库，完全兼容MySQL，具有高性能、高扩展性、高可靠性、高兼容性、低成本、非中间件式架构等特点，适用金融行业、游戏行业等需要高安全或高性能的行业。 RDS：具有低成本、高性能、高安全性、高可靠性等特点。 RDS for MySQL：MySQL是当前应用最广泛的开源关系型数据库。RDS for MySQL适用于网站业务、应用程序、中小型企业等场景。 RDS for PostgreSQL：PostgreSQL是一个开源对象云数据库管理系统，并侧重于可扩展性和标准的符合性。RDS for PostgreSQL适用于网站业务、位置应用系统、复杂数据对象处理等场景。 RDS for SQL Server：Microsoft SQL Server是老牌商用级数据库，成熟的企业级架构，轻松应对各种复杂环境；RDS for SQL Server适用于政府、金融、医疗、教育、游戏等领域。 RDS for MariaDB：MariaDB是当前比较主流开源社区数据库之一，对MySQL有较好的兼容性；RDS for MariaDB适用于各种规模的应用程序。 关系型数据库的选择建议： 场景一：基于兼容性原则 考虑平滑上云，上云前系统中数据库的选型已经过业务实践的检验，建议选取生态相同的关系型数据库服务进行平替，避免出现数据库层与应用层不兼容或数据库切换对业务架构中其他组件产生负面影响。 场景二：基于场景评估 如果是在云上新建业务系统或基于同数据库不同服务中选取时，建议结合业务的实际需要选取合适的数据库服务；例如RDS for MySQL和GaussDB（for MySQL)，在选取时应考虑更多因素，如性能等因素，这些因素可以从官方资料查看。 父主题： 选择合适的数据库资源

SEC01-01 建立安全管理团队 指定负责工作负载在云环境的安全性、合规性、隐私保护方面的关键角色，确保从责任主体上保障工作负载的安全性。 风险等级 高 关键策略 明确职责和角色：确定团队成员的职责和角色，包括安全架构设计、安全测试、安全运营等方面的角色。每个角色应清晰定义其职责范围和任务。 跨职能团队：组建一个跨职能的安全管理团队，涵盖安全运营、安全架构、安全合规等不同领域的专业人员，以确保综合性的安全管理。 制定安全政策和流程：制定详细的安全政策和流程，明确安全管理的标准和规范。团队成员应遵守这些政策和流程，确保安全管理的一致性和有效性。 建立应急响应计划：开发和测试应急响应计划，以应对安全事件和紧急情况。团队应清楚知道如何应对安全威胁和处理安全事件。 父主题： SEC01 云安全治理策略

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

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

韧性支柱简介 韧性支柱旨在帮助企业构建具有高可用的应用系统架构，提高工作负载的韧性，使之在面对各种异常场景时仍能提供和维持可接受的服务水平。韧性支柱结合了华为公司韧性设计经验和业界最佳实践，总结并提炼出一系列设计原则与最佳实践，用以帮助企业利用华为云平台基础设施达到高可用、面向各种故障场景进行韧性设计，并具备一定的灾备能力；同时通过规范化变更、部署及应急恢复等处理流程，减少业务中断时长，提升可用性。 华为云韧性支柱的设计框架如下图所示： 父主题： 韧性支柱

PERF03-07 选择合适的Kafka 风险等级 中 关键策略 根据生产流量、消费流量、老化时间、副本数等指标，计算业务所需的规格，选择合适的Kafka规格。 规格测算： 性能容量维度所需最小节点数 = max（（存储带宽需求 / 单节点存储带宽），（网络带宽需求 / 单节点网络基准带宽）） 磁盘容量维度所需最小节点数 = max（总磁盘容量需求 / 单节点磁盘容量上限） 详细规格选择参考官方文档。 父主题： 选择合适的应用中间件云服务资源