大话“高可用“-Part3∶高可用的考量标准（原创，转载请标明出处）

任何事情，都应该有个考量标准，那么高可用的考量标准又是什么？

行业现状∶

99.9%  （宕机时间<525.6分钟）

99.99%  （宕机时间<52.56分钟）

99.995%（宕机时间<26.28分钟）

99.999%（宕机时间<5.256分钟）

相信这些词都是大家耳熟能详的指标，全年内服务可用时间>xx.xx%。

不过同样很显然，这是一个以结果论的考量方式。

那么我们这样思考下，如果我们的kpi只考量大家每年完成的功能数、代码行数结果会怎样？

其实大家都知道，实现一个功能很简单，但是后面的实现方式、系统质量、可扩展性等等天差地别。既然功能上，我们有架构师、技术经理保障质量，有单元测试覆盖率、坏味道扫描、慢sql监控等等指标来衡量。

那么高可用，真的就是简简单单的几个9就能考量了吗？

我简单举几个例子：

1、去年疫情，电影院关闭，院线系统全年无故障，可用性100%。某电商平台日订单10亿笔，全年共计出现10分钟宕机，可用性99.995%。从结果论分析，院线系统的可用性保证能力远高于电商系统。
---结果论同样需要维度和参考系。而参考系是价值衡量的重要指标。

2、2019年，某平台亿级用户，日千万订单，全年宕机10分钟，可用性指标达到99.995%。领导层决定2020年不做用户、订单增长，不做云端新需求发布，该团队认为2020年云端可用性依旧可达99.995%。结果2020年在用户量不变、订单不变、日活不变的情况下，某天突然并发量突增，云端被打垮近20分钟。排查后发现是因端侧接口拆解，并发数上升导致。随后因为第三方依赖服务故障，导致云端瘫痪15分钟。全年可用性99.99%。
---外部影响的评估同样是高可用衡量的重要指标。

其实这样的案例还有很多，比如周期性bug、特定场景触发性故障（比如天气，这其实很有意思，特定行业，天气不光会带来用户量变化，还会因为基站信号不稳定，带来流量变化）、外部ip演变等等。

那么显而易见的是，如果只从结果去判别一套系统的高可用级别，显然是一个非常错误的衡量标准。结果论是用来衡量价值指标的工具，而不是质量指标的工具。我们不论是高可用还是需求，都是为了完成价值指标，但是我们相比需求体系，我们缺的是对高可用质量的度量体系。
 

那么我们是不是可以有一套类似于CMMI这样的体系，去考量我们的高可用体系呢甚至将这套高可用度量标准推广成全行业的通用标准呢？

这块我会在part5∶重新定义高可用中，去做一些阐述。

说到这里，我想提一个词“幸存者偏差”，高可用本身也包含质量体系的范畴，使用的却是单一的价值体系标尺来进行的度量，这种情况下，出现“幸存者偏差”其实再正常不过。我们同时应该从质量维度去定义高可用的标准和检查手段，在这样的标准体系下进行高可用的构建和实施，最终达成几个9的价值指标。
 

总结下，99.XX%是我们高可用需要实现的业务价值，是我们存在的意义，是我们需要去完成的kpi。而不是度量高可用能力成熟度的标尺。
 

会不会有一天，行业内的沟通变成了…

该公司的paas系统，高可用能力成熟度为Ⅲ级，综合评分为87.6分，

达成xx体量下99.995%指标的可信度为97%。

然后就是一张雷达图，展现这套系统在高可用6个维度下的长短板及优化建议。

未完待续...