安安！國慶連假第二天！今天進到第三章囉！這裡是今天讀的原文出處：Embracing Risk，那我們就開始吧！

書中提到 Google 將優化系統的目標化為客觀的性能指標，以衡量系統表現，並追蹤進步或退步。對於服務風險，所有潛在因素都可能被縮減為一個指標，主要關注計劃外停機時間，因為它直接反映了風險承受能力。

計劃外停機時間的可接受水平通常由服務的預期可用性水平體現，如 99.9%、99.99% 或 99.999% 的可用性。這個指數通常是根據系統正常運行時間與停機時間的比例來計算的：

可用性 = 系統正常運行時間 / （系統正常運行時間 + 停機時間）

假設一年 365 天，預期可用性有 3 個 9（99.999%），那一年可接受的停機時間會多長呢？

1 年 = 365 （天） * 24 （小時） * 60 （分鐘） * 60 （秒） = 31536000 （秒）

31536000（秒） * （100 - 99.999）% = 315.36 （秒）

315.36（秒） / 60 = 5.256 （分鐘） → 大約 5.26 分鐘

使用上述的公式，我們可以計算出一年內可接受的停機時間，使可用性達到預期目標。 然而，對於 Google 而言，時間基礎的可用性往往無意義，因為其目標是全球範疇的分布式服務。 Google 使用故障隔離手段，確保任何時候、任何地方都能處理一定的用戶流量，即部分「在線」。因此，Google 通過請求成功率定義服務可用性，這是一個基於產量的指標，通過滾動窗口（如一天內成功請求的比率）計算得出。

可用性 = 成功請求數 / 總計請求數

這個指標比基於時間的可用性更適應於那些不直接服務於用戶的系統。具體來說，一個每天需處理 2.5M 個請求的系統，其可用性目標為 99.99% 時，只能每天出現少於 250 個錯誤。

2500000（請求數） * (100-99.99)% = 25 （請求數）

在應用中，不是所有請求都是平等的，比如新用戶註冊請求失敗與後台呼叫郵件失敗在重要程度上是不同的。然而，從用戶的角度考慮，計算所有請求的成功率可以合理地預估系統的計劃外停機時間。

通常，Google 會為一個服務設定季度的可用性目標，根據性能每周甚至每天進行追蹤，通過不斷找出、追蹤和調整重要的偏差，以使服務達到高水平的可用性目標。

後記

今天提供了兩種計算服務風險的方法，接著來看風險的容忍度，那就明天見囉！掰噗！