2-张庆先-大型通讯软件可靠性工程实践.pdf

《2-张庆先-大型通讯软件可靠性工程实践.pdf》由会员分享，可在线阅读，更多相关《2-张庆先-大型通讯软件可靠性工程实践.pdf（40页珍藏版）》请在三个皮匠报告上搜索。

1、大型通讯软件可靠性工程实践张庆先张庆先二十年软件研发和项目管理经验中兴通讯质量专家和敏捷专家现任过程质量改进教练目录CONTENTS软件可靠性的底层逻辑01 大型通讯软件维测现状02 软件可靠性与维测正向设计融合方法论03 大型通讯软件维测正向设计实践与收益04 总结与展望05 01软件可靠性的底层逻辑2022年全球著名企业软件质量事故月份公司事件原因1IBM达拉斯地区的云服务宕机时间大约五个小时，次日虚拟私有云产品亦出现问题，持续大约一个小时，影响华盛顿特区的用户和日本。2英国航空在线服务中断了几个小时，导致数百个航班取消，影响波及全球，并中断了航空公司的运营。应用服务器存在单点失效。3Go

2、ogleTraffic Director工具的用户经历了“2小时35分钟的严重服务错误”，Spotify、Discord等服务受到了这次宕机的影响。代码更改假设配置数据格式迁移已经完全完成，但实际数据迁移尚未完成。4Atlassian用户无法访问Jira、OpsGenie、Confluence和其他Atlassian云服务，始于4月5日，部分客户在4月8日之前恢复了服务，而有些客户直到4月18日才恢复。5SpotifySpotify博客宕机，持续了8小时，播客听众无法访问平台过期的安全证书。6微软部分用户在连接位于弗吉尼亚州的美国东部地区的资源时遇到了问题。这次宕机影响了应用程序洞察、日志分析

3、、托管身份服务、媒体服务和NetApp文件，造成了延迟、登录失败和访问账户的问题。该问题持续了大约12个小时。冗余电力系统的组件产生了意外的电气瞬变，导致空气处理单元(ahu)检测到潜在的故障后自动关闭。7Rogers一次拙劣的维护更新导致Rogers Communications的网络在加拿大范围内长时间不能正常工作。这次宕机影响了大约1200万客户的电话和互联网服务，并阻碍了全国各地的许多关键服务，包括银行交易、政府服务和应急响应能力。外部BGP路由的退出可能是由内部路由问题引起的。8Google短暂的宕机影响了谷歌搜索和谷歌地图，全球用户无法使用这些广泛使用的谷歌服务约一个小时。试图访问

4、这些服务会导致来自谷歌边缘服务器的错误消息。根本原因是软件更新出错。9Zoom全球用户出现了502（Bad gateway）错误，用户无法登录或加入会议，在某些情况下，已经参加会议的用户会被踢出会议。这次事故波及美国波士顿、纽约市、华盛顿特区和旧金山等地区的用户，历史2小时。10WhatsApp发生了两小时的宕机，导致用户无法在平台上发送或接收消息。事故发生在印度的高峰时段，该应用在印度拥有数亿用户。与后端应用程序服务故障有关，而不是网络故障。Gartner 2023年十大战略技术趋势中提到的数字免疫系统（DIS），结合了可观察性、AI增强测试、混沌工程、自修复、站点可靠性工程和软件供应链安全

5、等实践和技术。从软件可靠性定义谈起在规定条件下、规定时间内，软件不引起系统失效的概率1、软件运行的软硬件环境2、软件输入操作空间及概率分布1、日历时间（自然时间）2、时钟时间（开始执行到结束）3、CPU时间（CPU执行时间）软件系统运行行为与用户需求的偏离失效发生可能性的度量常用指标：MTTF(平均无故障时间)系统无故障运行的平均时间MTTR(平均修复时间)系统从发生故障到维修结束之间的时间段的平均值MTBF(平均失效间隔)指系统两次故障发生时间之间的时间段的平均值可用性系统正常使用的时间占比，A=(MTBF-MTTR)/MTBF指标计算结果（以年为单位）1个9：90%(1-90%)*365=

