可靠可用性基本知识

1. 基本概念

1.1 可靠性

• 举例1：
  例如我想用一个锤子捶钉子，这个锤子捶钉子的功能正常，能达到我想捶钉子的目的，说明是可靠的，如果捶钉子功能异常，说明可靠性差。可靠性更多从功能的角度出发，能否达到用户的目的。
• 举例2
  如果锤子坏的频次比较高，说明可靠性差，锤子坏的频次低，说明可靠性高，可靠性有频率属性。
• 举例3
  如果锤子被弄坏了左边的锤头，虽然左边坏了，用的时候右边能很快顶上，照常能用，说明锤子是可靠的。说明可靠性具备一定的冗余，能抗部分风险。

关键字：功能相关、频率属性、有抗一定风险的措施。

1.2 可用性

• 举例1
  例如我想用一个锤子捶钉子的时候，这个锤子是处于正常可用状态的，说明是可用的，如果正在处于维修状态、故障状态，那锤子就是不可用的。可用性更多关注使用某项功能时，功能是否处于可用状态，具有时间属性。
• 举例2
  如果锤子一年的时间，半年都是坏的，说明可用性差，如果锤子一年只有1min是坏的，说明可用性高。
• 举例3
  如果锤子坏了，短时间就能恢复，可维修性高，说明可用性高。

关键字：可用状态、时间属性、恢复

2. 可靠和可用性指标

• MTBF: mean time between failure
• MTTR: mean time to recovery
• SLA: Service Level Agreement
• 失效率：λ = 1/MTBF
• 返修率：λt，t的单位是h，t=36524时值为年返修率。
• 返修率：失效数/发货数
• 修复率：μ = 1/MTTR
• 可用度：A(availability) = MTBF/(MTTR+MTBF)
• 危害性分析CA(Criticality Analysis):可以用Risk Priority Number(RPN)来表示 RPN = SPD，解释：S-严酷度参考值：40(I)\20(II)\5(III)\1(IV),P-出现的概率FITs,D-客户发现的概率参考值5(esay)\1(hard)\0.2(not))
• 故障模式和失效分析和危害性分析：FMECA = FMEA+CA
• 故障树分析:详情见链接。

例如：
1、网易云音乐网站可用度要达4个9
2、5G服务一般要达5个9

3. 可靠性工程实践相关概念

• 流程： 可靠性需求分析-可靠性目标\指标-故障建模-FAT\FMEA-故障执行-可靠性评估。
• 可靠性评估：测试能力评估+产品可靠性评估。
• 故障处理流程：检测-隔离(故障只影响本故障域)-诊断and定位-恢复or修复(尝试恢复的操作影响应该由小到大，线程-进程-应用-系统(DC重启-AC重启))。
• 故障隔离：ITU-T有介绍
• 业务过载处理：检测、限流、降级、熔断or扩容。
• 冗余(锦上添花)：冷热备份。
• 灾备(另起炉灶)：贵州内蒙数据中心灾备。业务灾备>应用灾备>数据灾备
• 故障预测方式：基于故障机理的故障预测，基于数据驱动的故障预测
• 故障注入工程技术：混沌工程

4. FEMA相关知识

4.1 基本概念

• FMEA: Failure Mode and Effects Analysis
• 分为设计FMEA和过程FMEA
• 设计FMEA与产品的本省有关，是对产品的组成可能出现的故障模式和故障后可能带来的影响进行分析，并把影响可以分级，从而对影响较高的部分采取防范措施，提升产品啊可靠性。
• 过程FMEA与流程相关，例如加工流程中可能出现故障，分析其影响，提出改进措施。
• 对单板来说：FMEA分析是分层的，可分为器件级、信号级、系统级，器件级主要针对单板上的各种芯片、mos管、核心器件等，信号级主要针对信号类型，例如IIC\SPI\JTAG等，系统级主要是指主从系统，灾备系统等。

4.2 FEMA分析流程

这里拿单板的FMEA分析进行举例。

功能或失效器件	bom编码	器件或功能描述	故障模式	故障原因	故障发生的可能性	对单元的影响	对系统的影响	故障等级	检测方式	故障应对措施
电源芯片	U12345	将24V转化成12V	芯片使能管脚失效	使能管脚失效导致芯片不能正常工作	高	供电单元失效	单板下电	致命	电源灯不亮	多路电源供电

• 功能或失效器件：单板的电子元器件。
• 故障模式：导致功能或器件失效的模式：芯片电压脚电压偏低\偏高\时钟频率异常\使能管脚与其它管脚连锡。
• 故障发生可能性：与失效率相关.
• 故障等级：致命、严重、一般、提示。
• 检测方式：通过何种手段观察到故障现象。

