量化互聯網產品可用性的方法論有很多，基于數量的Success-Ratio、基于目標的Error-Budget、基于故障時間的MTTR/MTTF、基于規則閾值的SLA/SLO、基于狀態的Up/Down、等等，還有一個比較新穎的指標：基于用戶時間的User-Uptime（及其派生出的Windowed User-Uptime）。只要需求不斷，指標家族就會不斷有新成員加入。

1. 好久沒理論創新了

任何互聯網產品如果不能對外持續提供穩定服務，必將損失用戶信心、口碑和商業利益。為了保障產品可用性和系統穩定性，產品的技術團隊會不遺余力地做兩件事：

“improving availability”：提升系統穩定性，如優化代碼和系統架構，力求提供高質量的代碼制品和高性能高可用的運行環境；?

“quantifying availability”：量化系統穩定性，如統計成功率、請求延遲等指標，力求能一目了然地回答“我的產品掛了沒有”、“一個月掛多久”等問題，也方便對外做出商業化SLA承諾“請您放心，我的產品一個月最多只掛這么久！”（尤其付費云服務）

第一塊improving工作大家討論得很多，也做了很多事，今天我們重點討論第二塊quantifying。對于量化產品可用性，業界有很多成熟方法論： 基于數量的Success-Ratio 基于目標的Error-Budget 基于故障時間的MTTR/MTTF 基于規則閾值的SLA/SLO 基于狀態的Uptime/Downtime …… 只需對系統數據實施采集、計算分析、可視化展示和異常報警，對絕大多數互聯網產品而言，這便足夠了。但是，上述這些指標真的就夠了嗎？當一個大型產品的用戶場景足夠復雜，維護團隊會不會在止血完一次線上事故之后，望著眼前綠色的請求成功率曲線圖，心中嘀咕一句“怎么請求成功率還是那么高，根本就體現不出有一批用戶登錄失敗”，旋即埋頭回到這次事故的善后和復盤工作去了。對于量化產品可用性這塊工作，罕見有團隊去創新理論。本文將回顧一下以前常用的量化指標的原理及其優缺點，并分享Google G Suite團隊（負責Gmail郵箱服務、Drive云存儲服務、Chat及時聊天服務、Calendar日歷服務、Doc在線文檔服務、等產品，后改名叫Google Workspace團隊）的一次全新探索，他們提出了一個新指標叫User-Uptime（及其派生出的Windowed User-Uptime）。致力于系統穩定性建設的童鞋，強烈推薦閱讀這篇Google paper原文《Meaningful Availability》（鏈接地址見文章結尾“參考資料”段落）。

2. 經典的量化指標先簡單回顧和總結一下這些常用指標的原理和優缺點。

2.1?請求成功率Success-Ratio 定義：

指一段時間內（如一天、一周、一個月）成功請求的數量除以全部請求總數量，success-ratio=successful request count÷total request count。是失敗率的反義。?

優點：原理簡單，說服力強，易統計。?

缺點： 二義性。產品在同一時間統計到的請求成功率只有一個結果（如98%），但不同人卻會有不同的感知和解讀。典型情況就是高頻請求用戶和普通用戶，前者發出98個請求失敗了1個，后者可能發出了1個請求就失敗了1個（對他們來說失敗率是100%）。而對系統整體而言，收到了100個請求失敗了2個，成功率計算結果確實是98%無誤。?

結果虛高。一類用戶在發現產品故障后會選擇離開一會（不想坐在那里不停重試），失敗請求的數量少下去，公式計算出來的成功率百分比會偏高（分子不變，分母變小，商變大），無法準確反映對用戶的影響程度。?

2.2?系統故障率Incident-Ratio 定義：

指一段時間內系統正常時間除以總時間，incident-ratio=up minutes÷total minutes。“up”和“down”取決于系統已知的線上系統故障。?

優點：直觀，說服力中等。?

缺點： 二義性。何謂up何謂down，需要去定義，則存在人為操作和解釋的空間。?

