谈谈稳定性

谈到稳定性，首先想到的肯定是SLA。

SLA全称Service Level Agreement，即服务等级协议，是服务供应商和客户就服务质量、可用性等方面达成的一种共识。^[1]

通常我们会说，某某服务的可用性达到了5个9（99.999%），这其实是可用性方面更通俗易懂的一种说法。

具体到某个具体的业务，通常会先确定一个核心指标，然后一切都围绕着它进行。

比如搜索，一般定义就是从用户点击“搜索”的那一刻起，是否能在合理时间内（通常是小于1秒）返回准确的结果。基于这一定义，通常会建立1条代表每秒搜索量（以下简称pv）和1条每秒搜索异常（超时，白页之类，以下简称pv lost）的曲线。

再围绕这2条曲线可以做很多事情，比如，每次上线时，先上线5%的机器，观察pv lost是否有波动，如果没有明显异常再进行后续批次的上线。再比如，通过监控pv曲线是否有明显的下跌来判断是否发生了网络劫持。

从核心指标本身出发，可以分2个视角：如何尽可能的提高服务的可用时间，以及如何尽可能缩短服务不可用的时间。

说起来服务不可用的最大因素首推“变更”，业内的共识是：一个经过线上充分验证又停止迭代的业务一般是不太会出问题的。这里的变更除了狭义上的程序变动之外还包括配置变动，数据库变动等等。

当然，并不是放着不动就一定不会有问题。程序会OOM，服务器会宕机，网络会抖，光纤会断，机柜会断电，云服务会故障……根据墨菲定律，大部分时候意外总能不期而至。因此业务部署最起码需要做到主备（并且不能在同一机柜上）；同城最起码需要有灾备，如果是冷备还要经常切流演练；做的好一些通常是同城双活，甚至是两地三中心或者异地多活。

除了单纯的防止不可用，还要尽量保证线上业务好用。如果等个10秒钟才勉强返回结果当然也是没意义的。因此，线上业务需要定期压测，静态资源做CDN，用户访问要就近，攻击要有拒绝策略。

这里有一个比较好的做法是服务要做降级。当然降级的前提是服务要分级。时间关系，我们埋个坑，且听下回分解。