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公眾號