TS - 可用性与可靠性

可用性与可靠性

可用性

• 关于系统可以被使用的时间的描述，以丢失的时间为驱动
• 可用性百分比 = 可用时间 / ( 可用时间 + 不可用时间 )

可靠性

• 关于系统无失效时间间隔的描述，以发生的失效个数为驱动
• 可靠性百分比 = 平均无故障工作时间 / ( 平均无故障工作时间 + 平均故障修复时间 )
• 平均无故障工作时间（MTBF，Mean TimeBetween Failure）指上一次故障恢复后开始正常运行到这次故障的时间平均值
• 平均故障修复时间（MTTR 的全称是 Mean Time To Repair）是指从出现故障到完全恢复的这段时间

可用性等级

获得更高的可用性，意味着投入更高的成本。
不同的技术是保证可用性的一种方法之一，不是全部，难以从根本上保证极高的可用性。

# 基本可用
- 2个9，99%
- 年度停机时间：87.6 小时
- 可能涉及的技术：简单的负载均衡

# 较高可用
- 3个9，99.9%
- 年度停机时间：8.8 小时
- 可能涉及的技术：灰度发布、自动化发布、自动化测试、快速回滚

# 高级可用
- 4个9，99.99%
- 年度停机时间：53 分钟
- 可能涉及的技术：微服务、相关中间件自动扩展（数据库自动扩展、缓存自动扩展)、容错、监控、弹性伸缩

# 极高可用
- 5个9，99.999%
- 年度停机时间：5 分钟
- 可能涉及的技术：异地多活、智能运维

导致可用性下降的常见原因

# 变更与发布
当应用需要升级或维护的时候，为了降低复杂度和变更成本，通常会暂时中断服务。

# 故障
发生故障的时候，系统可用性会受到影响，例如出现内存溢出，可能导致整个服务不可用。

# 压力
突发的事件导致预期之外的压力会造成系统宕机，而预留太多冗余资源又比较浪费。

# 外部强依赖
如果外部依赖的服务发生故障，则会导致调用异常，进而导致系统的不可用。外部依赖的服务越多，做到高可用的挑战就会越大。

实现高可用的重要方法

# “20/10/5”倍数原则（根据实际情况来确定）
- 设计系统的时候，以实际流量的20倍来设计;
- 开发系统的时候，以实际流量的10倍来开发系统;
- 发布系统的时候，以实际流量的5倍来部署。
- 实现基础资源的弹性伸缩是应对超预期流量的可用方式之一


# Design for failure
- 预测可能发生的问题，做好预案。
- 例如当流量高峰的时候如何限流、伸缩、隔离故障节点。
- 并不是所有的故障都会导致不可用，重点关注关键业务流程。


# 运维的完善性
可以很大程度上减少故障的发生和降低故障的影响
- 做好日常的巡检和备份（配置和数据）
- 建立全层次的监控平台，及时预警和告警
- 完善和演练应急灾备方案