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

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

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

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

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

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

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

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

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

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

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

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

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