不適用于大型分布式系統。對現代化的大規模系統而言，幾乎不存在絕對的down和絕對的up，微服務拆分、多實例部署、主從熱備、異地多活等手段令得整個網站很難徹底掛，而可能只是商品評論按鈕點擊沒反應、購物車列表加載不出來、廣東某市訪問變慢、之類的“局部”異常。?

2.3 故障恢復時間MTTF/MTTR 定義：?

MTTF（Mean Time To Failure，平均失效前時間）指系統可無故障運行的平均時間（或者工作次數），越高表示系統持續服務能力越強；?

MTTR（Mean Time To Recovery，平均故障恢復前時間）指從出現故障到修復故障之間的時長（包含了確認失效和排查故障源頭等所需的時間），越短表示系統易恢復性越好；

MTBF（Mean Time Between Failures，平均故障間隔時間）指兩次相鄰故障之間的時長，MTBF=MTTF+MTTR。通常MTTR遠小于MTTF，因此MTBF≈MTTF； 此外，還有MTTD（D表示Detect，指檢測）、MTTA（A表示Acknowledge，指響應時間）、MTTI（I表示Identify，指識別和確認）、MTTK（K表示Know，指定位到根因）、MTTV（V表示Verify，指實施修復之后驗證工作所需的時間），以及MDT（Mean Down Time）、MTRS（Mean Time to Restore Service，MTRS = total downtime / # of failures）、MTBSI（Mean Time Between Service Incidents，MTBSI = MTBF + MTRS）、等一批術語，原理大體相同。?

優點：傾向于描述系統整體可用性的宏觀情況。?

缺點： 與“系統故障率Incident-Ratio”指標一樣，需要去定義故障，也僅適用于只有up/down二元狀態的系統。?

粒度粗。顧名思義，這批指標都是Mean/Average/平均值，可衡量宏觀但不適用于描述某次具體故障。?

2.4 錯誤預算Error-Budget 定義：事先給產品設定可用率目標，如系統宕機時間一個月不得大于50分鐘、用戶下單每天失敗次數不得大于1000次，這里的“50分鐘”、“1000次”就是給團隊的“預算”（最常用的量化維度是時間）。每次發生故障則相應扣除，通常用燃盡圖展示，簡稱EB。?

優點：直觀，易操作，多用作考察手段。?

缺點： 粒度粗。無法描述每次具體故障及其影響。

2.5?服務水平目標SLA/SLO/SLI 定義：?

第一步：為產品設定可用率目標（使用百分比），即Service Level Agreement（SLA），常見如一個月不低于99.99%（俗稱“4個9”）表示一個月故障時長不得大于4.3分鐘，這“4.3分鐘”便視為給團隊的“錯誤預算”（ErrorBudget，簡稱EB）；?

第二步：為產品選擇最合適的幾個黃金指標，即Service Level Indicator（SLI），最典型是Google SRE團隊推薦的4大黃金指標，分別是Latency（請求延遲）、Traffic（流量）、Errors（請求錯誤率）、Saturation（資源利用率）。此外，還有很多指標，如Accuracy（數據準確性）、Coverage（覆蓋率）、等等，詳見下表。SLI并非選得越多越多，以網易嚴選為例，因為這是一個典型的在線電商產品，我們只挑選了最適合HTTP WEB類產品的兩個指標Latency和Error去進行嚴選的SLA/SLO實踐；?

第三步：為每個黃金指標設置閾值，即Service Level Object（SLO），常見如下單請求Latency 99線不高于500毫秒（ResponseTime_99th≤500）、支付請求錯誤率不大于萬分之一（5xx_Ratio＜1?）。

第四步：持續監控這些目標是否真的達成，不能達成則自動扣除錯誤預算，直至耗光預算甚至跌至低于SLA承諾值，則將觸發用戶賠償。因為SLA是一種有法律效應的商業承諾，一旦不能達成將按協議作相應賠償，如提供消費抵價券、延長服務時長等，在各大云廠商官網都可以找到SLA承諾及賠償方案，如亞馬遜AWS SLA、阿里云ECS SLA、阿里云短信服務SLA、網易云信SLA等；?

優點： 業界通行。尤其SLA，這是廠家和用戶都認可的共同語言。?

