SRE: How Google Runs Production Systems 讀書筆記（二）
第三章在講風險，開頭再度強調了「不該追求極端的可靠性」，我們必須考慮機會成本——可靠性的成本並非線性成長，多追求一個級別的提昇（例如 99% 提昇至 99.9%）說不定成本要提高百倍才做得到，甚至，好不容易達成後對使用者來說根本沒差
怎麼看風險？
可靠性（或者說對故障的容忍程度）是靠風險管理得出的結果。風險是一個非線性的連續體(continuum)的概念，我們要問的問題是：服務合理的風險是多少？
合理的風險更像是一個可選的區間，透過衡量「成本」、「業務風險」與「維運風險」對應後我們可以再選出一個目標值
怎麼量化風險？
故障導致的業務風險很難量化（例如媒體大肆報導導致退訂），最直接的作法是參考指標（延遲、停機時間、請求成功率等）
拿停機時間來看——可用性水準訂為 99.99%，一年當中可以接受的停機時間就是 52.56 分鐘
但對分散式服務來說，停機可能是很久才會發生一次的（較難追蹤校正），可以改用請求成功率——可用性水準訂為 99.99%，如果一天要接受 2.5 M 個請求，錯誤數量少於 250 個即可（要注意不同請求的重要性不同，直接面向使用者的請求會更重要）
可用性目標應該多久更新一次？訂定的依據是什麼？
通常以一季為單位來訂，每週或每天追蹤其變化
成本考量很重要，舉了一個很好的比較：Gmail 跟 Youtube——Gmail 定的可用性目標很高，因為如果服務中斷，會導致大量成本及嚴重後果（例如包含許多企業在內的使用者流失）；反之，為 Youtube 設定的可用性目標較低，因為快速發展更重要
可以思考下列這些問題：
- 使用者是誰？他們期望怎樣的服務水準？
- 服務是否直接關係到收入？（公司的收入或客戶的收入都算）/ 是付費還是免費？
- 競爭對手的服務水準如何？
- 多一個「9」，收益增加多少，成本增加多少？
- 服務是否為基礎設施？服務水準是否可以適用各個業務端？
如果難以訂定，可以參考「ISP 的服務錯誤率」（大約 0.01%-1%），只要可用性優於此基礎，故障就會被網際網路的噪音(noise)掩蓋掉
持續發生的零星故障 / 全網中斷哪個更糟糕？
看情況。不同故障類型不能以同樣方式來量化，要考慮不同故障會對業務端造成多大影響
同一個服務怎麼滿足不同類型的使用者？
有時服務的特性是雙面刃，書上舉了 BigTable 為例：要低延遲，利用率愈低愈好（可以更快處理），但要低成本，利用率愈高愈好（避免閒置）
我自己在使用 BigTable 也遇過這種競爭約束（competing constraints）的情況：同一個應用要服務 streaming 跟 batch 這兩種不同場景
書上提供一個解決方式：用戶隔離——低延遲使用者跟離線分析使用者分別使用不同叢集