6、36.5天2个9：99%(1-99%)*365=3.65天3个9：99.9%(1-99.9%)*365*24=8.76小时4个9：99.99%(1-99.99%)*365*24=52.6分钟5个9：99.999%(1-99.999%)*365*24*60=5.26分钟6个9：99.9999%(1-99.9999%)*365*24*60*60=32秒GB/T 11457-1995 软件工程术语软件失效机理及应对错误研发人员产生在研发过程中缺陷内置在产品中故障引起在运行时失效用户经历的在运行时避错查错容错降低质量左移可用性级别描述年不可用时长可靠性设计方法（推荐）99%基本可用87.6h重传，降级

7、，限流，冷备99.9%较高可用8.8h负载均衡，弹性伸缩，隔离，熔断，温备99.99%故障自恢复52min自愈，热备、双活99.999%高可用5min多活案例一：航天飞机飞控软件洛克希德马丁公司的航天飞机小组实现了目标：软件几乎没有错误，接近完美。软件的最后三个版本，每个版本(42万行代码)只有一个Bug。最后的11个版本一共有17个错误，同等复杂度的商业程序有5000个。航天飞机软件开发小组的流程是如此强大，不仅仅通过了SEI CMM5的认证，而且SEI的不少标准就来自于这个小组的各种实践。、软件的质量取决于软件的设计例如让航天飞机使用GPS导航，这一变化仅涉及6366行代码，占程序总量的1

8、.5%，但是相关的文档长达2500页，涵盖了各种各样的条件，分支，几乎就是伪代码了。2、两个百科全书式的数据库一个是代码历史的数据库，第二个是错误数据库，记录了软件在编写和运行时发生的每一个错误，可以追溯到近20年前。3、不止要修复错误，要修复任何引入错误的东西如果软件存在缺陷，那么编写它的方式一定存在问题案例二：排版软件TEX1973年，这部刚出到第三卷的书（计划写七卷）已被计算机界视为“神作”,1974年美国计算机学会就“迫不及待”的把计算机界的最高奖图灵奖授予高德纳。此时高德纳仅仅36岁！只靠一套还没有完成的书就获得ACM图灵奖，不但是前无古人，估计也后无来者了。然而令人大跌眼镜的是，拿

9、到图灵奖以后，高德纳宣布暂停写作，理由竟然是现有的计算机排版系统太差，破坏了书的美感！然后单枪匹马开发出了革命性的排版系统TEX,TEX至今仍是全球学术排版的不二之选。有趣的是高纳德为此还设置了奖金，谁能从TEX 发现第一个Bug，奖励2.56美元，然后每年翻一倍，5.12，10.24.事实上，当奖金达到327.68美元以后，基本上就没什么Bug报出来了。计算机程序设计的艺术面向 组织/人 的过程使用质量模型提升软件产品质量管理过程质量满足使用质量ProcessQualityInternalQualityExternalQualityQuality inuseinfluencedepends

10、oninfluencedepends oninfluencedepends on软件可靠性的过程管理模型Ruan模型软件可靠性管理软件可靠性参数与指标的确定软件可靠性分析与设计软件可靠性测试与验证软件交付与使用软件可靠性早期预计软件可靠性预计和估计软件可靠性应用评估软件需求分析阶段软件设计与实现阶段软件测试阶段软件交付与使用阶段实例化需求SFMEASFTAMFQSFMEASFTAMFQDevopsTLA+混沌测试模糊测试探索测试维测系列方法02大型通讯软件维测现状维测的基本概念易分析性：可以评估预期变更(变更产品或系统的一个或多个部分)对产品或系统的影响、诊断产品的缺陷或失效原因、识别待修改部

