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



参考资料

李智慧-架构师训练营