我是非典型理科男號主。 關注後你可以收穫最硬核的知識分享， 最有趣的互聯網故事 
大家好，我是“非典型理科男”。今天跟大家聊聊穩定性建設相關的事情。
沒有穩定性，一切歸零
7月13日B站主站、App、小程序均出現訪問故障，頁面提示“正在玩命加載數據”。
B站崩了，才讓大家發現原來“小破站”的流量如此驚人。上不了網站、沒得看視頻直播的“B站難民”衝向知乎、微博以及著名遊戲網站NGA。“b站崩了”“陳睿”“豆瓣崩了”等詞迅速走紅，甚至連B站名梗“蒙古上單”也一同霸榜微博熱搜，傳遍全網，頗爲壯觀。
23時左右故障發生，直到23時45分，B站網頁端和App才初步恢復正常訪問，但像直播、會員購等板塊，以及一些站內互動、評論、投幣功能，還無法正常使用。
B站的這次事情， 在全網火了，同時也讓互聯網人意識到穩定性的重要性。毫不誇張的說，沒有穩定性，所有一些都會歸零。
穩定性定義
所謂『服務穩定性』就是用戶在使用我們的服務時，服務是可響應的、正確的、高效的。
- 可響應：app能打開、裏面的各項功能點擊後有響應；
- 正確：各種功能輸出的結果是正確的，符合預期的，比如支付的金額正確，頁面裏該有的內容和數據都有，等等；
- 高效：前面兩個都符合要求也還存在一個響應效率的問題，如果服務響應突然變慢，導致用戶放棄使用，也是穩定性出了問題；
業務發展的不同階段，使用不同的穩定保障的策略。
業務發展初期，所有人一心撲在業務幾乎不考慮穩定性的事情。
隨着業務的不斷髮展， 業務規模不斷擴大， 各類穩定性事情頻發。 這個階段， 一般由業務的同學負責穩定性相關的事情。
業務發展到了相對穩定階段之後， 由於業務規模很大，穩定時間的影響也越來越大。 甚至帶來廣泛的輿情影響， 影響公司的品牌形象。這個階段， 有會專門的團隊負責穩定性建設。
穩定性評價
穩定性評價對於穩定性建設很重要。 穩定性評價不僅可以讓團隊快速評估出目前系統穩定性現狀，而且也是穩定性團隊工作評價的一個標準。
穩定性評價悖論
如果一個系統非常穩定，體現不出穩定性團隊工作價值。 如果一個系統穩定性故障頻發，穩定性團隊沒有做出工作價值。 這似乎是一個悖論。 因此不能簡單的使用系統是否穩定的定性團隊的工作價值。 必須找到一個可度量、可觀測的指標評估系統的穩定性。
同步流程評價
同步流程可以使用可用性指標度量。也就是幾個9的穩定性。不同的可用性代表用戶可使用時長佔比。
可用性計算公式
目前業界有兩種衡量系統可用性的方式，一個是時間維度，一個是請求維度，我們先來看這兩個維度的計算公式。
時間維度 ：Availability = Uptime / (Uptime + Downtime)
請求維度：Availability = Successful request / Total request
時間維度
我們先來看時間維度的系統可用性。用一句話來概括：時長維度，是從故障角度出發對系統穩定性進行評估。
以發燒爲例子，首先要定義什麼情況算髮燒，比如體溫超過37.5，是否真正發燒還要看持續時長，偶爾一次溫度超過37.5也不能算作發燒。
從例子可以看出，時長維度評估包含三個要素：
一個是衡量指標，比如體溫就是衡量指標；
第二個是衡量目標，達到什麼目標是正常，達不到就是異常，低於37.5 度算正常，超過 37.5 度就是異常。
但是單次測量不能說明問題，我們可以多次測量， 比如 6 次中有至少 4 次低於 37.5 度纔算正常，轉化成比例的話就是 67%；
第三個是影響時長，比如持續超過 12 小時。
使用時長緯度評算只有系統故障纔會影響可用性，這個結果計算比較粗。偶爾的接口異常或者超時沒有達到故障程度不統計到不可用的範圍。
時長維度也沒有考慮高峯故障和低峯故障雖然時長一樣對用戶造成的影響，完全不同。
請求維度
請求維度，是從成功請求佔比的角度出發，對系統的穩定性進行評估。
請求維度的系統可用性同樣包含三個關鍵要素，第一個衡量指標，請求成功率；第二個衡量目標，成功率達到 95% 纔算系統運行正常；第三個是統計週期，比如一天、一週、一個月等等，我們是在一個統計週期內計算整體狀況，而不是看單次的。
異步流程
異步流程雖然不會直接影響業務指標， 但是如果處理時間過長會影響用戶體驗。
異步流程評估可以使用SLA進行評價。SLA是Service Level Agreement的縮寫， 表示服務對於用戶的承諾。 SLA主要看兩個指標：
-
SLA時長： SLA時長=請求完成時間-請求發起時間。SLA時長直接決定用戶體驗。
-
SLA完成率： SLA完成率=SLA時間內完成的量/總的請求量。 SLA完成率影響用戶滿意度。
關於穩定穩定性， 今天就寫到這了。 下一篇會詳細介紹大公司如何去做服務穩定性。
關注《非典型理科男》，技術文章不迷路。
JDK8的新特性，你知道多少？ 回覆“資料”，免費獲取 一份獨家嘔心整理的技術資料！