11、分的有效性和效率的程度。易修改性：产品或系统可以被有效地,有效率地修改，且不会引人缺陷或降低现有产品质量的程度。易测试性：能够为系统、产品或组件建立测试准则,并通过测试执行来确定测试准则是否被满足的有效性和效率的程度GB/T 25000.10-2016产品质量模型易分析性降低缺陷定位的成本易修改性降低缺陷修改的成本易测试性降低缺陷发现的成本可控制：系统提供辅助手段帮助测试工程师控制该系统的运行，实现其测试执行步骤的能力（通过打点、改变内部状态、值等手段）可观察：软件系统提供辅助手段帮助测试工程师获得充分的系统运行信息，以正确判断系统运行状态和测试执行结果的力。通讯软件维测范围和问题没有协议规范

12、需求来源多开发组织多客户规划网研网智网元A中心B中心C中心E中心D中心F中心维测模型中的挑战DataTrace&CollectAnalysis维测三要素数据域采集域 分析域外溢挑战：复杂数据场景中定位定界有效率如何提升维测数据如何统一模型大容量场景下的采集和分析性能如何保证功能知识如何统一积累维测研发过程质量如何保证。管理/管理域维测思维转型中中间层间层Metrics告警KPI/Counter（15min，小区）Raw Packet（原始报文级）泛Log（信令级，TTI级，UE级）基于单一Log，事后型，集中式运维基于Metrics事前型定界+基于Log事后型定位分析、统计的经验直接沉淀在数据

13、中1、需任务，事后型，需复现，覆盖面窄2、突发跟踪，开销大，影响业务性能3、集中上报，集中分析，后分析算力巨大1、免任务，事前型，免复现，覆盖面广2、维测算力内嵌且平缓，且输出的数据质量高3、统计型数据，大大减负数据采集和数据分析03软件可靠性与维测正向设计融合方法论为何要正向设计基于已知故障的设计基于已知故障的维测设计维测正向设计基于已知故障的设计是在开发过程中，根据已有的故障或外部失效记录，对系统进行设计，以解决已知的问题。这种方法的主要特点是对已有缺陷的记录和解决，对系统的可靠性和安全性的考虑，对系统的性能和效率的考虑等缺点：只能针对已知的故障，无法管理未知的故障，其准确性和可靠性都有一

14、定的限制。需要完整的故障信息，如果信息不完整，可能会导致准确性和可靠性受到影响。无法处理复杂的故障关系，例如多个故障之间的关联性、故障之间的依赖关系等。无法考虑不同的环境和应用场景，只能适用于特定的环境和应用场景，无法考虑不同的环境和应用场景。无法适应变化的故障模式，只能适应固定的故障模式，无法适应变化的故障模式，因此无法适应系统的不断变化反馈链路和收敛时间长维测正向设计是一种在系统设计阶段就考虑维护和测试需求的方法。它强调在系统设计过程中，依据失效模式及影响进行全面分析，以提高系统可维护性和可测试性。优点：更全面的失效分析：通过在设计阶段充分考虑系统功能之间的关系，以及功能失效之后的影响，可

15、以更全面考虑维测风险。提高系统可维护性：在设计阶段即考虑维护需求，如合理的模块划分、清晰的接口设计等考虑，可降低维护的复杂性和成本。提高系统可测试性：可使系统更易于测试，从而提高测试的效率和准确性。减少故障和缺陷：可以提前发现和解决潜在的问题和缺陷，从而减少系统在运行时出现的故障和失效。提高开发效率：可减少后续的修改和调试工作，从而节省开发时间和资源。提高维护效率：当系统出现故障时，可以根据失效模式迅速定位故障点，并进行诊断和排除，有助于开发团队快速确定导致故障的原因，减少故障诊断的时间和精力VS方法论调研及分析SFMEA：软件失效模式和影响分析（SFMEA Software Failure

16、Mode and Effects Analysis），用于分析软件系统中每一个模块、组件所有可能产生的故障模式及其对软件系统造成所有可能影响的一种归纳方法；缺点：SFMEA 是一种自底向上的定性的单因素失效分析方法，它基于已知系统的结构和功能，分析的工作量巨大，需要找到合适的层次和重点。SFTA 是软件故障树分析（SFTA，software faulttree analysis），用于表明软件中哪些模块的故障、外部事件或者他们的组合导致软件发生故障的逻辑图。缺点：SFTA 是一种自顶向下依照树状结构从上向下推导出故障原因的方法，在选取顶事件时，可能考虑不周全，存在遗漏的情况。SFTA 在分析故

