写点什么

系统故障原因及方案

用户头像
superman
关注
发布于: 2020 年 08 月 26 日

1: 原因与故障级别

1.1故障原因



  • 软件本身错误导致系统不可用

软件bug导致功能不能按预期实现

软件本身问题导致系统运行失败或运行一段时间故障失败等

  • 压力导致超出系统负担

  • 系统发布时的程序本正确运行或配置导致不可用

  • 服务器硬件故障

  • 网络故障

  • 外部攻击导致系统不可用

  • 机房故障-灾害



1.2 故障级别

根据故障造成的伤害范围与程度对故障进行分级

功能范围

系统整体不可用

系统核心功能不可用

部分核心功能不可用

部分非核心功能不可用

时间范围

长时间不可用

较长时间不可用

短时间不可用



用户范围

全部用户不可用

大量用户不可用

部分用户不可用

少量用户不可用



范围越大故障级别越高

核心功能对大部分用户长时间不可用是最高

2:解决方案

2.1 解决思路

导致系统故障的原因有多种,需要从相应的多个方便去防范故障,同时有些故障是不能避免的,需要在故障发生时可以尽量降低故障的伤害-将范围与程度降到最低。

可用性的方案与成本挂钩,不同业务(用户)对可用性的要求差异,可用性的的级别要与业务本身的需求及可承受的成本间找到平衡。

有些系统整体歇一天用户都接受,有些系统核心功能半小时不可用都影响巨大,不能接受。



可用性价值观

1:尽量简单的方案

简单可以方便发现与解决问题,简单也会减少问题

2:问题导向

设计的可用性方案是针对本系统真实存在的问题,针对性的解决方案。

权衡的核心是本系统的真实环境,会遇到的真实问题。

面对的环境-软硬件,用户等

可靠性要求

各个指标的重要等级

3:成本收益平衡

平衡本系统的成本,决定在哪些方便达到哪种级别的可用

针对可用性的最终决策者要求:软件运营或使用者,管理者多系统可靠性的要求。



故障应对的思路

  • 设计上就减少或避免故障发生

  • 故障发生时可方便的尽快定位到故障原因

  • 故障影响范围尽量小:

响应的功能少,影响用户少,时间短()

  • 故障伤害级别限制到低程度--比如故障后关键数据不丢失只短暂不可用,就比丢失数据好

  • 尽量提前发现故障:越早发现故障损失越小

  • 故障能尽快恢复-发送故障后可自动切换或短暂时间内自动|手动切换

  • 故障修复



2.2具体方案



根据各故障原因从多种故障应对的思路上进行防范。



2.2.1 软件本身原因

解耦-减少故障,方便定位与修复

软件功能设计上高内聚低耦合,减少故障发生并方便问题定位与修复

组件设计原则,面向对象与设计模式,领域驱动设计

从多个粒度解耦。

解耦对可用性的好处:

1>可以让核心部分稳定的部分不受不稳定非核心的干扰

2>更方便分工,核心功能可以让更靠的主的人去维护。

3>出现问题方便定位与修复



隔离--降低故障影响范围

业务拆分为多个子系统-功能隔离

微服务与中台--功能横向拆分,纵向拆分-个性与共性隔离

依赖关系隔离-生产消费者隔离--用消息队列模式

虚拟机与容器隔离--运行环境的隔离



异步编程模型--隔离问题,保整体可用,重要的可用

反应式编程,事件驱动架构,多线程等

好处:生产消费故障隔离,部分失败不影响整体。



故障补偿-故障修复

故障后重试

服务幂等设计

失败后业务逆超时(事务补偿)



熔断-限制故障蔓延



2.2.2 压力问题

限流-降低伤害范围与级别

丢弃超过能力范围的请求

降级-降低伤害级别

压力过大关闭非核心功能

动态伸缩--压力应对与故障预防

压力指标预警后动态扩容

压力测试-提前发现问题

获取系统压力指标,方便预警与伸缩。



2.2.3 物理故障

应对物理故障主要通过冗余的办法。在故障发生后有替代者,保证系统可用。

同时通过物理上的冗余也方便系统升级,在升级时可逐步停止升级启动,升级过程中系统仍可用。



冗余的模式:集群,备份

冗余位置

网络冗余-多厂商接入

存储冗余-主备主从分片

计算集群

多机房-异地多活

故障转移:

1:确认故障

有状态的-管理节点主动检测,消费者访问失败上报,服务主动定期上报健康

2:转移故障

有状态:

选主|任务接替者:民主投票,管理裁决

数据拷贝

无状态:负载均衡



2.2.4 监控与预警

通过监控与预警,可提前发现潜在问题并处理,出现问题后可方便定位问题。

监控内容

各维度压力,服务器性能,用户行为,业务指标。

预警

超过阀值:预警,限流,转移,扩容

故障报警



2.2.5 运维升级

运维的自动化手段与升级策略减少版本升级导致故障

自动化

自动化测试

规模达到临界点后每次变动人工进行之前功能的回归成不过大,引入自动化测试。

持续集成

提交代码,执行自动单元与集成测试

持续交付

部署到测试环境,验证

持续部署

部署到生产环境。



升级环境与策略

自动化发布

每次小的迭代发布,不积累过多的变更,出现问题也好修复。

预发布环境

两种方式的预发布环境

1:发布服务到正式环境,但用户请求不接入(不在负载均衡下),内部测试验证通过后,再发布到正式服务器。

2:独立的环境,跟现实服务版本,配置一致,但是物理隔离,类似镜像环境。升级时先升级,验证后在升级到正式环境。

镜像模式预发布环境跟线上环境一样,也作为运维升级的演练,研发不要操作。这样升级正式环境时运维的操作不会遗漏。

灰度升级

线上升级时防止全部升级时如果出现故障,影响过大,并且回滚时间过长

先一部分升级,没问题后在逐步推广到全部。

2.2.4 安全攻击

从运维与系统设计多角度的安全防护。

内容较多参考

https://xie.infoq.cn/article/7cf05bcef7da111d2f134fe96



参考资料

李智慧-架构师训练营



发布于: 2020 年 08 月 26 日阅读数: 75
用户头像

superman

关注

还未添加个人签名 2018.07.20 加入

还未添加个人简介

评论

发布
暂无评论
系统故障原因及方案