什麼是穩定
百度百科關於穩定的定義：
“穩恆固定；沒有變動。”
很明顯這裡的“穩定”是相對的，通常會有參照物，例如 A 車和 B 車保持相同速度同方向行駛，達到相對平衡相對穩定的狀態。
那麼軟體質量的穩定是指什麼呢？
假設軟體系統是輛車，質量預期是滿足客戶行駛要求，那麼功能是指能正常行駛，效能是指按一定速度和油耗正常行駛，穩定是指平穩且持續的按一定速度和油耗正常行駛，這種穩定狀態並不是質量本身的特性，而是質量表現的態勢。
但在行駛中，車輛本身質量和路況不是一成不變的，輪胎磨損、剎車磨損、路面結冰、路口堵車、高峰限號等等各種狀況都會影響行駛，那麼此處的“平穩且持續”可以分解為質量本身的穩定及質量表現的穩定（駕駛者感受到的穩定）。
科幻電影常常可以看到這種操作：帥氣的飆車中，男主車胎突然被打爆，車輛立刻變形，四胎變三胎，或者從機器觸手中撈出備胎，凌空替換破損胎；一番操作炫酷絲滑，男主依然狂飆，刺激效果 upup，觀眾直呼給力給力。該電影場景體現了兩點：產品本身質量好是硬道理（比如飆車那麼久剎車依然靈敏），但是突發情況更需要有其他手段維持帥氣（比如引入各種高科技手段）。
什麼是穩定性
GB/T 16260 描述穩定性如下：
“軟體避免由於軟體修改而造成意外結果的能力。”
軟考高階《系統架構設計師》描述穩定性如下：
“軟體穩定性，指軟體在一個執行週期內、在一定的壓力條件下，軟體的出錯機率、效能劣化趨勢等，並觀察其執行環境內的應用伺服器、資料庫伺服器等系統的穩定性。”
2022 年 6 月由中國信通院釋出的《分散式系統穩定性建設指南》描述穩定性：
“系統穩定性表示系統在遭受外界擾動偏離原來的平衡狀態，而在擾動消失後系統自身仍有能力恢復到原來平衡狀態的一種頑性。”
百度百科描述穩定性如下：
“系統穩定性是指系統要素在外界影響下表現出的某種穩定狀態。”
綜合各方觀點可以得到：系統穩定性關注的是系統隨時間延續、軟體修改、外界變化的關係，強調不受系統要素變更和外界擾動影響的能力。
這是一個比較泛的概念，那麼如何提升這種能力呢？我們嘗試從定義中的幾個關鍵詞入手：
系統要素
系統要素的定義：
“系統要素是構成系統的基本組成部分或基本單元。”
系統研發過程既是生產軟體系統的過程，也是製造問題（缺陷）的過程，過程質量也是影響穩定性的因素之一。
• 2022 年 4 月 Atlassian 出現當機事故，原因是團隊之間存在“溝通鴻溝”、系統警告不足；
• 2022 年 8 月谷歌搜尋和谷歌地圖出現當機事故，原因是軟體更新出錯；
系統內部風險需要儘量在軟體生產過程中避免，將製造風險的過程轉變為控制風險的過程。
外界擾動
外界擾動指非系統本身帶來的變化，往往不受系統控制，例如城市地震、機房電纜被挖、駭客 DDOS 攻擊，這種不可抗力事件雖然小機率，但世界範圍內隨時都在發生，我們能做的是儘量提高抵禦外界擾動的能力，減少對系統穩定性的摧殘。
• 2022 年 6 月微軟出現當機事故，原因是微軟的冗餘電力系統的元件產生了意外的電氣瞬變，導致空氣處理單元（ahu）檢測到潛在的故障，因此自動關閉；
• 2022 年 7 月甲骨文（Oracle）出現訪問延遲，原因是創紀錄的夏季高溫導致冷卻系統出現故障，資料中心的溫度攀升，計算基礎設施的一部分進入保護性關閉狀態；
• 2022 年 7 月亞馬遜的 EC2 例項癱瘓，原因是亞馬遜網路服務（AWS）可用區 1 (AZ1)發生停電，導致服務中斷；
穩定狀態
上文提到穩定是一種相對的狀態，因此更關注基於預期的結果對比和基於質量基線的趨勢對比。
1）確定基線
最新版的國家標準 GB/T 25000.10-2016 將軟體系統的使用質量拆分為以下影響途徑：
每個階段的質量都有對應的測量指標，例如產品質量的 8 個特性如下：
目前業內較為常見的 SLA/SLO 系列指標屬於使用質量的評估維度，體現軟體系統對其利益相關方的影響；MTTR 是產品質量可靠性的重要評估指標，體現軟體系統恢復到正常情況所花費的全部時間。
透過質量指標的拆解也可以看出為什麼我們常說的是穩定性質量保障，而不是可用性質量保障、可靠性質量保障等等，顯然穩定性視角覆蓋到的是更全面的維度。
2）確定預期
不同產品/系統/元件的質量指標預期值可能各有不同，沒有標準答案，但“使用者期望什麼樣的質量水平”一定是所有產品都重點考慮的必要標準。
什麼是質量保障
• 質量：產品/服務固有特性滿足使用者要求的程度。
• 質量保障：Quality assurance，官方譯為“質量保證”，日常更多稱“質量保障”，縮寫是 QA。
質量保障、質量控制、測試的區別
• 質量保障（Quality Assurance）：指為使人們確信產品/服務能滿足質量要求而在質量管理體系中實施並根據需要進行證實的全部有計劃和有系統的活動；
• 質量控制（Quality Control）：
為使產品或服務達到質量要求而採取的技術措施和管理措施方面的活動；
• 測試（Testing）：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程；
這三種活動過程的目的都是交付符合質量的軟體，在專案中的實施範圍從大到小是質量保障>質量控制>測試。
與質量控制和測試相比，質量保障更關注“預防”，通常透過“測試左移”和“測試右移”將測試活動構建於整個業務流程過程中，預防為主，防治結合。
質量控制關注產品結果本身，驗證其是否達到預期要求並給出改進建議，包括需求確認、產品測試等操作。質量控制的概念早於 QA 形成至少 10 年以上。測試是質量控制的最後一道關卡，是驗證質量的手段。
為什麼要做質量保障
質量控制和測試對產品結果的驗證，但是實際專案中，只重視產品結果往往為時過晚，想要修復產品初期的問題，需要投入更多的時間和人力成本。
那麼控制問題的產生、控制問題帶來的影響，是產品研發效能提升的關鍵。質量保障應運而生。
什麼是質量保障體系
• 體系：泛指一定範圍內或同類的事物按照一定的秩序和內部聯絡組合而成的整體，是不同系統組成的系統。
• 質量保障體系（質量保證體系）：透過一定的制度、規章、方法、程式和機構等把質量保障活動加以系統化、標準化及制度化。
質量保證體系的執行應以質量計劃為主線，以過程管理為重心，按 PDCA 迴圈進行，透過計劃（Plan）—實施（Do）—檢查（Check）—處理（Action）的管理迴圈步驟展開控制，提高保證水平。
體系不是一天兩天建成的，更不建議為了建設而建設，一定是先有質量需求，開展了質量保障活動，逐步完善活動過程形成體系並逐步最佳化。
例如 google 定義的 SRE，SRE 不僅僅是職位的名稱，更是一套迭代了接近 20 年的體系，覆蓋了延遲最佳化、效能最佳化、效率最佳化、變更管理，監控、應急響應、容量規劃與管理等等多個方面，非常值得借鑑和學習。但任何外來體系在本土化的過程中都需要經過篩選、調整、消化，如果直接生搬硬套，大機率會水土不服、事倍功半。
穩定性質量保障建設方向
透過前幾章的概念拆解，我們對“穩定性質量保障“說法的由來有了一定了解，那麼穩定性質量保障活動在產品專案中如何開展呢？此處僅從上文概念拆解的角度來看，整體圍繞以下幾個方向：
自身健壯-Design for failure
1）提高自身穩定
關注所有與軟體生命週期有關的因素，包括但不限於：
• 人：如何規避人為因素產生的負面影響；
• 流程：如何規避流程缺失或腐化的負面影響；
• 技術：如何規避技術缺陷引起的風險；
• 元件/系統：如何規避內部元件關係，或系統架構的潛在風險；
• 變更：如何規避以上所有因素的變更帶來的風險；
2）防禦外界擾動
常見的外界影響包括：基礎設施問題、外部依賴問題、使用者異常操作等。需要針對不同的外部影響、影響範圍、影響階段制定不同的策略。
及時發現-Multiplex monitor
1）質量影響途徑維度
質量影響途徑維度更多關注質量內的健康狀態。從第二章的質量途徑圖示中可以看到使用質量依賴軟體生命週期中的過程質量和產品質量，過程質量的監控和評價有利於產品質量改進，產品質量的監控和評價有利於改進使用質量；同樣，評價使用質量可以為改進產品提供反饋，而評價產品可以為改進過程提供反饋。
GB/T 25000 系列已對各維度的質量評價指標做了詳細說明，例如可靠性最常見的評估指標 MTBF/MTTR，本文不再贅述。
2）使用者訪問鏈路維度
使用者訪問鏈路維度更多關注系統組成要素在生產環境中的健康狀態，經典的監控體系分層包括：
• 使用者體驗層：
頁面響應時間、渲染時間、業務指標等；
• 應用服務層：
服務可用性包括服務狀態、Four Golden Signals（錯誤、流量、延遲、飽和度）、呼叫鏈路等；
• 元件層：
系統軟體、中介軟體、資料庫等；
• 主機層：
硬體、虛擬機器、容器等；
• 基礎設施層：
機房、網路等；
快速解決-Emergency response
在任何生產或質量保障活動中成本都是必須考慮的事情，權衡取捨之後，永不失敗、100% 穩定可靠的服務不可能存在，那麼問題出現後如何快速解決是提高使用者使用質量的關鍵。
Things break; that’s life。
• 快速定位：精準定位故障點；
• 快速決策：精準選擇解決方案；
• 快速執行：快速並有效執行；
這三個方向主要做了兩件事：降低問題發生機率和降低問題發生後的影響，對標信通院總結的穩定性建設目標是“降發生“和”降影響“，對標 GB/T25000 質量指標是提高 MTBF、減低 MTTR。
雲商穩定性保障建設歷程
穩定性質量保障在雲商落地的過程中經歷瞭如下幾個階段：
階段1：質量控制
重心在測試執行，透過在測試階段的活動發現軟體問題推動質量改進。
階段2：質量內建
重心在透過流程卡點、架構改造等一系列最佳化動作提高 MTBF，該階段的思路已逐漸向質量保障靠攏，但缺乏“質量右移“視角 。
階段3：風險防控
該階段從軟體生命週期維度將“風險”到“故障”的過程劃分為風險產生的階段、問題暴露階段和故障損失階段，並認為不管故障有沒有帶來具體的使用者損失，只要在生產環境中被發現都屬於損失。
重心在多維度巡檢和報警，但缺少有效的跟進和管理手段。
階段4：故障管理
該階段的思路是從故障閉環角度入手，從時間維度分故障前、故障中、故障後，粗力度劃分如下，細分項較多，此處不再展開。
因前幾個階段在預防、發現、覆盤方面發力，已基本滿足“自身健壯”和“及時發現”，第四階段的建設重心在補齊“快速解決”的短板，提高故障定位和故障恢復的速度，降低 MTTR。
按時間順序，MTTR 一般拆分為四個指標：
• MTTI（Mean time to identify )：定義為識別服務或元件問題所需的平均時間，有時被稱為平均檢測時間或 MTTD；
• MTTK（Mean Time To Know）：定義為找出問題發生原因所需的平均時間；
• MTTF（Mean Time To Fix）：定義為解決問題所需的平均時間；
• MTTV（Mean Time To Verify）：定義為驗證問題所需的平均時間；
在實際故障中發現，MTTK 和 MTTF 佔用 MTTR 的更多時間消耗。
• MTTK-故障定位
透過“工具賦能”提高問題聚焦能力，透過“人員能力提升”補齊工具覆蓋不到的路徑。
1）工具賦能：藉助健全的運維繫統能力提高效率，包括指標監控平臺、日誌平臺、分散式追蹤平臺等，重心在可觀測性平臺的建設；
2）人員能力提升：工具能定位到的路徑之外，需要人工能力補齊，重心在透過實操演練等途徑提升人員排查定位故障的能力；
• MTTF-故障恢復
透過提前預案、快恢平臺、應急流程的建設，助力恢復操作迅速、有序地開展，控制和防止故障進一步惡化。
1）應急預案：針對可能發生的事故預先制定的行動方案，並週期性演練驗證保鮮；
2）快恢平臺：將預案執行手段沉澱到平臺中，縮短執行路徑，並結合可觀測平臺做自動決策、自動執行，實現故障快速自愈；
3）應急流程：故障恢復過程中免不了多人、多部門的協作，將流程規範化並達成共識，助力大家緊密協作，有條不紊地推進故障恢復；
經過幾年建設和迭代，雲商穩定性質量保障建設體系已基本成型，下面是體系建設全景圖，供讀者參考。
結語
本文嘗試從概念詮釋的角度解讀穩定性質量保障的由來以及建設方向，未對具體的落地措施做展開描述，如有進一步瞭解的需求，歡迎交流。