強烈的指導意義。SLA有絕對的考察意義，團隊無法達成則將觸發懲罰性措施（如對外用戶賠償、對內績效扣分等），而EB燃盡速度也常用于控制新版本的發布變更頻率、故障演練次數。

缺點： 不易操作。整套方法論不復雜，但是概念多，易踩的坑也多。挑選哪些sli，slo閾值設置多少，sla定什么周期幾個9，都需評審，需聯合多團隊（負責人+研發+測試+運維±法務），并需要大量素材。?

研發成本。與CMDB概念一樣，業界沒有絕對標準的落地方案，每家企業都有自己一套CMDB，實施SLA/SLO/SLI也都是“本土化”建設，研發成本有大有小，質量參差不齊。黑貓白貓能抓老鼠就行。?

維護成本。不能一勞永逸，需定期展開復盤和評審，討論SLI是否增補、SLO閾值是否修改、SLO是否需要增加規則去覆蓋產品即將上線的新功能、SLA目標是否上調、以及上個月EB為什么消耗這么快等議題。

2.6 在離線狀態Uptime/Downtime 定義：統計產品正常工作或者宕機的狀態（Up/Down），以及時間長度（Uptime/Downtime），并面向用戶公開，通知渠道可以有多種，常見如郵件推送、RSS訂閱、管理后臺展示、官網展示等。?

優點：用戶友好，直觀。?

缺點：信息有限，量化不足。只知道一個產品掛了，不知道成功率是跌到99%還是80%，是全部接口都掛了還是只掛了寫操作的接口而讀操作接口正常。

2.7 歸納為兩大類可用性就是好服務在全部服務中的占比，高度抽象的公式如下：

每一種量化指標都站在不同視角去定義和描述“好”good，歸納起來其實就是兩大類：基于時間和基于數量。

2.7.1 基于時間time-based metrics“故障恢復時間”、“在離線狀態”、“服務水平目標”等指標都是基于時間維度，它們的計算公式可進一步具象為：

基于時間最大的問題在于：?

無法反映故障的嚴重程度。同樣是掛10分鐘，這10分鐘內系統功能是100%全掛還是只掛了10%；?

無法反映用戶的影響程度。同樣是掛10分鐘，夜間10分鐘和白天高峰期的10分鐘所造成的用戶影響肯定不同；?

指導性弱。僅憑“掛了10分鐘”是看不出哪里掛了；?

依賴人為判斷。對于一個大型分布式系統而言，定義純粹的二元狀態up/down是困難的，畢竟通常只掛了某個產品功能（某個微服務）而不會全掛。只影響商品評論但不影響下單支付算不算故障？影響1000個用戶才算故障還是只影響1個用戶就算？只影響廣東用戶但不影響吉林用戶算不算？上文提到的“下單請求Latency 99線不高于500毫秒（ResponseTime_99th≤500）”這條SLO規則的閾值為什么是500毫秒，而不是502毫秒？?

2.7.2 基于數量count-based metrics最典型的代表就是“請求成功率”，它的計算公式可具象為：基于數量的指標不需要任何閾值，令他看起來渾然天成，統計起來也很方便，但它也有自己的問題：?

數字對用戶意義沒那么大。一個產品的請求成功率為99%（感覺很高了），但這個產品在一天24小時里每一分鐘都要掛一掛，一個運氣很差的用戶在0點到23點之間每個小時打開產品總會遇到一兩次報錯彈窗，對這個用戶的體感來說，這個產品是掛了一整天。?

數字會被高頻用戶意外放大。高頻用戶發出的請求數量可能是普通用戶的1000倍，他們對分母和分子的貢獻非常大，很容易淹沒普通用戶的貢獻，匯總后的產品成功率有80%但可能高頻用戶全部100%成功了，而低頻用戶只有40%。?

數字會受客戶端行為影響而放大/縮小。兩個極端場景，一個是用戶看到頁面報錯彈窗后選擇不斷刷新頁面或者點擊按鈕，這些重試行為會產生大量請求，而且全都是失敗請求（此時系統還處于故障狀態尚未得到修復），進而意外地拉低成功率。另一個極端是用戶看到頁面報錯后干脆關閉離開，系統只剩下巡檢系統每1分鐘發來的一條探活請求，失敗請求數量變少，進而意外拉高成功率。?

