不合理的设计终究要断裂

多年以前,由于要兼容滚筒洗衣机,在装修的时候,选择了台下盆和柜子的组合(下图的样子供参考)。台盆与大理石台面用粘合剂(大理石胶为主,玻璃胶填缝)粘在一起,这样一个设计,现在看来是不可能持久的。果然在几年后,台盆一侧粘不住下沉。好在由于下水是铝管,同时有柜子隔板,台盆还能勉强使用。具体原因有多个方面,能想到的有两个(1)由于重力因素,台盆会对粘合剂有个向下的力,自然造成老化(2)台盆蓄水或者清洁都对粘合剂造成向下的压力,会加速粘合剂老化。

请物业师傅来维修,由于我和师傅均不想整体替换,物业师傅选择的方案还是大理石胶。但是在安装的时候,维修师傅发现,这样肯定还会掉下来,他也不想以后还要来维修(维修费包含在物业费中,不另外支付),于是师傅给出了一个加固方案:在台盆下面加装两个木棍,把台盆托举起来,这样台盆就很难掉下来了。最终形成了类似图二的样子,虽然有些丑陋,还算实用。

image

图1:参考系统的样子,需指出这是一个定制化的系统

image

图2:物业维修人员完成的维修,预计可以继续使用很多年,直到木棍滑脱或者断裂

这个生活案例看似很小,其实却说明了两个重要的问题:

一、不合理的设计必然导致断裂,造成故障

ISO25010(ISO9126的升级版本)定义了软件质量(大质量)的标准,这些内容是多年软件研发的质量实践合集,下图是定义了8个维度的软件质量,任何一个出现问题都可能造成故障或者投诉。

对照前面的案例分析,这是一个可用性设计问题。首先是有老化问题,系统在日积月累的使用中,可用性会下降,这类问题在硬件系统中产生的可能性较大,软件本身没有磨损问题,但是在日志存储、配套组件升级中却可能出现类似“老化”的问题,造成故障。其次在业务量增加的时候,系统容量不足,会造成故障,只要涉及到数据处理、网络处理、数据库、文件系统、对象存储等等,都很容易出现容量不足问题。最终会造成系统断裂

image

 

二、维护人员可以修复断裂,但是未必能根治

软件系统的维护方法很多,一般由SRE执行,通常采用“带外”的方式来维护系统。对比上面的案例,就是通过引入配套系统和机制来提升系统的可靠性。很典型的场景就是负载均衡(如图3):当单机(粘合剂)不能支撑业务的时候,就引入两个子系统(两根木棍)来分担流量(重力+压力),这样即便台盆蓄水造成重量增加,或者由于清洗台盆增加向下的压力时,由于支柱的存在,系统会抗住压力保持稳定。

这种场景下需要SRE人员有较强的经验和动手能力:需要找到方法,找到木棍,掌握测量所需木棍的长度、裁剪木棍,并将木棍和台盆组合在一起,之后还要测试验证不会脱落。负载均衡是一种常用的带外维护手段,如果系统在设计时就有所考虑,则会容易很多;否则也不是不能做,麻烦些而已。

与此同时,SRE人员一般不会修改产品本身代码来加固系统,一方面技能重点和研发人员不同,责任和分工也不同。一方面,已经交付的系统,如果要修改原始设计、根治原因、再次交付的成本太高,对客户的业务影响也更大,双方都未必同意。

image

图3:负载均衡设计:用更多的服务器来抗住处理压力

不合理的设计终究要断裂》有2个想法

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注