If I have seen further it is by standing on the shoulders of Giants.
如果说我比别人看的更远一点，那是因为我站在了巨人的肩膀上。
站在巨人的肩膀上，并不是牛顿发明的，却因为牛顿而广为流传，
甚至 Google Scholar 都把这句话放到了首页。
它表示，在前辈的工作基础上进行新发现。
这像极了当今的软件生态。
甚至可以说任何软件，都很难不在别人的基础之上进行开发。
这个基础，说的就是基础设施，或者软件生态。
很显然要想把软件做的可靠，基础也得可靠才行，
否则就像是巨人站在了泥足之上。
然而，现实生活中，很多软件系统的基础设施都是不可靠的，
被依赖方经常会出现各种各样的问题，导致软件不可用，或者不好编写。
这里提到了两种不同的概念，运行可靠性，以及研发可靠性。
运行时不稳，会导致很多用户可见的问题，损害企业的利益，
而研发时出现各种各样的问题，却大多由开发者自己扛了。
这是因为，研发困难并不是企业直接关心的事情。
下面我们来分析一下其中的取舍和原因。
可靠性理论
说起稳定性或者可靠性，其实已经有相关的理论研究了，
在《可靠性数学引论》中，作者是这样写的，
可靠性问题是在第二次世界大战前后，才真正开始受到重视。
其基本原因之一是军事技术装备越来越复杂。
复杂化的目的在于使技术装备具有更高的性能。
但是装备越复杂，往往就越容易发生故障，
到了复杂化的程度严重影响设备可靠性时，设备复杂化也就失去了意义。
因此，复杂化和可靠性之间存在着尖锐的矛盾。
另一个基本原因，新的军事技术装备的研制过程，是一种争时间争速度的竞赛。
但是研制周期又很长，经不起研制过程的重大重复。
这就需要有一整套科学的方法，将可靠性的考虑贯穿于，
研制、生产和使用维修的全过程。
因此复杂设备的可靠性成了相当严重，而又迫切需要解决的问题。
这样看来，软件的可靠性并不是人们第一次遇到的可靠性问题，
也不是拍脑袋就能轻易解决的问题。
有适当的理论知识作为铺垫，才不会重蹈覆辙，而是能把精力用到该用的地方。
串联系统
串联系统是由 n 个部件串联而成的，任一部件失效都能引起系统失效。
串联系统的可靠度，为单个部件可靠度的乘积。
一个复杂的软件系统，考虑各子系统之间的依赖关系，即可简略看成是一种串联系统。
这条链路越长，各子系统越不可靠，整个系统就越容易出问题。
所以，软件分层虽有助于职责分离，但对可靠性来说犹如雪上加霜。
考虑我们现实中的研发场景，研发过程中所产生的依赖，实则是一层一层的。
最浅的一层是团队内维护的一些公共代码库，
继而下层是部门或公司级别的一些软件设施，或者框架。
就到这里为止了么？其实还远远不够。
更下层是一些开源的类库框架，或者其他知名公司的软件产品，
更下层还有，是全球范围内适用的一些规范，以及基础建设。
工程师不是站在一层之上进行开发的，而是有很多层，
每一层都有“暗坑”，每一层都有可能导致最终的软件出现问题。
可悲的是，专业工程师必须对最上层软件的可靠性负责。
所以，有人说工程师是站在一座“垃圾堆”上干活的，也是可以理解的。
只是这个“垃圾堆”的范围和深度，远超大多数人的认知之外而已。
孰轻孰重
现实中有些系统的可靠性，已经差到令人发指的地步了，
工程师们每天都得花费很多额外的时间去解决问题。
为什么就没人考虑把它修好呢？
这是因为，保持原样比修好它，对企业而言可能会更省钱。
提高系统的可靠性，不是免费的午餐，
企业需要投入更多的成本才能做到，包括招聘更好的工程师。
因此，软件基础设施，是总难足够可靠的，
一旦到了勉强够用的地步，就不会再优化下去了。
相较而言，对最终产品有害的可靠性问题，会优先解决，
而研发困难问题，很少有企业会舍得花钱。
很明显，工程师需花费更多的时间开发软件，
可以让他们加班，
好过花钱找人解决研发问题，让工程师们早点回家。
无偿加班，掩盖了问题实质。
能用省钱的方式解决，为什么要花钱呢？
这样就把“该不该去”解决的“道德问题”，转变成“值不值得”解决的“商业问题”了。
结语
刚开始工作时，总容易把没有被解决的问题，
当成是别人没看到，其实并不尽然。
有很多问题是，大家都看到了，但认为不值得去解决它。
从商业角度来看每一件事，可能会有意想不到的收获。
只是有很多团体和个人，并不会把赚钱当做唯一目标，
凡事都从能不能赚的更多作为出发点，
长此以往，会忽略很多重要但是不赚钱的事情，成为今后发展的障碍。
因此，大至企业小至团队，一个有远见的领导者是很重要的。
水能载舟，亦能覆舟。