趁著這被人掃地出門(mén)，無(wú)地可去的日子，多學(xué)習(xí)學(xué)習(xí)別人的理論知識(shí)。
書(shū)籍名 《Site Reliability Engineering》網(wǎng)絡(luò)運(yùn)維工程，編者Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy
第二部分 規(guī)則（Principles）
第四章 Service Level Objects
如果你不知道哪些行為對(duì)服務(wù)有關(guān)鍵影響（無(wú)論積極還是消極），那么你就不可能正確地去管理好這個(gè)應(yīng)用。那么為了衡量行為的程度，我們的服務(wù)需要一些指標(biāo)，如果有人調(diào)用我們的服務(wù)，那他們也應(yīng)該熟悉這些指標(biāo)。
這里我的理解是，比如別人調(diào)用我的接口去操作一臺(tái)網(wǎng)絡(luò)設(shè)備，執(zhí)行了某個(gè)命令。這就是一個(gè)行為，但是我們對(duì)于這個(gè)行為，應(yīng)該有一些具體的數(shù)字進(jìn)行描述
谷歌SRE在這里定義了三個(gè)名詞，分別是：
SLIs、SLOs、SLAs，這里SL是 srvice level,服務(wù)級(jí)別，而I O A分別是 indicator、object與agreement
這些名詞和指標(biāo)建模、選擇、分析息息相關(guān)。（這里的指標(biāo)，就是metric，就是我們現(xiàn)在監(jiān)控系統(tǒng)所采集的對(duì)象），SRE中有個(gè)原則是“簡(jiǎn)單”，所以在監(jiān)控系統(tǒng)中選擇要關(guān)注哪些指標(biāo)是非常重要的，我們既需要這些指標(biāo)能比較全面、客觀地反饋服務(wù)的狀況，又必須盡可能壓縮監(jiān)控指標(biāo)的數(shù)目（特別接觸了對(duì)幾千臺(tái)物理設(shè)備的監(jiān)控系統(tǒng)后，我深有體會(huì)，每多一個(gè)指標(biāo)，在生產(chǎn)環(huán)境是需要multiply幾千的）
SLI就是服務(wù)狀況體現(xiàn)最直觀的數(shù)字，比如：
request latency 請(qǐng)求延遲（提一嘴，latency這個(gè)常見(jiàn)指標(biāo)，很多時(shí)候是從服務(wù)端測(cè)獲取到的，其實(shí)不見(jiàn)得能反應(yīng)服務(wù)的真實(shí)延遲狀況）
error rate 錯(cuò)誤率（SRE說(shuō)，別只統(tǒng)計(jì)成功的request數(shù)）
system throughput（這個(gè)有點(diǎn)意思，按照字面意思，是系統(tǒng)生產(chǎn)力。如果目前系統(tǒng)在服務(wù)1000個(gè)人，能說(shuō)系統(tǒng)的生產(chǎn)力很高嗎？或許但不一定，因?yàn)楹芸赡茈m然在服務(wù)1000個(gè)人，創(chuàng)建了2000個(gè)連接，但卻沒(méi)做什么事情。而如果從反饋數(shù)據(jù)的帶寬，是否比前面的連接數(shù)更能說(shuō)明系統(tǒng)的“生產(chǎn)力”呢？）
當(dāng)然還有一種SLI對(duì)于SRE很重要，那就是 n個(gè)9 的服務(wù)可用性
SLO
SLO是一組值的范圍，這個(gè)值就是由SLI定義的服務(wù)級(jí)別數(shù)值。自然的SLO定義就是，某SLI在正常情況下需要小于某值或者處于某個(gè)大小值之間。
選擇一個(gè)合適的SLO并不是一件容易的事情，當(dāng)然你并不需要一開(kāi)始就設(shè)定好這個(gè)范圍，比如說(shuō)QPS，這個(gè)指標(biāo)取決于你的用戶，而你是無(wú)法預(yù)先做出判斷的。（比如運(yùn)維平臺(tái)上線了某個(gè)服務(wù)，你可能預(yù)測(cè)這服務(wù)最后每天的使用量能達(dá)到100次，但實(shí)際并沒(méi)人用，因?yàn)榭赡苡脩舳疾恢烙羞@么一項(xiàng)功能）
確定一個(gè)SLO，和服務(wù)怎樣運(yùn)行也有關(guān)系（how service to perform）
SLA
服務(wù)級(jí)別的協(xié)議，可能是明確的協(xié)議，也可能是不明確的（implicit，比如約定俗成的、沒(méi)有紙面協(xié)定）
這種協(xié)定可能是，如果服務(wù)失效、或者達(dá)不到預(yù)期的效果，該怎樣做。一般是賠償、退款，當(dāng)然也有其他形式。一般來(lái)說(shuō)，SRE是不參與SLA的制定，因?yàn)镾LA更靠近商務(wù)層面或者產(chǎn)品設(shè)計(jì)層面。
比如谷歌搜素這項(xiàng)服務(wù)，并沒(méi)有暴露給用戶的SLI，但是卻有和全世界都簽訂協(xié)議，也就是SLA。（你注冊(cè)谷歌賬號(hào)時(shí)，一大堆的文字）
SLI實(shí)踐
了解你的用戶關(guān)心什么
你不需要把監(jiān)控系統(tǒng)中每個(gè)metric都視為SLI，選擇盡可能少的SLI，但這些SLI卻能說(shuō)明服務(wù)是否健康。這些SLI應(yīng)該：
用戶側(cè)系統(tǒng)（user-facing serving systems）：可用性（a）延遲（latency）服務(wù)生產(chǎn)力（throughput）。換句話說(shuō)：服務(wù)能響應(yīng)用戶的請(qǐng)求嗎？響應(yīng)要耗時(shí)多久？我們能處理多少請(qǐng)求？（個(gè)人心得：很多時(shí)候，我們喜歡在監(jiān)控系統(tǒng)的dashboard上把a(bǔ)gent獲取到的數(shù)據(jù)全都擺上去，看起來(lái)很高大上，但卻連服務(wù)“能”處理多少請(qǐng)求都無(wú)法了解，這里能處理多少請(qǐng)求從另外一個(gè)角度講就是服務(wù)的飽和度）
存儲(chǔ)系統(tǒng)（storage systems）：延遲，可用性和持久性。換句話說(shuō)：成功寫(xiě)數(shù)據(jù)需要多久？是否能正確獲取到想要的數(shù)據(jù)？當(dāng)我們需要這個(gè)數(shù)據(jù)時(shí)它是否還在那兒（這應(yīng)該指的是緩存）
大數(shù)據(jù)系統(tǒng)（big data systems）：對(duì)于數(shù)據(jù)處理管道（data processing pipeline），就需要去關(guān)注生產(chǎn)力與端對(duì)端的延遲（end-to-end latency）換句話說(shuō)：有多少數(shù)據(jù)被處理？從獲取數(shù)據(jù)到處理完成耗時(shí)多少？
對(duì)于所有系統(tǒng)，還需要關(guān)注正確度（correctness）：服務(wù)返回的是否是正確的數(shù)據(jù)？正確度是關(guān)注服務(wù)健康的重要的SLI
收集indicators
我們絕大多數(shù)情況都是從服務(wù)側(cè)收集的，比如使用borgmon或prometheus，但是我們也應(yīng)該關(guān)注用戶側(cè)的指標(biāo)收集。