3. 介紹一個新指標察覺到現有指標存在不足之處，Google G Suite團隊決定探索一套新指標。他們認為一個好指標必須滿足3個條件，要能體現用戶切身感受（meaningful）、數字與用戶感受是成比例相關的（proportional）、具備故障源頭指導意義（actionable），并且不需要人為設定閾值（否則太需要專家經驗，容易過于武斷，還需要長期跟蹤和調優）。

3.1 用戶可用時間user-uptime3.1.1 定義姑且先翻譯為“用戶可用時間”，計算公式如下：

先計算出每個用戶（per user）成功使用產品的時間，全部用戶加起來求和，作為分子。再計算每個用戶成功和失敗的時間之和，全部用戶加起來再求和，作為分母。二者相除的結果，就是user-uptime。

3.1.2 闡述巡檢系統，均勻地發送探針請求，每分鐘1次。success-ratio=67%, user-uptime=67%，二者相同。

某個大活人user0，不均勻地隨機發送請求，有疏有密。success-ratio=68%, user-uptime=65%，二者不同。

? ?

真實世界系統在第30分鐘~50分鐘之間發生了數據庫故障，影響到商品查詢服務和下單支付服務，但不影響小游戲、商品評論等其它功能。讓我們看看同一個故障是如何對不同用戶造成不同影響的： user0喜歡隔一會就刷新檢查某款商品是否已補貨，前面幾次都順利但突然報錯，再重試3次還是失敗，氣跑了今天不再來了； user1今天首次打開網站就撞見這次故障，他一直報錯并頻繁刷新連續報錯53次，皇天不負有心人第54次之后功能就正常了； user2與user0很像，本來開心地刷著商品列表但突然報錯，重試5次后終于恢復正常，不再報錯，還成功下單支付了； user3是個另類的用戶，他打開網站不是來買東西而是玩一款內置小游戲，小游戲功能今天一切正常沒有失敗； 請問，user0/1/2/3四人的success-ratio是多少？user-uptime是多少？系統整體的呢？這四人誰的體感更差？?

3.1.3 兩個細節挑戰

3.1.3.1 挑戰1：

判斷持續時間對同一個用戶，最簡單的情況就是兩次相鄰請求要么都成功要么都失敗，這兩次請求的間隔時間的長度就算為求和公式里的一個加數uptime(i)或者downtime(i)。但假如前一次成功后一次失敗，或者前一次失敗后一次成功，那這段時間算作uptime還是downtime呢？無非三種選擇： 在一次成功（或失敗）的請求之后，我們就假定系統會一直保持正常（或故障），直到下一次請求來到并看到相反的結果。從一次成功請求到一次失敗請求之間的時間長度視為uptime，一次失敗請求到一次成功請求之間的時間長度視為downtime； 在一次成功（或失敗）的請求之前，我們假定系統是一直保持成功（或故障），直到收到一次真實請求。一次成功請求之前的時間長度視為uptime，一次失敗請求之前的時間長度視為downtime； 把兩次結果相反的相鄰請求（一次成功一次失敗）之間的時間長度取中間值，一半視為uptime，另一半視為downtime； 這三種選擇如下圖所示，綜合來看，我們選擇第一種方案。

3.1.3.2 挑戰2：

活躍與不活躍階段如果一個用戶很久不請求（離開電腦去吃飯了，關掉手機去睡覺了），隔了幾小時或者幾天才發來下一個請求，該用戶的時間軸（提醒：在這套理論里，每個用戶是有自己的時間軸的，用戶之間的時間軸是獨立不相干的）會出現一段很長很長的綠色（或紅色）線段。在這段期間系統對他來說是down還是up呢？或者問，這段時間要算為uptime還是downtime呢？似乎都不合適。谷歌團隊引入了一個“cutoff時間”的新概念。如果一個用戶兩次請求相隔時間超過cutoff時間，這段時間忽略不用于計算uptime和downtime。一個系統可以選定自己的cutoff時長，谷歌團隊選擇的是用戶在線交互平均時間間隔的99線（the 99th percentile of the interarrival time of user requests），對Gmail而言就是30分鐘。

