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