可用性和可靠性的區別
首先,這兩個屬性都是質量(可維護性)的一部分。
按照書上的定義,
可靠性(reliability):在規格時間間隔內和規定條件下,系統或部件執行所要求功能的能力。例如:
QA1:在客戶端與伺服器端通訊時,如果網路故障,系統不能出現故障。
可用性(availability):軟體系統在投入使用時可操作和可訪問的程度,或能實現其指定系統功能的概率。例如:
QA2:系統的可用性要達到98%。
實話說我一直想吐槽這個定義,說得未免太模糊了一點。尤其是可用性的定義,用術語解釋術語可太秀了。後來在看分散式系統的時候,看到了一個解釋:
可用性被定義為系統的一個屬性,它說明系統已準備好,馬上就可以使用。換句話說,高度可用的系統在任何給定的時刻都能及時地工作。
可靠性是指系統可以無故障地持續執行,是一個持續的狀態。與可用性相反,可靠性是根據時間段而不是任何時刻來進行定義的。
如果系統在每小時崩潰1ms,那麼它的可用性就超過99.9999%,但是它還是高度不可靠。與之類似,如果一個系統從來不崩潰,但是每年要停機兩星期,那麼它是高度可靠的,但是可用性只有96%。
我覺得這個解釋說得很好。可靠性是一個持續性的狀態,更多地強調系統自身;而可用性是一個短暫的狀態,更多地強調外部的觸發。就好比一個人,你找他的時候能不能找到,這是可用性;而他幹活靠不靠譜,則是可靠性。一個人如果隨叫隨到,但是時不時偷懶,就是高可用、低可靠;而如果他經常找不到人,但幹活很負責,就是低可用、高可靠。其實就是上面說的那個例子了。
再回到書上的例子去。為什麼“網路故障,系統不能出現故障”是可靠性?其實也是比較顯然的。這是一個持續的過程。網路故障的時候,系統不出現故障,維持了正常執行狀態,正是高可靠的表現;而且,系統不受外界影響,體現出內在的穩定性,也是可靠性的隱藏要求吧。
從某種程度上,可用性包括了可靠性。如果不可用,根本談不上可靠。有一個定義:
平均故障間隔時間(MTBF,Mean Time Between Failure),是指相鄰兩次故障之間的平均工作>時間,是衡量一個產品的可靠性指標。
平均修復時間(MTTR,Mean Time To Repair),是描述產品由故障狀態轉為工作狀態時修理時間的平均值。在工程學中,MTTR是衡量產品維修性的值,在維護合約裡很常見,並以之作為服務收費的準則。GB/T3187-97對可用性的定義:在要求的外部資源得到保證的前提下,產品在規定的條件下和規定的時刻或時間區間內處於可執行規定功能狀態的能力。它是產品可靠性、維修性和維修保障性的綜合反映。
Availability = MTBF / (MTBF + MTTR)
從這裡也可以看出,可靠性強調的是一個持續狀態。
參考資料:
《軟體工程與計算(卷二):軟體開發的技術基礎》
參考:
相關文章
- 可用性、可維護性、可靠性有什麼區別?
- ../和./和/的區別
- 和 的區別
- as 和 with的區別
- ||和??的區別
- /*和/**的區別
- LinkedList和ArrayList的區別、Vector和ArrayList的區別
- http和https的區別/get和post的區別HTTP
- ./ 和sh 的區別
- JQuery this和$(this)的區別jQuery
- jquery $(this) 和this的區別jQuery
- T和?的區別
- ++a和a++的區別
- makefile =和:=的區別
- Mybatis中#{}和${}傳參的區別及#和$的區別小結MyBatis
- 和區別
- MYSQL和SQL的區別MySql
- varchar和char的區別
- &self 和 self 的區別
- var和public的區別
- filter和interceptor的區別Filter
- useEffect 和 useLayoutEffect 的區別
- SDK和API的區別?API
- var 和 let 的區別
- WebApi和MVC的區別WebAPIMVC
- service和systemctl的區別
- GET和POST的區別?
- GET和POST的區別
- button和submit的區別MIT
- GET 和 POST 的區別
- 【Java】equals 和 == 的區別Java
- django和flask的區別DjangoFlask
- promise 和 Observable 的區別Promise
- sass和less的區別
- POST 和 GET 的區別
- cookie和session的區別CookieSession
- MTV和MVC的區別MVC
- mysql中!=和is not的區別MySql