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并不是具体的实现方案，而只是一个方案思路，用一页纸把方案思路说清楚即可，不需要给出具体的电路设计或实现代码。
以上问答，仅供参考。
