01
HALT和HASS試驗的目的與聯系？
HALT是屬于研發階段的一種試驗，其主要目的是通過較高的應力水平，加速激發潛在的故障，從而實現可靠性增長的目的。同時通過HALT試驗，還要摸清產品的兩條線，一是功能線，指到達該應力水平時產品功能發生故障，但應力降下來后，功能還可以恢復；二是破壞線，在功能線的基礎上，如果應力降下來后，產品功能也無法恢復（即發生了破壞性故障）。而這兩條線也是制訂HASS試驗標準的依據。HASS則屬于生產過程中的試驗，相當于傳統ESS的增強版，是一種篩選缺陷的工序手段。
02
耐久性試驗可以用哪些指標度量，有哪些試驗類型？
耐久性是指產品在規定的使用、貯存與維修條件下，達到極限狀態（疲勞、磨損、 腐蝕、變質等）之前完成規定功能的能力。耐久性試驗一般是為了驗證產品在規定條件下的使用壽命、貯存壽命等指標是否達到規定的要求，以及發現產品中過早損耗的薄弱環節，進而分析影響產品耐久性的根本原因。可以用首次大修期限、使用壽命、貯存壽命、可靠壽命等指標來度量。
03
GO流方法與可靠性框圖方法的區別？
可靠性框圖方法（Reliability Block Diagram, RBD）利用串聯、并聯、旁聯、k/n等若干種典型的基本邏輯關系，來建立系統的可靠性模型。可靠性框圖方法有兩個基本假設：一是組成系統的各層次產品只具有正常和故障兩種狀態，且這兩種狀態之間是互斥的；二是組成系統的各層次產品，其“功能正常”事件的發生是彼此獨立的，即系統的功能正常只取決于組成系統的各層次產品的功能正常及框圖模型中給出的幾種典型邏輯關系。
GO流方法與可靠性框圖方法的區別是：用GO流方法建立系統的可靠性模型時，系統的組成單元是多狀態的，且單元與單元之間有時序關系，系統的成功取決于每個單元正常和單元之間的時序正常。GO流方法在描述系統功能成功的邏輯關系時，顯然比可靠性框圖方法要豐富。Go流方法常用于核電站、化工系統等運行時序要求高的系統。
04
FMECA、故障樹分析（FTA）和事件樹分析（ETA）？
最基礎、最常用的故障邏輯方法是失效模式影響及危害性分析（FMECA）、故障樹分析（FTA）和事件樹分析（ETA）。
FMECA方法從零部件的失效模式開始，沿著系統的層次結構自下而上，分析失效原因、失效影響，FMECA的結果構成從零部件失效到設備失效、再到子系統失效、直至系統失效等多層次、多分支的失效邏輯關系鏈條。
FTA方法以最不希望出現的故障事件為頂事件，運用邏輯門符號和事件符號刻畫導致這一故障事件的各層次原因及其原因的組合，逐層展開至不再分解的底事件。在系統的研發階段使用FTA方法，一般要建立一系列頂事件構成的故障樹集，即建立很多棵自上而下的故障樹。
ETA方法從一個初因事件開始，按時序邏輯橫向羅列后續事件直至最終的各種嚴重程度的后果事件。事件樹中的每一個事件只有發生或不發生兩種狀態，這樣構成一棵從左向右橫向展開的樹狀分支結構。
05
國產化替代等因素，導致底層硬件可靠性下降，如何保障整個系統可靠性不降低？
這種現象在很多行業都存在，比如在通訊設備領域，從原來專用的通訊硬件架構，如cPCI、aTCA等，轉換成采用通用的商用服務器。此時可靠性更多要在系統層面和業務層面想辦法，確保具有更多的系統容錯能力和業務彈性能力。比如現在的很多DC(數據中心)，采用大量的商用服務器，服務器本身尤其是其中大量的硬盤在頻繁數據讀寫的情況下，極易發生故障，此時服務器通過采用集群和冗余的架構，可以將故障硬件上承載的業務遷移至正常的設備上，從而抵消掉硬件故障對系統和業務帶來的負面影響。
06
針對商用開源軟件可靠性加固問題的建議？
現在很多行業使用的軟件已經從原來專用的軟件向商用開源軟件轉化，而很多商用開源軟件原本就不是針對高可靠應用場景(如電信)開發的，因此不能很好的滿足這些應用的可靠性要求，此時就需要針對其可靠性特性進行增強。比如在NFV(網絡功能虛擬化)中，其中一個常用的商用虛擬化軟件VMware，其對于虛擬機的故障管理部分（VMtools）不能滿足電信級應用的可靠性要求，VMware的虛擬機故障檢測時間通常在20s左右，而電信級的業務要求通常在幾秒，甚至毫秒級，因此需要對這部分的可靠性特性進行增強，即所謂的加固。
07
軟件可靠性與其運行時間的長短有沒有直接的聯系？
如果將軟件看成一段靜態的軟件代碼，那么軟件可靠性和運行時間是沒有直接聯系的。但是，從現實狀態看，通常是因為軟件運行時間長，軟件經歷的使用場景就越多，因此觸發的故障可能就會越多。從這個角度分析軟件可靠性和其運行時間是有關聯的。但是，如果軟件始終就運行在同一個場景，那么只要第一次不出現問題，后面運行時間多長也不會出現問題。
再從更宏觀的時間去看待軟件老化的問題，可以這樣理解，雖然相同的一段靜態代碼是沒有變的，但是隨著更長尺度時間的推移，當前支撐這段代碼運行的軟硬件環境已經和編制軟件當時發生了顛覆性變化，導致當前的軟硬件環境已無法使用這段軟件代碼，這也可以理解為軟件的老化和退化。
08
產品具有多樣性、開發進度短的特點，全面深入開展可靠性有困難，如何解決？
企業需要把平臺可靠性和產品可靠性分開考慮，產品可能有很多，但基本的軟硬件平臺不會很多，且不會經常變動，所以這部分有充分的時間可以把可靠性做深入。同時如果是迭代開發的產品，還可以分公共部分和新開發部分。模塊化做得好的產品，可以把一些公共模塊的可靠性做好，類似于前面說的平臺可靠性，剩下的只需要集中精力把產品新開發部分的可靠性做好就行了，工作量會減少很多。
09
各品類元器件如何進行選型、采購？可靠性測試的標準和方法是什么？
器件選型和采購需要研發部門和采購部門分工協作。現在國內很多企業把器件選型交給研發部門做了，這是錯誤的。研發部門的職責是結合各類器件的工藝、功能指標和實際使用環境對器件提出可靠性要求和規格，再交給采購部門去完成器件和供應商的選擇和控制，這樣可以明確分工，減少工作量，也可以發揮采購部門的優勢。可靠性測試的標準和方法，可以參考器件的頂級供應商給出的測試標準和客戶對器件的要求。
10
能否介紹一下可靠性CBB？
這里所說的可靠性CBB實際上就是公共可靠性解決方案。對于一些共性的可靠性問題或需求，通過構建可靠性CBB，為研發人員提供參考的解決方案和思路，并實現在整個企業內的共享。比如軟件升級不中斷業務這個特性，我們開發出設計方案，可以把它寫成CBB，這樣以后某個產品需要實現這個特性時，就可以拿來作為參考。一個需求或特性可以對應多個CBB。另外CBB并不是具體的實現方案，而只是一個方案思路，用一頁紙把方案思路說清楚即可，不需要給出具體的電路設計或實現代碼。
以上問答，僅供參考。
