检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
降,故而也应该综合考虑业务的趋势。 比如一个快速增长的业务组织更多地可能会偏向于提升业务的速度,而设计一个比较宽松的云成本优化策略,而稳定的业务组织则可以以成本效率为主要考量,设计比较严格的云成本优化策略。如果应用服务于特定的地理位置或市场领域,并且您已预测出该领域会出现的对云业
成本优化支柱 成本优化支柱简介 基础概念 设计原则 问题和检查项 COST01 规划成本优化相应的组织机构和流程 COST02 实施预算规划管理机制 COST03 对成本进行分配 COST04 持续进行成本治理 COST05 优化指定策略和目标 COST06 使用不同计费模式优化成本
响应时间、服务级别目标(SLO) 或服务等级协议(SLA),同时应该记录团队间沟通信息,确保有足够的数据用于后续的改进。 例如一种运维组织设计是:将运维组织分为一线、二线和三线阶梯型运维支持团队,一线受理客户的服务请求,第一时间将大部分的服务请求闭环。二线处理一线升级的服务请求和
OPS02-01 进行需求管理和迭代开发 风险等级 高 关键策略 您的云上应用要达到卓越运营,从设计和开发阶段就需要保证可用性,可恢复性,同时也需要保证代码的质量。您需要评估和了解软件DFX相关要求,包括可靠性、性能、可服务性、可运维性、可交付性等要求 将监管、行业和内部合规性要
RES12 应急恢复处理 应用系统无论如何精心设计,仍可能会出现无法恢复的故障,当此类故障发生后,需要进行应急恢复处理。 RES12-01 组建应急恢复团队 RES12-02 制定应急预案 RES12-03 定期应急恢复演练 RES12-04 出现问题后尽快恢复业务 RES12-05
RES14 配置防差错 配置防差错是针对配置过程中因人输入了错误的配置数据导致系统和业务受损或失效场景下通过产品设计降低或避免配置错误产生的影响。 RES14-01 变更防呆检查 RES14-02 自动化变更 RES14-03 变更前数据备份 RES14-04 提供runbook进行标准化变更
卓越运营支柱 卓越运营支柱简介 基础概念 设计原则 问题和检查项 OPS01 建立持续改进的团队文化和标准化的运维体系 OPS02 通过CI/CD实现高效的频繁可逆的小规模变更 OPS03 完备的测试验证体系 OPS04 自动化构建和部署流程 OPS05 运维准备和变更管理 OPS06
故障快速恢复 当应用系统采用华为云服务的高可用设计时,在云服务实例发生故障后,云服务能自动检测和恢复;但对于应用系统本身的故障,需要应用系统自身进行检测和快速恢复处理,以保证系统能够正常运行,从而提高系统的可靠性和稳定性。 RES08 依赖减少与降级 RES09 故障重试 RES10
全生命周期性能管理 全生命周期性能管理围绕需求、设计、开发、测试与编护完整的软件生周期展开,将性能活动内化到生命周期流程中,实现性能工作的常态化。 PERF01-01 全生命周期性能管理 父主题: PERF01 流程与规范
以及合法、合规使用数据,保护用户隐私的一系列最佳实践。 安全性是现代应用程序的重要维度,需要成体系地考虑工作负载的安全。华为云安全性支柱的设计框架如下图所示: 父主题: 概述
负载能够适应不同的需求,同时保持最佳性能。 尽早设计性能目标 性能目标是定义性能的指标,清晰明确的性能目标是关键,通过性能目标,团队可以针对特定目标持续改进。为了确保系统能够满足预期的可靠性和性能要求,避免系统性能瓶颈,性能目标设计需要在部署业务之前开展,重点的是明确系统的需求和预期目标,以生成性能目标范围。
故障复盘及持续改进(含故障演练),基于故障模式库,面向全流程、构建恢复能力、保证平均恢复时长(MTTR)的长效收敛,实现故障的快速恢复。 设计建议 父主题: OPS07 进行故障分析和管理
并确保服务可用性满足SLA服务等级协议。 客户责任:客户可以从华为云选择合适的产品并进行可靠性配置以符合应用韧性目标,并参考本白皮书中的设计原则与最佳实践,充分考虑各种异常场景的检测和恢复能力,来构建高可用应用系统。 父主题: 基本概念
RES08 依赖减少与降级 对于应用系统,需要识别和管理系统依赖项。应用系统设计人员需要维护对其他系统组件的依赖项的完整列表,包括系统内和系统外的所有依赖。 应用系统应尽可能减少关键依赖项,即减少由于该依赖项不可用而导致服务中断的组件。 RES08-01 减少强依赖项 RES08-02
门的工具分析瓶颈,否则很有可能是在浪费自己的时间。另外,性能优化的隐含代价会使我们的代码变得难于理解和维护,这一点也是需要权衡和关注的。 设计优化 算法优化 资源优化 父主题: 性能效率支柱
业务而言,意义就不大了。 遵循可操作性原则能避免很多误报。并且要定期统计和分析告警频率,识别高频告警,解决告警问题,清除明确的告警误报。 设计建议 优化告警阈值:适当提高 内存/CPU/网络 IO 告警阈值。 优化日志级别:优化不合理的日志级别,把部分 ERROR 级别的日志调整为
关键策略 当系统出现问题时,需要能够追踪系统中每个组件的行为和交互情况。通过在系统中实现分布式跟踪,可以快速定位问题并进行有效的故障排除。 设计建议 链路跟踪可以通过在系统中添加跟踪标识符来实现。当请求进入系统时,标识符将被添加到请求中,并在整个系统中传递。每个组件都可以将标识符添
弥补了Full-Mapping的不足。 Mapping代替:强制将特定key分配给特定Grid,方便测试、隔离。 进行Grid路由层设计。设计原则如下: 路由层是系统唯一的一个共享组件,因此需要尽可能的稳定,减少修改。 避免业务逻辑,保证尽可能的稳定,减少修改。 由于爆炸半径大
取决于需要FunctionGraph函数执行何种逻辑。 策略: 正确的使用连接池,保持连接存活并重用在上一次调用中建立的连接(HTTP,数据库、redis等)。 通过接口调用FunctionGraph函数时,建议客户端维护http连接池,减少http连接初始化时间。 避免在每次调
更并未影响实际业务,检查完成后,发布变更结果。 变更关闭:在变更完成后,关闭变更任务。对变更记录进行留存,便于后续变更数据的运营与分析。 设计建议 父主题: OPS05 运维准备和变更管理