没有稳定性，一切归零

7月13日B站主站、App、小程序均出现访问故障，页面提示“正在玩命加载数据”。

B站崩了，才让大家发现原来“小破站”的流量如此惊人。上不了网站、没得看视频直播的“B站难民”冲向知乎、微博以及著名游戏网站NGA。“b站崩了”“陈睿”“豆瓣崩了”等词迅速走红，甚至连B站名梗“蒙古上单”也一同霸榜微博热搜，传遍全网，颇为壮观。

23时左右故障发生，直到23时45分，B站网页端和App才初步恢复正常访问，但像直播、会员购等板块，以及一些站内互动、评论、投币功能，还无法正常使用。

B站的这次事情，在全网火了，同时也让互联网人意识到稳定性的重要性。毫不夸张的说，没有稳定性，所有一些都会归零。

稳定性定义

所谓『服务稳定性』就是用户在使用我们的服务时，服务是可响应的、正确的、高效的。

可响应：app能打开、里面的各项功能点击后有响应；
正确：各种功能输出的结果是正确的，符合预期的，比如支付的金额正确，页面里该有的内容和数据都有，等等；
高效：前面两个都符合要求也还存在一个响应效率的问题，如果服务响应突然变慢，导致用户放弃使用，也是稳定性出了问题；

业务发展的不同阶段，使用不同的稳定保障的策略。

业务发展初期，所有人一心扑在业务几乎不考虑稳定性的事情。

随着业务的不断发展，业务规模不断扩大，各类稳定性事情频发。这个阶段，一般由业务的同学负责稳定性相关的事情。

业务发展到了相对稳定阶段之后，由于业务规模很大，稳定时间的影响也越来越大。甚至带来广泛的舆情影响，影响公司的品牌形象。这个阶段，有会专门的团队负责稳定性建设。

稳定性评价

稳定性评价对于稳定性建设很重要。稳定性评价不仅可以让团队快速评估出目前系统稳定性现状，而且也是稳定性团队工作评价的一个标准。

稳定性评价悖论

如果一个系统非常稳定，体现不出稳定性团队工作价值。如果一个系统稳定性故障频发，稳定性团队没有做出工作价值。这似乎是一个悖论。因此不能简单的使用系统是否稳定的定性团队的工作价值。必须找到一个可度量、可观测的指标评估系统的稳定性。

同步流程评价

同步流程可以使用可用性指标度量。也就是几个9的稳定性。不同的可用性代表用户可使用时长占比。

可用性计算公式

目前业界有两种衡量系统可用性的方式，一个是时间维度，一个是请求维度，我们先来看这两个维度的计算公式。

时间维度：Availability = Uptime / (Uptime + Downtime)

请求维度：Availability = Successful request / Total request

时间维度

我们先来看时间维度的系统可用性。用一句话来概括：时长维度，是从故障角度出发对系统稳定性进行评估。

以发烧为例子，首先要定义什么情况算发烧，比如体温超过37.5，是否真正发烧还要看持续时长，偶尔一次温度超过37.5也不能算作发烧。

从例子可以看出，时长维度评估包含三个要素：

一个是衡量指标，比如体温就是衡量指标；

第二个是衡量目标，达到什么目标是正常，达不到就是异常，低于37.5 度算正常，超过 37.5 度就是异常。

但是单次测量不能说明问题，我们可以多次测量，比如 6 次中有至少 4 次低于 37.5 度才算正常，转化成比例的话就是 67%；

第三个是影响时长，比如持续超过 12 小时。

使用时长纬度评算只有系统故障才会影响可用性，这个结果计算比较粗。偶尔的接口异常或者超时没有达到故障程度不统计到不可用的范围。

时长维度也没有考虑高峰故障和低峰故障虽然时长一样对用户造成的影响，完全不同。

请求维度

请求维度，是从成功请求占比的角度出发，对系统的稳定性进行评估。

请求维度的系统可用性同样包含三个关键要素，第一个衡量指标，请求成功率；第二个衡量目标，成功率达到 95% 才算系统运行正常；第三个是统计周期，比如一天、一周、一个月等等，我们是在一个统计周期内计算整体状况，而不是看单次的。

异步流程

异步流程虽然不会直接影响业务指标，但是如果处理时间过长会影响用户体验。

异步流程评估可以使用SLA进行评价。SLA是Service Level Agreement的缩写，表示服务对于用户的承诺。
SLA主要看两个指标：

SLA时长： SLA时长=请求完成时间-请求发起时间。SLA时长直接决定用户体验。
SLA完成率： SLA完成率=SLA时间内完成的量/总的请求量。 SLA完成率影响用户满意度。

关于稳定稳定性，今天就写到这了。下一篇会详细介绍大公司如何去做服务稳定性。

稳定性系列文章1-如何评价系统稳定性？