17、障原因时也会有所遗漏，这会影响底事件的严酷度排序，从而影响实施改进措施时对轻重缓急的判断。解决的方案：综合两种技术，SFMEA+SFTA 正向综合，并和测试验证相结合的；将关键的、有重大影响的事件作为顶事件进行分析。SFMEA典型过程：1、建立失效模式库；2、确定软件约定层次；3、建立SFMEA工作表。SFTA典型过程：1、确定最顶事件；2、分析逻辑关系。软件测试典型过程：1、系统测试；2、集成测试；3、单元测试。三种方法论之间的关系1、失效模式对应SFTA 的中间事件，中间事件的分析又可详细的体现在集成测试和配置测试中。2、应用SFTA 的基本事件，可以容易地确定SFMEA 中的失效原因，基

18、本事件又是单元测试的主要对象。3、SFTA的顶事件，可以明确SFMEA 中的失效影响，且可作为系统测试中判断失效的重要依据。4、GJB-Z 1391-2006 故障模式影响及危害性分析指南给出明确的评分准则，评分等级10-1。引用：基于SFMEA和SFTA的软件测试 顶事件=失效影响=系统测试中间事件=失效模式=集成测试基本事件=失效原因=单元测试 顶事件=失效影响=系统测试中间事件=失效模式=集成测试基本事件=失效原因=单元测试案例说明2顶事件=失效影响中间事件=失效模式底事件=基本模式34红线：贯穿图表的线索蓝线：中间事件绿线：底事件1失效模式库系统级软件失效模式参考标准IEEE“Stan

19、dard to Classifcation for Software Anomalies 93”标准(1)操作系统挂起(2)程序挂起(3)程序失败：程序不能自启动；程序运行不能终止；程序不能退出(4)输人问题：错误输入被接受；正确输入被拒绝；描述不正确或遗漏，参数不正确或遗漏(5)输出问题：错误的格式；不正确的结果或数据；不完全或遗漏;拼写问题、语法问题(6)未达到要求的性能(7)发现的整个产品失败(8)系统错误信息(9)其他:程序运行改变了系统配置参数；程序运行改变了其他程序的数据；其他。GJB/Z 13912006故障模式、影响及危害性分析指南 本地化维测正向设计五步法微软雅黑字体，行间距

20、1.5，字号12.微软雅黑字体，行间距1.5，字号12。维测正向设计微软雅黑字体，行间距1.5，字号12。Step1 需求分析描述用户、目的、场景、系统交互，建立物理视图、逻辑视图和时序图等，确定高层需求Step2 功能分析功能分解，建立功能关系表，确定分析层次和分析项。Step3 失效分析确定失效模式，分析失效影响；选定顶事件，分析逻辑关系，建立SFMEA和SFTA。Step4 风险分析确定优先级 RPN=严重度S*发生频率O*探测度D。Step5 维测举措及落地基于LOG标准化制定记录、解决、自愈等综合措施，并根据举措执行设计和TCO。1、需求分析1 定系统2 找用户3 问目的4 画场景5

21、 设功能 澄清需求 确定结构 划出边界 确定用户 寻找干系人 三个层级 两大方向 三大维度 目的-场景 需求补充 映射关系 主要架构实例化需求分析方法场景库功能树需求体系化i=1n需求A场景1场景2场景N.流程A流程A流程C流程X功能A功能B.功能X2、功能分析结构分析一般从整系统的物理视图开始，再打开到所有部件的逻辑视图逻辑视图中一般只展示重要、关键的部件或者模块按照树状结构逐层绘制结构树结构分析功能分析将需求分析输出的功能作为输入，并识别功能间的依赖关系将功能关联到结构树中的系统要素将性能要求或特性与功能关联逐层细化3、失效分析软件失效影响：失效影响定义为失效模式产生的后果失效影响描述的是