5. 产品开发流程中可靠可用性测试如何开展

5.1 测试可靠可用性输入\输出

输入1：通过反复实验、或者加压等措施增大故障发生的可能性。
输入2：通过外部直接注入故障，代替生产或者实际使用过程中去触发。
输出1：观察系统的检测\定位故障、承受\控制故障、恢复故障是否符合预期的能力。
输出2：故障注入时，通过对系统内部指标监控，通过积累指标的形成的数据经验模型，可以预估故障，帮助用户或者开发人员预防故障。

• 定义：通过故障注入措施，给被测系统注入故障，观察系统检测\定位故障、承受\控制故障、恢复故障的能力进行评估，判断是否满足设计预期，推动减少产品失效率。

5.2 可靠可用性开展流程

• 开发流程

概念	计划	开发	测试	发布
需求与计划	测试方案设计	用例设计&迭代验收&①&②	③&发布测试版本	产品测试关闭

① SDV：(System design Verify)系统设计验证
② SIT：(System Integration Testing) 系统集成测试，也叫做集成测试
③ SVT：(System Verification Test)系统确认测试（系统模拟测试）

链接1:专业名词参考
链接2:IPD流程参考

• 测试活动

设计	执行	评估
分析需求	测试执行方法	评估指标
分析测试对象	测试观察点确定	评估
结合测试模式库分析	测试工具利用

• 测试输出

设计输出	执行输出	评估输出
测试方案&测试用例	执行结果&指标数据	测试报告

5.3 测试设计

• 分析被测对象，分析可以是多个角度，开发视角(从系统架构角度)、部署视图角度(组网)、用例视角(操作)等，即可得到被测对象。

开发视角：系统与外部接口、系统组件、组件间接口。
部署视角：物理连线图、部署节点拓扑。
用例视角：登录、登出、购买、退货、开机、关机等。

• 依赖测试模式库：测试模式库设计是一门学问，来源包括网上问题、历史模式库、新特性分析产品的故障模式、还有发散性思维得出来的故障模式；故障模式一般是开发中不能或者不好解决的故障，或者需要一定冗余和容错能力才能解决的故障，如果可以在开发中可以解决，就直接落到开发流程，例如PCB链路开路导致温度检测功能失效，PCB链路开路就是难以在开发中解决的问题，就可以提取出开路的故障模式；模式库有编号、名称、来源、测试方法(目的\环境搭建\步骤)、预期结果(defense-detect-sustain-expect)。
• 测试对象和测试模式库分析匹配，等到测试对象关联的故障模式，结合具体产品，即可得到可靠性测试用例集。

5.4 测试执行

5.4.1 执行前准备

• 包括：物料准备、固件准备、网络准备、部署准备、配置准备、工具准备、用例准备等。

5.4.2 故障注入方法

1. 故障注入测试：

• 手工注入、自动化注入
• 工具注入、命令行注入
• 硬件注入（上电前注入故障+运行中注入故障）、软件注入（寄存器注入、冷补丁注入）

3. 压力测试：负载测试、CPU\内存\高并发测试，观察系统检测、承受\响应，恢复的能力。
4. 长稳测试：通过冷启动反复上下点、通过热启动反复上下电，观测时间可以是7*24小时

5.4.3 故障现象\结果记录

• 观察点：linux日志、管理系统日志、查询状态回显、灯态、告警、黑匣子、网络日志、系统工作状态(正常、降级、挂死)等。
  

①：故障注入时间点
②：故障暴露时间点
③：业务恢复时间点
④：故障恢复时间点
⑤：智能分析总结or备份时间点
②-①：检测时长：不考虑成本，检测时长越短越好。
③-最小SLA\access时间点：业务中断时长。
③-①：业务恢复时长。
④-①：故障恢复时长。
⑤-④：总结时间or备份时长。

5.5 测试评估

• 可靠性完整性，需求覆盖度。
• 可靠性策略完整完备情况，测试对象覆盖度。
• 可靠性策略有效性，TOP问题缺陷覆盖度。
• 可靠性设计完整性：模式覆盖度
• 可靠性用例覆盖度
• 可靠性用例执行率
• 可靠性用例通过率

NA	测试需求	测试策略	测试设计	测试执行	测试评估
可追溯	全部需求都有对应设计		①全部设计都有对应用例、②测试对象都有测试设计	①测试用例有执行记录、②问题单关联用例	评估模型明确、无疑义
完备性		测试策略目的明确、范围明确、主次分明	测试对象涉及的模式库都有覆盖		评估维度齐全
有效性		关键问题全覆盖			评估模型科学