《SRE: Google 運維解密》（1-6章）—— 讀書筆記
這幾天到杭州出差，帶了這本運維領(lǐng)域的經(jīng)典有空的時候刷一下。雖然書本概念偏多，但是可以看出是來源于實際工作中的例子，比起單講理論或者工具的書來說，對運維領(lǐng)域的工程師有頗大的指導(dǎo)意義?！?至少這本書展示了運維領(lǐng)域一些有挑戰(zhàn)性的工作，讓運維工作變得更加有趣一點。
PS. 這本書的電子英文版在可以免費在線閱讀，不過要自備梯子：
https://landing.google.com/sre
第一章 介紹
運維操作占時間限制在50%以內(nèi)
- 必要時讓研發(fā)團(tuán)隊承擔(dān)運維壓力，同時也會促進(jìn)團(tuán)隊構(gòu)建出更加自動化的系統(tǒng)。
- 研發(fā)和 SRE 共同承擔(dān)可用性的責(zé)任，（彼此就有必要了解彼此的工作了）。
追求 100% 的可用性是有害的
- 服務(wù)的 SLO 可用性在 99.999%和100%之間的差別，只是整個綜合系統(tǒng)的噪聲，對用戶沒有實質(zhì)好處。
- 追求過高的可用性帶來的成本上的增加，和時間成本上的損失，會降低業(yè)務(wù)的迭代速度。
第二章 Google 生產(chǎn)環(huán)境
- Google 的軟件服務(wù)器和物理服務(wù)器兩個概念有較大不同。我理解是盡可能地虛擬化、容器化的結(jié)果。
- 一個典型的服務(wù)的架構(gòu)，基本上每個環(huán)節(jié)（前端、DNS 服務(wù)器、負(fù)載均衡、服務(wù)后端、數(shù)據(jù)庫、磁盤）都需要高可用。
第三章 擁抱風(fēng)險
這一章主要討論了 SLO（服務(wù)可用性目標(biāo)）應(yīng)該怎么定義和怎么決定數(shù)值。
- 怎么定義
可以是按時間，也可以是按成功請求數(shù)（Google 的服務(wù)大多按請求數(shù)定義，因為基本沒有 downtime）
- 怎么決定數(shù)值
用戶期望、對收入的影響等等。還有一個是收益是否能高于成本的投入。
錯誤預(yù)算
我認(rèn)為這章最重要的一個概念是“錯誤預(yù)算”，就是一個周期內(nèi)可以允許的故障時間預(yù)期。用來平衡研發(fā)新功能和提高穩(wěn)定性的工作量之間取得平衡。在還有較多錯誤預(yù)算的前提下，可以承擔(dān)更多的風(fēng)險去發(fā)布新功能；而預(yù)算接近耗盡時，則應(yīng)該推動更多的測試和放慢發(fā)布的速度。
第四章
解釋了 SLI、SLO 和 SLA 之間的差別。
SLI：indicator，服務(wù)的某項具體量化指標(biāo)
SLO：object，服務(wù)的某個 SLI 的目標(biāo)值
SLA：agreement，服務(wù)與用戶之間的協(xié)議，描述沒有達(dá)到 SLO 之后的后果。
關(guān)于指標(biāo)，不同的指標(biāo)有不同的標(biāo)準(zhǔn)，有些對波動比較敏感的指標(biāo)，比如 CPU或延時，適合每10秒收集一次，用柱狀圖的方式來呈現(xiàn)分布。有些指標(biāo)比如內(nèi)存使用量等，則可以按分鐘取平均值。
第五章 減少瑣事
Google 將瑣事定義為重復(fù)性的、手工的勞動，特征是被動式的、沒有持久價值、與服務(wù)同步線性增長的工作。
總的來說，通過時間工單統(tǒng)計，或者 on-call 時間等計算，處理瑣事的時間不應(yīng)該超過50%，用這些時間投入到軟件工程和系統(tǒng)工程上，用于消除瑣事。
第六章 分布式系統(tǒng)的監(jiān)控
盡量的簡化，讓報警盡量接近故障的根源（通過大量白盒監(jiān)控）。
對于報警規(guī)則，可以通過審視一系列的問題來減少誤報：
- 是否可以忽略的報警？
- 是否要立即進(jìn)行某個操作？該操作能否被安全地自動化？——當(dāng)收到報警時，我應(yīng)該立即進(jìn)行某項操作。這項操作應(yīng)該需要一定的分析過程，如果每次都是機械動作，那應(yīng)該自動化掉，而不是應(yīng)該成為緊急報警。
待續(xù)……