?

克服這兩個挑戰之后，我們就可以重新定義uptime、downtime及inactivetime：

?

我們可以說，這里的uptime是特指user-uptime，是站在用戶側看到的uptime，即對用戶來說一款互聯網產品對他而言，切切實實的正常工作時間。

3.1.4 實驗例子谷歌做了這么一個實驗，模仿用戶行為隨機地向系統發起請求，并故意制造一場持續15分鐘的故障（發生在30~45分鐘期間），以下圖為例，是其中2個用戶（user0和user1）的請求分布情況，也是他們倆人使用產品的“親身體驗”。

實驗總時間是60分鐘，系統故障時間是15分鐘（即，系統正常時間是45分鐘）。直觀來說，這個系統的可用性的期望值應該在45÷60=75%左右。那么，實驗結果是75%嗎？谷歌將這個實驗重復做數千次，并統計出請求成功率（success-ratio）和用戶可用時間（user-uptime）兩個指標的可用性正態分布圖。可以看出： 兩個指標顯示出Mean可用率分別是75.8%和74.2%，都在期望的75%左右，沒有問題。

前者的Stdev標準差是0.078，后者只有0.049，右側的柱狀圖分布更為“緊湊”。成功率會收到用戶重試行為（故障期間重試必定失敗）的影響而出現不少次實驗的可用率下降在60%左右，導致左側柱狀圖顯得更“松散”，不能有效集中在0.75綠線旁邊。

?

3.2 累積最小用戶可用時間Windowed user-uptime&MCR3.2.1 定義大多數互聯網產品會計算一個特定周期的可用性，如每天、每周、每月、每季度。如下圖，這是嚴選一個低優先級的內部服務的可用率周報表。這樣的報表可以告訴我們可用性的抖動情況，但不能告訴某次事故的影響范圍。

對穩定性管理員來說，他內心會希望擁有一張具備這樣能力的新圖表：呈現系統在過去1分鐘的可用性最高是多少，同時呈現過去5分鐘、10分鐘、1小時、24小時、7天、90天的可用性最高達到多少？谷歌團隊創新地引入了兩個新概念：

新概念1：Windowed user-uptime。 暫且翻譯為“窗口化用戶可用時間”，縮寫為WUU，先給產品選定幾個時間長度作為“window窗口”（如1分鐘/4分鐘/15分鐘/1小時/4小時/1天/1周/1月/1季度），將上一章節統計得到的“user-uptime”進一步量化，用窗口長度去平均切割過去一段時間（數日甚至數月）得到多個等長片段，計算每個片段里全體用戶的user-uptime比率，得到多個比率（百分比）并從中找出最小值min，就是這個窗口粒度的Windowed user-uptime（WUU）。

新概念2：Minimal Cumulative Ratio（MCR） 暫且翻譯為“累積最小用戶可用時間”，縮寫為MCR。將多個時間窗口按從小到大排列，將每個窗口找到的windowed user-uptime的點相連繪制呈線，這條曲線就是MCR曲線。

