#💎 可靠性理論

說起穩定性或者可靠性，其實已經有相關的理論研究了,

可靠性問題是在第二次世界大戰前後，才真正開始受到重視。
其基本原因之一是軍事技術裝備越來越複雜。
複雜化的目的在於使技術裝備具有更高的性能。

但是裝備越複雜，往往就越容易發生故障，
到了複雜化的程度嚴重影響設備可靠性時，裝備複雜化也就失去了意義。
因此，複雜化和可靠性之間存在著尖銳的矛盾。

另一個基本原因，新的軍事技術裝備的研制過程，是一種爭時間爭速度的競賽。
但是研制周期又很長，經不起研制過程的重大重覆。

這就需要有一整套科學的方法，將可靠性的考慮貫穿於，
研制、生產和使用維修的全過程。
因此複雜設備的可靠性成了相當嚴重，而又迫切需要解決的問題。

這樣看來，軟件的可靠性並不是人們第一次遇到的可靠性問題，
也不是拍腦袋就能輕易解決的問題。
有適當的理論知識作為鋪墊，才不會重蹈覆轍，而是能把精力用到該用的地方。

#🔗 串聯系統

串聯系統是由 n 個部件串聯而成的，任一部件失效都能引起系統失效。
串聯系統的可靠度，為單個部件可靠度的乘積。

一個複雜的軟件系統，考慮各子系統之間的依賴關系，即可簡略看成是一種串聯系統。
這條鏈路越長，各自系統越不可靠，整個系統就越容易出問題。
所以，軟件分層雖有助於職責分離，但對可靠性來說猶如雪上加霜。

考慮我們現實中的研發場景，研發過程中所產生的依賴，實則是一層一層的。
最淺的一層是團隊內維護的一些公共代碼庫，
繼而下層是部門或公司級別的一些軟件設施，或者框架。

就到這里為止了麽？其實還遠遠不夠。
更下層是一些開源的類庫框架，或者其他知名公司的軟件產品，
更下層還有，是全球範圍內適用的一些規範，以及基礎建設。

工程師不是站在一層之上進行開發的，而是有很多層，
每一層都有“暗坑”，每一層都有可能導致最終的軟件出現問題。
可悲的是，專業工程師必須對最上層軟件的可靠性負責。

所以，有人說工程師是站在一座“垃圾堆”上幹活的，也是可以理解的。
只是這個“垃圾堆”的範圍和深度，遠超大多數人的認知之外而已。

#🧱 孰輕孰重

現實中有些系統的可靠性，已經差到令人發指的地步了，
工程師們每天都得花費很多額外的時間去解決問題。

為什麽就沒人考慮把它修好呢？

這是因為，保持原樣比修好它，對企業而言可能會更省錢。
提高系統的可靠性，不是免費的午餐，
企業需要投入更多的成本才能做到，包括招聘更好的工程師。

因此，軟件基礎設施，是總難足夠可靠的，
一旦到了勉強夠用的地步，就不會再優化下去了。

相較而言，對最終產品有害的可靠性問題，會優先解決，
而研發困難問題，很少有企業會舍得花錢。

很明顯，工程師需花費更多的時間開發軟件，
可以讓他們加班，
好過花錢找人解決研發問題，讓工程師們早點回家。

無償加班，掩蓋了問題實質。
能用省錢的方式解決，為什麽要花錢呢？
這樣就把“該不該去”解決的“道德問題”，轉變成“值不值得”解決的“商業問題”了。