22、对下一级产品集成的影响（内部或外部），对操作系统的最终用户的影响（外部），以及对适用的政府规章的影响（法规）失效影响的严重度按照10分制进行评级软件失效原因：失效原因是指失效模式发生的原因失效原因造成的后果是失效模式应尽可能识别每种失效模式的所有潜在原因，失效原因可能源自于下一较低级别的功能失效模式4、风险分析RPN=S*O*Dn 严重度（S）：代表失效后果的严重程度n 发生度（O）：表示失效发生频率n 探测度（D）：表示失效原因/模式可探测的程度n S、O、D的评估等级分别分为1-10个等级，其中等级10的风险贡献最高。n 通过分别检查S、O、D的评级和三者的组合，可以得到对风险因素采取降低

23、风险行动的优先排序。GJB/Z 13912006故障模式、影响及危害性分析指南 软件严重度评估等级软件发生度评估等级软件探测度评估等级本地化5、维测举措及落地维测TCO1.设计思路2.设计原理3.模块设计4.协作流程5.类设计6.数据定义维测详细设计设计要求维测正向设计过程模型持续规划持续开发持续部署与发布持续运维持续反馈需求分析维测需求实例化分析MFQ分析系统设计功能分析失效分析风险分析故障树分析MFQ分析详细设计维测方案设计LOG方案设计维测测试用例设计TCO设计软件开发维测功能开发SFMEA SFTA设计用例开发持续集成维测测试维测功能验证部署运维产品发布现场部署运维及反馈度量、流程建设

24、维测正向设计维测正向设计贯穿软件开发生命周期的 需求、设计、开发、测试环节。阶段：维测设计开发阶段；活动：各阶段需要开展的维测设计活动；标准和能力规范和模板设计规范 设计指南 设计指导书 成熟度模型 工作输出模板技术与知识库失效模式知识库LOG标准化典型场景案例工具和系统SFMEA系统SFTA系统智能运维系统组织和能力BA TS DEV 培训课程04大型通讯软件维测正向设计实践与收益维测正向设计实践32系统建模-时序图方式进行建模功能分析功能分析-从交互模块的视角对系统的业务模型进行描述，波及组件（紫色）从交互模块的视角对系统的业务模型进行描述，波及组件（紫色）功能分析：确定分析项：组件交互信

25、息信令消息为载体系统建模-DU处理失效分析-失效模式失效分析-失效影响风险分析&维测措施-标准化设计（MTL）维测措施-详细设计维测TCO 维测正向设计度量体系33序号HPPD优先级大类度量指标指标定义公式备注1需求分析L1设计需求维测设计覆盖率需求中按照维测正向设计的过程模型进行正向设计的完成情况完成维测设计的需求个数/需求总数2方案设计L1设计特性维测设计覆盖率特性中按照维测正向设计的过程模型进行正向设计的完成情况完成维测设计的特性个数/特性总数3详细设计L2设计失效模式数维测正向设计中发现的失效模式（类型）的个数失效模式个数观察性，无期望趋势4需求开发L2审查设计审查（需求/特性）发现的

26、缺陷数针对系统维测设计审查发现的安全缺陷数设计审查发现的缺陷数观察性，无期望趋势5维测测试L1测试维测用例个数用例库中维测用例的个数维测用例个数6维测测试L2测试维测用例占比用例库库中维测用例占全体用例的比例维测用例/用例全集7维测测试L2测试维测用例自动化率维测用例中实现自动化的用例自动化的维测用例/维测用例全集8产品交付L1交付维测故障数交付后发现的维测类故障数维测故障个数9产品交付L1交付维测故障占比交付后发现的故障中维测类故障占比 维测故障/泄露故障总数需求维测设计覆盖率维测用例自动化率维测正向设计收益34定界有效率Metrics建设05总结与展望维测正向设计思考3636功能的因果关系是失效的因果关系等效；失效的因果关系来源于功能的因果关系；依赖关系的数字化；Tracing是数据的链接纽带（Metrics，Logging）Tracing本身也一种数据将关联关系 数字化Metrics感谢聆听关注QECon公众号