检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
RES05-01 网络连接高可用 应用系统对外提供服务时,需要确保对外网络连接的高可用,避免单个网络连接中断而导致业务不可用。 风险等级 高 关键策略 网络链路冗余:网络连接需要支持多路径,以实现高可用能力,以避免在一条网络路径中断的情况下,业务能切换到其他路径继续通信。 网络链
关键策略 请求超时,可能是链路闪断或其他临时性故障导致消息丢失,可以进行重试。 根据错误响应码进行有针对性的重试;对于临时性故障,如错误码指示为系统繁忙时,可等待一段时间后重试,否则无需重试。 请求SDK中内置了消息重试时,客户端无需重复重试。 多层业务栈一般只在源端重试,避免逐层重试。
原地升级和回滚时,升级和回滚过程中业务将会中断,中断时长受限于升级和回滚的时长,对业务影响比较大;而采用灰度部署和升级,可减少升级和回滚过程中的业务中断,提升系统可用性。 风险等级 高 关键策略 通过金丝雀部署、蓝绿部署等方式实现灰度升级或部署,逐步引入新版本部署范围或切换用户流量,配合自动回退以降低部署差错导致业务中断的风险。
参考案例 通过AOM助力系统运维能力提升,降低运维成本与难度 基于LTS采集多类端侧日志,问题全链路追踪分析和业务运营分析 LTS助力某公司高效完成日常业务运维与等保合规 父主题: 卓越运营支柱
数据持久度 数据持久度是指数据不丢失的概率,即存储在预计周期内不出现数据丢失的概率,可以用于度量一个存储系统的可靠性。其只表示数据是否丢失的概率,不体现数据丢失多少;数据持久度的预计周期,一般按一年进行预计。 影响存储数据持久度的主要因子有:冗余数、磁盘失效率与数据修复时间。其中
故障全面检测 高可用性系统必须具有完善的故障检测能力,以确保能够快速发现那些可能导致故障的事件、显示正在发展的故障、激活的故障,以及潜在的故障的事件。在几乎所有情况下,故障检测能力都是故障恢复的前提。 RES06 故障检测 RES07 监控告警 父主题: 韧性支柱
RES12 应急恢复处理 应用系统无论如何精心设计,仍可能会出现无法恢复的故障,当此类故障发生后,需要进行应急恢复处理。 RES12-01 组建应急恢复团队 RES12-02 制定应急预案 RES12-03 定期应急恢复演练 RES12-04 出现问题后尽快恢复业务 RES12-05
RES14 配置防差错 配置防差错是针对配置过程中因人输入了错误的配置数据导致系统和业务受损或失效场景下通过产品设计降低或避免配置错误产生的影响。 RES14-01 变更防呆检查 RES14-02 自动化变更 RES14-03 变更前数据备份 RES14-04 提供runbook进行标准化变更
裸金属服务(Bare Metal Server,BMS)是一款兼具弹性云服务器和物理机性能的计算类服务,为企业提供专属的云上物理服务器,为核心数据库、关键应用系统、高性能计算、大数据等业务提供卓越的计算性能以及数据安全。 可靠性功能 常见故障模式 父主题: 云服务可靠性介绍
ECS弹性云服务器 弹性云服务器(Elastic Cloud Server,ECS)是由CPU、内存、操作系统、云硬盘组成的基础的计算组件。弹性云服务器创建成功后,就可以像使用自己的本地PC或物理服务器一样,在云上使用弹性云服务器。 可靠性功能 常见故障模式 父主题: 云服务可靠性介绍
数据数量、数据属性(如疾病史比电话号码更敏感)、存储区域是否有其他数据可关联、个人数据收集/存储/处理/披露的目的(如统计分析、研究、税收管理、法律要求)、所属角色(控制者/处理者/设备供应者)等。 严格保护敏感个人数据。通常情况下,敏感个人数据包括:生活信息如种族或血统、政治观
PERF05 性能优化 性能优化工作中,需警惕“过早优化”的问题。我们的基本指导策略还是首先让系统运行起来,再考虑怎么让它变得更快。一般只有在我们证实某部分代码的确存在一个性能瓶颈的时候,才应进行优化。除非用专门的工具分析瓶颈,否则很有可能是在浪费自己的时间。另外,性能优化的隐含
RabbitMq版:完全兼容开源RabbitMQ,提供即开即用、消息特性丰富、灵活路由、高可用、监控和告警等特性,广泛应用于秒杀、流控、系统解耦等场景。 RocketMQ版:低延迟、弹性高可靠、高吞吐、动态扩展、便捷多样的消息中间件服务。 可靠性功能 常见故障模式 父主题: 云服务可靠性介绍
恢复能力 备份 应用数据被破坏的情况下的恢复能力 容灾 在Region/AZ/IDC或其他云站点发生灾难的情况下的恢复能力 监控告警 应用系统故障后的检测和告警能力 弹性扩缩容 应用容量不足时的自动恢复能力 变更防差错 变更对应用业务中断的影响 应急恢复处理 应用在故障情况下的应急恢复能力
RES02 备份 对于应用系统中的重要数据,需要提供备份功能,以便在病毒入侵、人为误删除、软硬件故障等场景,能够快速将数据恢复到备份点。 由于容灾通常对数据采用实时复制且没有多备份点,在主数据被误删或误改的情况下,错误数据会同步到备端,从而无法达到数据备份的效果,因此通常不能使用容灾来代替备份。
分钟,则每年故障中断时长为45分钟。 变更中断:假定应用支持金丝雀部署或蓝绿部署,并自动完成,软件更新不中断业务。 按照以上评估,每年应用系统不可用的时长是45分钟,满足可用设计目标要求。 电子商务类应用典型架构为前端无状态应用层+后端数据库,其中前端无状态应用可采用ECS或CC
ELB采用集群化部署,支持多可用区的同城多活容灾,无缝实时切换。 ELB支持后端服务器多AZ部署,当某个AZ出现故障时,ELB仍可将流量转发到其他AZ的后端ECS处理,提高应用系统容灾能力。 监控告警 配合CES服务,支持对ELB的连接数、带宽、错误响应等进行监控和告警。详见“监控指标说明”。 父主题: ELB弹性负载均衡
向扩散等,在实际攻击当中,利用率最高的是弱口令(简单口令、重复口令)爆破、流行漏洞利用和钓鱼。 攻防演习是有规则的,约定开展时间、确定靶标系统、设定战果分数、限制影响面大小等,但实际攻击没有规则,所以常态化的安全建设要求必须高于攻防演习特定要求,才能真正提升整体能力。 攻击战法分析:
多线程不要共享通道,因为你很难实现线程安全。 不要频繁的开启或关闭连接和通道,否则会造成更高的延迟。 生产者和消费者使用独立的连接,来提高吞吐量。 大量的连接和通道可能会影响管理接口的性能,造成请求超时。 消息确认 消费者使用确认(Acknowledgment)机制避免消息因为连接问题而丢失,客户端可以在收到消息或者处理完消息后回给服务端一个
没有消息,会导致分区间的数据不均衡。 生产者发送消息时指定了消息Key,按照对应的Key发送消息至对应的分区,会导致分区间的数据不均衡。 系统重新实现了分区分配策略,但策略逻辑有问题,会导致分区间的数据不均衡。 Kafka扩容了Broker节点,新增的节点没有分配分区,会导致节点间的数据不均衡。