检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
根据以上方案,典型部署架构如下: 该架构的主要特点包括: 应用系统采用无状态应用+有状态数据库的分层部署架构。 该应用系统在华为云一个Region两个AZ中各部署一套,提供同城容灾能力。 接入层(外部GSLB):通过外部GSLB进行域名解析与流量负载均衡,在单个AZ故障时自动将业务流量切换到另一AZ。
RES05-03 不同流量模型业务的网络共享带宽隔离 不同流量模型业务共享网络带宽享时,可能会导致流量抢占,相互影响,一个业务流量突然可能会导致其他业务不可用。 风险等级 高 关键策略 相同流量模型的业务,可共享网络带宽,带宽需要满足所有共享业务的需求 不同流量模型的业务,为了避免相互干扰,建议使用各自独立的共享带宽实例
关联源代码版本和部署的应用版本,使用代码质量最佳实践 风险等级 高 关键策略 在代码开发阶段,需要开展代码协作设计和管理。使用现代化的代码仓管理代码,确保代码合并后,代码将保持一致,并且不会丢失任何更改。通过正确的版本控制,同时,现代化的代码仓可以方便设置代码版本,关联源代码版本和部署的应用版
fka后,再被DLI消费,链路长,且成本高 解决方案: 业务价值: 端侧日志全面采集接入,自定义域名上报:集成LTS提供的多端SDK,全面采集端侧日志,接入LTS,且支持上报服务端域名自定义,在用户面保持了业务一致性与合规性,降低了问题定位复杂度,提升了运维效率 端侧日志数据毫秒
进行应用的自动部署与回滚。每1~2个月更新一次软件。 应急恢复处理 制定应急处理机制,指定应急恢复人员,以便在突发事件后能快速决策和恢复;并提供常见应用、数据库问题以及升级部署失败的相关解决方案,以便在出现问题后可以及时恢复。 根据以上方案,典型部署架构如下: 该架构的主要特点包括:
梳理资产清单 梳理工作负载涉及的服务器、IP地址、域名、数据库、证书等全量云资源的资产清单,给资源打上标签,从而在出现安全事件时,能快速定位到有安全风险的资源。 风险等级 高 关键策略 设计态与运行态一致性:对照设计态的架构图、架构文档实施云服务资源。工作负载运行时的架构始终保持与设计态一致。
RDS、DDS等实例负载状态及资源故障切换等的监控,在负载超过阈值或状态异常时告警。 弹性扩缩容 支持自动弹性伸缩;针对ECS,通过ELB实现ECS实例的故障检测与负载均衡,并可通过AS监控负载随时添加和移除ECS实例来扩展应用系统的服务能力;针对RDS for MySQL,可根
跨云容灾方案 当重要应用系统已经在IDC或其他云上部署,并需要容灾到华为云,以提供高可用的容灾方案。假定应用系统在IDC或其他云上可以达到99.9%的可用性,则在容灾到华为云后,能提供99.99%的可用性。 跨云应用典型架构为前端无状态应用层+后端数据库,其中前端无状态应用可采用虚拟
内部知识管理类应用通常用于内部操作,且在故障时只会对内部员工造成影响,可以承受较长的恢复时间和恢复点,其可用性目标通常要求达到99.9%,即每年中断时间可以为8.76小时。 导致业务中断的时间包含故障中断时间及由于升级配置维护等导致的中断时间,假定分别中断时间如下: 故障中断:假定每年故障中断4次
当重要应用系统已经在IDC或其他云上部署,并需在华为云上部署一套系统实现双活,以提供高可用的容灾方案。假定应用系统在IDC或其他云上可以达到99.9%的可用性,则在容灾到华为云后,能提供99.99%的可用性。 跨云应用典型架构为前端无状态应用层+后端数据库,其中前端无状态应用可采用虚拟
路径。 公有云组网场景可通过多EIP 弹性IP及DNS域名解析实现网络连接的高可用;对可用性要求较高的场景,需要支持智能DNS功能,能对EIP进行异常监控和自动切换;此外DNS自身也需要冗余容错,避免由于DNS故障而导致域名解析失败,业务中断。 混合云组网场景链路冗余与倒换方案:
部署容灾系统以满足容灾目标 针对不同应用系统的容灾目标,需要综合考虑中断概率、容灾成本等因素,来决定采用什么样的容灾方案来实现这些目标。 风险等级 高 关键策略 面向跨Region/跨云容灾场景,可基于不同的可用性目标要求,采用不用的容灾方案,如远程备份、主备容灾、双活容灾等,其
业务中断,因此网络架构的高可用及容灾能力至关重要。在进行网络设计时,需要充分考虑应用系统对内和对外的网络连接、IP地址管理和域名解析等。 华为云中网络高可用主要涉及三个场景: 公有云网络:构建应用系统相关的公网网络连接的高可用,可减少由于网络连接中断而导致的业务中断。 混合云网络
金融类核心应用通常比较重要,要求非常短的恢复时间和数据丢失量,其可用性目标通常要求达到99.999%,即每年故障时间可以为5.26分钟。 假定故障中断与变更中断的时长分别如下: 故障中断:由于要求的故障中断时间很短,要求尽可能自动恢复,没有手动触发的恢复,假定每年故障中断4次,每次自
建议 由于大括号“{}”为Redis的hash tag语义,如果使用的是集群实例,Key名称需要正确地使用大括号避免分片不均的情况。 Value相关规范 设计合理的Value大小。 设计合理的Key中Value的大小,推荐小于10 KB。 建议 过大的Value会引发分片不均、热点K
COST03-03 公共成本分配 风险等级 中 关键策略 跨团队共享使用的CDN、直播带宽应按照各业务团队的实际带宽占比,将带宽费用拆分到不同的业务团队。 跨团队共享使用的CCE集群服务,应按照各团队分配和使用的CPU/内存等比例,将容器集群成本(包含CCE、ECS、EVS等服务成本)拆分到各个业务团队。
OPS02 通过CI/CD实现高效的频繁可逆的小规模变更 OPS02-01 进行需求管理和迭代开发 OPS02-02 关联源代码版本和部署的应用版本,使用代码质量最佳实践 父主题: 卓越运营支柱
OPS01-01 建立持续学习和改进的文化 风险等级 高 关键策略 由于系统的独特性和复杂性,没有放之四海皆准的方案,为了达到卓越运营,需要不断改进这些最佳实践,并建立自己的最佳实践。所以,在所有最佳实践的第一条,就是在您的团队中培养持续学习和改进的文化。 而持续学习和改进需要鼓励团
OPS01-03 规划标准化的运维流程和运维工具 风险等级 高 关键策略 流程和工具是经验的承载,通过标准化的流程,可以大幅降低在运维过程中因为个人的因素受到的影响和无序化。 通过标准化的、统一的运维工具,向运维人员提供集中、统一维护界面及清晰易上手的操作手册,方便运维人员的集中维护,提高运维效率。常见的运维流程有:
无论如何设立组织,应该确保具有一个整体的流程,在流程中的每个团队和成员都有自己明确的责任。 同时可以使用明确的方式(如收集运营/运维数据)分析团队工作对业务成果的影响,从而可以在实际工作中确定不同任务的优先级,并适时改进。 父主题: OPS01 建立持续改进的团队文化和标准化的运维体系