系统高可用与有罪推定论

最新IT圈最火的支付宝与携程,注定要将蓝翔神技与运维逆袭载入史册。无论故障的过程与真实原因如何,都足以让大家对整个生产系统的建设进行反思并加以检讨。

 

多年以来各设备厂商,解决方案都在强调自身系统可用有多高,可用达到n9。而这些n9SLA承诺通常是在使用统计学上的概念,甚至于在配置了双机或集群的状态下,计算可用性直接将故障率直接相乘,即(1-1-99%*1-99%))=99.99%。这样的算法对于实际工作来说,其实是无意义的。

系统出故障好比中彩票,谈论百分比毫无意义。中了的人就是中了,100%;没中就是没中,0%。中奖的人不会把奖金分给没中奖的人,同理,出故障的系统不会因为系统中的设备众多而减少故障处理时间,或因平摊设备故障而减少故障时间。

系统n9的高可用是外企在推销产品时的传统促销手段,即如国外的司法上流行的无罪推定论,强调的是产品的有效性。然而,任何人都不能保证建设系统后不出故障,我们向客户推荐高可用、容灾系统解决方案就是为了将故障损失降低到最低。

故此,我们在向客户推荐高可用,容灾系统解决方案的时候应当抛弃传统SLAn9的概念,直接用有罪推定论,直接告诉客户,当你的系统故障后恢复需要多长的时间,如:

1.        硬件故障后更换备件所需要的时间。包括故障诊断时间,备件到场时间,以及备件现场更换时间等(可以想象偏远地区客户多么悲催);

2.        系统故障后恢复系统需要的时间。包括故障诊断时间,系统启动时间(虚拟机包括宿主机及虚拟机启动时间),双机切换时间,集群漂移时间,甚至于重新安装系统的时间等;

3.        应用故障后恢复应用需要的时间。包括故障诊断时间,应用启动时间,数据完整性校验时间,相关系统恢复时间等;

4.        不可抗力故障后恢复的时间。包括自然灾害,楼宇基础设施故障(风火水电),相关供应商故障(万能的挖掘机)等;

5.        人为故障后恢复的时间。包括黑客入侵,内部破坏,操作失误等引起的故障,甚至与法律法规类的伟大的墙等。

以上只是系统运行过程中可能遇到的故障大致分类,具体内容还需要大家进一步发掘。有人可能要说我是不是太悲观了?我说我是个乐观主义者,最大灾难不过一地的楼倒了,数据没了,只要世界还在,一切数据都可以重来。

“Tomorrowis another day.”

 

让我们抛弃n9SLA观念,用系统有罪推断论来建议客户吧,只有客户真正理解了故障所能引起的灾难性后果,才能珍视IT人员的价值,才能在系统建设之初就能选择更加合理的方案。


你可能感兴趣的:(高可用,解决方案,故障率,容灾系统)