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