187

如何看待系统的可用性?

 6 years ago
source link: https://mp.weixin.qq.com/s/-T9JoM41yJrqxX2rpIYVUA
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

如何看待系统的可用性?

Original Tim TimYang 2017-10-11 02:44 Posted on

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

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

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

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

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

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

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

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

扩展阅读

Image

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK