一、背景
- 伴随公司和业务的快速发展，服务稳定性也越来越重要，特别是对于基础架构或者重要的业务团队，我们的任何服务出现问题，都可能影响到依赖我们的服务，所以我们应该以更高的稳定性要求作为我们的目标。
- 业务发展看似并不一定需要稳定性建设，因为有时稳定性建设的复杂性反而会拖慢业务迭代的速度，但是实际上业务长期稳健发展是离不开稳定性建设的，不稳定的业务其发展终究也会受限。
二、目标
提升 MTBF 缩短 MTTR，做到 MTTR 3-15-30 (3分钟发现，15分钟定位，30分钟止血）。
MTBF（Mean Time Between Failure） 是平均故障间隔的意思，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。
MTTR （ Mean Time To Repair ） 表示故障的平均恢复时间，也可以理解为平均故障时间。这个值越小，故障对于用户的影响越小。
可用性用公式可以表达为：
Availability = MTBF / (MTBF + MTTR)
| 系统可用性 | 年故障时间 | 日故障时间 |
|---|---|---|
| 99%（两个九） | 3.65天 | 14.4分钟 |
| 99.9%（三个九） | 8小时 | 1.44分钟 |
| 99.99%（四个九） | 52分钟 | 8.6秒 |
| 99.999%（五个九） | 5分钟 | 0.86秒 |
| 99.9999%（六个九） | 32秒 | 86毫秒 |
三、治理
核心理念：永远不要相信你的上下游，甚至不要相信你自己！！！！
3.1 变更规范治理
变更三原则：“可灰度，可监控，可回滚”。 如果某个原则无法做到，必须要充分评估可能引发的风险项和应急手段。
为了满足这三个原则，我们总结以下几个核心内容：
3.2 监控埋点治理
监控埋点的核心目标是为了“快速发现&定位问题”，所以我们需要尽可能把服务链路中可能影响服务稳定性的指标都要提前收集起来并建立预警机制。
3.3 服务流量治理
服务雪崩：由于下游服务故障，上游服务调用下游服务接口超时，错误，重试，导致众多上游服务也出现故障，由于服务与服务之间的依赖性，故障会传播，会对有依赖关系的上下游服务造成灾难性的后果。
流量治理的目的就是防止服务雪崩，包括出流量和入流量两个治理维度。
3.4 服务容错治理
容错主要是指对服务的上下游依赖错误的兼容，体现在代码上，就是我们要做好各种类型的
1 | try-catch |
。
3.5 服务依赖治理
在没有明确强弱依赖关系的前提下，系统很难进行限流降级、优化改造等操作。强弱依赖治理就是通过科学的手段持续稳定地得到应用间依赖关系、流量、强弱等数据，提前发现因为依赖问题可能导致的故障，避免依赖故障影响用户体验，积累数据持续推进系统稳定性提升。
根据服务依赖的强弱，我们可以分为：
- 强依赖：异常发生时，影响核心业务流程，影响系统可用性的依赖称作强依赖。（数据库）
- 释义：服务A依赖服务B，当服务B不可用时候，服务A也不可用，通常服务A会返回错误信息，我们称这种依赖为强依赖
- 弱依赖：异常发生时，不影响核心业务流程，不影响系统可用性的依赖称作弱依赖。（日志，短信）
- 释义：服务A依赖服务B，服务B不可用时候，服务A仍然可用，服务A会返回正确信息，与服务B相关的错误会默认处理或者降级处理，我们称这种依赖为弱依赖。
对于依赖的治理原则大致如下：
- 强依赖尽可能降级为弱依赖，不能降级的强依赖，需要做好应急、沟通预案，需要做到在强依赖设施恢复之后的短时间内完成业务的恢复。
- 弱依赖需要提供降级方案，有快速手段进行自动、手动的解除依赖或者降级依赖的手段。
场景分析：
电商系统：
- 订单服务依赖于库存服务，订单的生成是一定会校验库存的，当库存服务不可用时候，订单服务也不可用，只能返回对应的错误信息，所以库存服务对于订单服务就是强依赖。
- 订单服务依赖于短信服务，短信服务不可用时候，用户仅仅是收不到信息通知，但是不影响订单的生成，所以短信服务对于订单服务就是弱依赖。
四、故障应急流程
核心原则：“及时响应，快速定位止损，事后修复”。
作者：字节架构前端
链接：https://juejin.cn/post/7402793540306665484
