如何看待系统的可用性?

前几天针对鹿晗事件中微博短时间内部分用户不能访问的现象，很多业界的技术朋友也在热烈讨论系统可用性的难点及应对之道，这里简单说下对可用性的个人看法。

大型系统的可用性犹如对一条河流治水，解决了单点故障对系统的影响之后，剩下一个最主要工作就是了解及评估系统的警戒水位线，这也是我们这次应对不足的地方。水位线是评估一个系统应对更大流量的核心指标。由于成本及人力的原因，我们无法盲目的进行机械倍数式的扩容，如果了解警戒水位线，我们可以及时的根据水位线对薄弱的环节进行扩容，犹如治水中的拓宽堵塞河道。如果突发的容量超过境界水位线时候，就会发生系统决堤的风险。突发的事件并不会象大自然的洪水那样会有一定时间预警，它也许会在10分钟或者半小时之内来临并达到峰值。

评估单个模块的容量并不难，有很多已知的方法可以达到，比如通过 QPS 与系统 load 关系，以及主动压测来评估系统极限等方法来实现。但对于一个有很多模块及服务构成的大型复杂系统来说，这个评估并不如一些人想的那么简单。监控系统每秒会收集到百万到千万级别的数据指标，最后会归并到数百个 dashboard 图表中，但这些图表可能无法直接告诉你哪些是最关键的信息。也许新兴的人工智能 AIOps 未来可以帮助我们更好地发现及感知类似问题。

大型系统更像一条长河而非大坝，所以很难通过单个指标直观看到所有系统的警戒水位线，也较难通过一场运动或者升级一个核心的部件来解决。但系统可用性也并非无解或不能评估，提升可用性是一个长期趋近目标的过程（比如趋近 99.99% 或 99.999%），科学的容量评估及监控手段是保证可用性的关键。

由于条件的限制，真实容量评估非常困难，我们无法去事先全量模拟洪峰，大部分容量评估都是针对局部，比如针对模块或者服务级别；也有一些变相的整体压测方法，比如人为让河道变窄来升高水位，局部洪峰的方法大可积极采用，因为它可以帮助我们主动发现一些问题，我们以前应对春节的压测就发现在变窄河道中，老化的交换机出现访问波动的情况。但是另外一方面局部压测和真实的峰值毕竟存在差异，因此通过历史的峰值来判断系统的承载能力是一种更有效的方法，但是历史峰值毕竟受条件限制，非人为可以制造。因此到目前为止，局部模拟洪峰依旧是常用的方法。

容量评估还有异构的复杂性。一条河流往往由很多团队分而治之，这些团队的理念和重心也各不一样，导致防护的重点也各有差异，但这些防护重点也往往是经验式的，经验少的团队就会有更大的可用性风险，这些风险只能通过团队之间的交流及共同治理来弥补。

虽然架构师的有一些共识比如先保证核心区域，但是一个在不断迭代的系统，核心区域的范围也在实时发生变化。新上线的系统的访问型态也可能相比之前有很大变化，这些变化也许只是一万行代码里面的某一行对核心系统 RPC（远程调用） 带来。正常情况下，这行调用不会给核心系统同比环比调用带来明显变化，但类似调用的增加，逐渐带来水位线的增高，由于系统是一条河流而不是一个可控距离的大坝，部分区域的增高就不容易被整体迅速感知，最终可能产生决堤的风险。能实时监控感知访问型态的变化对于异构系统来说至关重要。

对系统容量的科学监控及评估，决定了系统可用的成熟度，提升可用性是一个系统性的工程，需要通过消除单点故障、弹性伸缩能力、科学的容量评估、对访问型态的积极感知，跨团队的治理、智能化的监控等方法来综合解决。