3.2.2 闡述windowed user-uptime的思路是找到同一時間粒度上最差的那一次可用性，并繪制成MCR曲線。谷歌其實就是借鑒了編程語言Real-time Garbage Collector理論中的Minimum-Mutator-Utilization（MMU）思路，MCR和MMU在思路和計算上完全一樣。假如我們給自己的系統繪制MCR，為描述方便只選擇過去3天的全部請求，選取的window窗口分別是1分鐘、5分鐘、15分鐘、1小時、6小時和1天一共六個。那么，計算步驟如下： 第一步，計算“1分鐘”窗口的WUU。首先，以“1分鐘”為粒度去平均切割過去3天，一共得到24×60×3=4320個片段。接著，計算片段1（3天前00:00:00至00:01:00期間）的user-uptime比率，即00:00:00至00:01:00期間的uptime除以totaltime，假設結果是99.4%（這1分鐘里系統發生了一次時間極短的小故障）。然后計算片段2（3天前00:01:00至00:02:00期間）的user-upitme比率，假設結果是100%（這1分鐘里系統沒發生任何問題，用戶請求全部成功）。以此類推，計算出片段3、片段4、直至片段4320的結果。最后，從4320個結果（4320個百分比）中找出最小值，假設是92%（在2天前10:20:00至10:21:00期間系統發生了一次嚴重故障，影響了大量用戶請求，導致這個窗口片段的user-uptime比率只剩下92%），這個92%便是“1分鐘”窗口的WUU。 第二步，計算第二個窗口“5分鐘”的WUU。過程相同，先以“5分鐘”為粒度去平均切割過去3天，一共得到(24×60×3)÷5=864個片段。接著，計算出片段1（3天前00:00:00至00:05:00期間）的user-uptime比率，以及片段2、片段3、直至片段864的結果。最后，從864個結果中找出最小值，假設是94.3%，這個94.3%便是“5分鐘”窗口的WUU。 第三步，以此類推去計算“15分鐘”、“1小時”、“6小時”、“1天”這四個窗口的WUU，假設結果分別是96%、97.2%、99.2%和99.96%。 最后一步，繪制MCR曲線圖。X軸為六個離散的時間窗口，Y軸為WUU。將6個WUU點（92%、94.3%、96%、97.2%、99.2%和99.96%）按順序打上去并連成線。這條曲線即系統的MCR。 MCR概念比較新，未接觸過這類最小值累積原理（類比GC MMU理論）的童鞋可能一下子不好理解，我們舉一張MCR圖來說下。從下圖可以直觀地看出3個信息點（常規的SLA可用率曲線圖是無法直觀呈現出這些信息的），這款產品： 整個季度的整體可用性達到99.991%（最右側末段的點）； 1分鐘最差的可用性是92%（最左側開端的點），沒有比92%表現更差的分鐘了； 拖垮系統可用性跌至92%的那次故障一共持續了約2個小時（曲線第一個拐點，它位于在1hour~4hours的中間位置），在半天以及更大時間尺度來看，系統可用性都維持在99%以上而不再出現大型故障（曲線在第一個拐點之后突然變陡，曲線斜率變大并迅猛地爬升）；?

既然系統穩定性管理員從上一張圖已經得知系統發生過一次持續近2小時的故障，從MCR圖表下鉆到更細粒度的“每分鐘可用性”詳圖便可以知道這次故障在某一天下午13:50開始發生功能異常（影響用戶請求），在15:40開始逐步恢復，到16點附近系統可用性爬升回到99.9%理想水位，整個過程持續了約2個小時。

3.2.3 MCR單調遞增谷歌在數學上證明了MCR公式的單調性（monotonicity），篇幅太長這里不贅述，證明過程詳見paper原文（5.2、5.3及尾部附錄Appendix章節）。也就是說，只要窗口是越來越大，那么MCR曲線只會越走越高，斜率取決于系統真實可用性和故障程度。但MCR曲線是不會往下走的。通俗地說，1hour的Worst Availability是不會比1分鐘的更低。由于1分鐘是包含在1小時之內的，如果1分鐘的最差可用性為99%，那這1個小時也差不到哪去，肯定不會比99%更低，而只會比99%更高至少持平。

4. 指標的關系4.1 分開來看谷歌收集了全部Google G Suite產品（Calendar、Docs、Drive、Gmail、等）在2019年度的用戶請求數據（已脫敏），并分別從用戶可用時間（user-uptime）及請求成功率（success-ratio）兩個角度去計算，向我們展示了這兩項指標的作用，以及優劣勢。如開篇所言，Google G Suite團隊原先就只有success-ratio圖表但看著總覺得哪里不夠用，指導性不夠，才會去折騰琢磨user-uptime這個新指標。好消息是，試水結果很好，沒有白折騰。

數據1：當描述系統整體可用性 可以看出，user-uptime橙線要比成功率的藍線更高一些。這背后發生了什么？繼續往下看。

數據2：當描述超高頻用戶與常規用戶 谷歌G Suite產品的用戶構成是： 99%是常規用戶，一段時間請求不多于100次。貢獻了請求總量的38%。 1%是超高頻用戶，請求頻率是普通用戶的1000倍。貢獻了請求總量的62%。 當發生系統故障（產品功能異常）時，這1%超高頻用戶會在短時間內刷出大量請求（失敗請求），而當系統正常時，這1%超高頻用戶則會刷出大量成功請求。這些數量太大，在計算success-ratio成功率時極大稀釋了另外那99%常規用戶的表現。這樣的稀釋會誤導系統的穩定性管理員，過高或過低地誤判一次故障在用戶的真實影響程度。數據3：從MCR累積角度看 X軸是不同的窗口大小，可以看到橙線和藍線形狀和斜率相似，但橙線水位更高。

無論是數據1按時間分布，抑或數據3按窗口累計分布，可以看到user-uptime橙線都要比success-ratio藍線更高一些。讓我們下鉆到每分鐘的詳圖，在這個故障發生之前（下圖最左側）和故障恢復之后（下圖最右側），橙線藍線基本吻合。但是，在故障持續期間兩條線有明顯偏差，為什么呢？進一步分析，發現是來自一批Google G Suite產品的濫用用戶（abusive users），他們使用第三方郵箱產品并設置同步Gmail郵件，但這個第三方產品功能有bug，可以同步中低數量郵件的郵箱，但無法成功同步海量郵件的郵箱，同步過程會報錯并立即重試（不斷又循環失敗下去），重試之前沒有間隔一定的休眠時間。這批濫用用戶會拉低請求成功率（success-ratio）指標，并不斷上下抖動，但由于請求失敗的只是這一小戳用戶，其余大量用戶的請求全部都成功，用戶可用時間（user-uptime）指標看上去就平穩。

?

4.2 兼容并包，各取所長從上文數據1、數據2和數據3的分析可以看出，請求成功率這個指標的最大問題在于容易受特殊用戶（超高頻用戶、濫用用戶、等）的行為干擾，而用戶可用時間這個指標則更加穩健，不易受干擾。借助上文這兩項指標的數據對比，谷歌系統管理員便可以直觀意識到有哪些極端用戶和意外場景的存在，并進一步追查和優化，如聯系第三方郵箱產品并溝通適配同步Gmail郵件的方式等。以前只有請求成功率這一張圖，管理員是不易察覺到這樣的深層次問題的存在的，可能會盯著藍線單調地起起伏伏而熟視無睹，現在有了橙線的輔助，偏差一目了然。有偏差，就意味著哪里有問題。下面左圖是把2個指標擺一起看，右圖是把2個產品擺一起看，一對比，一些隱藏問題就可以躍然紙上。

因此，這兩個指標（其它指標亦然）之間不是非黑即白的矛盾關系，而都是系統管理員武器庫中的成員，武器種類越多當然越好。而且，這些武器不是那種管理員手上拿著刀便舉不了槍的互斥關系，而是手上拿著刀頭上還戴多一副紅外夜視眼鏡的相輔相成關系，讓黑夜里數據變得更直觀，信息更透明。

4.3 已獲得銀彈和萬能鑰匙？答案是否定的。盡管新指標有諸多優點，新指標與成功率等舊指標擺在一起呈現可以給管理員提供更多信息和線索，但不意味Success-Ratio、MTTF/MTTR、SLA/SLO等舊指標就一無是處，也不意味著User-Uptime新指標就無所不能。舉個最常見的例子，某些故障令用戶請求根本就達到不了系統（域名DNS失效、機房光纖挖斷、等），這些也影響產品可用性和用戶體驗，但無論Success-Ratio還是User-Uptime都是“燈下黑，睜眼瞎”，需要其它手段。

5. 需求不斷，創新不止回顧Google G Suite團隊整個指標創新的過程，我的感覺是這樣的：回到開篇管理員的那聲嘀咕，假如你在工作中也浮現過這樣的“別扭瞬間”，說明當前的工具或者方法還不夠好，說明有創新空間在，說明自己和團隊可以抓住這個寶貴的痛點癢點進一步深挖和創造。可能今天介紹的User-Uptime新指標不一定適用于你的產品你的系統，但這個敢于創新的精神是普世的。再大的痛點也不慌，再小的癢點也不要錯過，“從0到1是創新，從1到1.1也是”，與諸君共勉。