背景

又到一年的11.11大促日，最近很多團(tuán)隊(duì)郵件上下游確認(rèn)SLA，你是不是還沒搞明白服務(wù)質(zhì)量SLA、SLO等概念？本文通過理論知識(shí)以及基于SLO告警治理的實(shí)踐經(jīng)驗(yàn)分享。詳細(xì)介紹如何設(shè)置SLO、有效的告警泛濫治理、以及如何根據(jù)SLO的指標(biāo)來優(yōu)化服務(wù)性能和可靠性。

問題（1）

首次接觸到了SLA（服務(wù)等級協(xié)議）的概念，其中承諾的響應(yīng)時(shí)間是200毫秒。而服務(wù)接口的TP99（即99%的請求完成時(shí)間）超過了100毫秒，上游的超時(shí)配置卻是2000毫秒。這之間存在何種聯(lián)系呢？我感到有些困惑。后來在工作中逐步搞清楚了SLA的概念。

問題（2）

年初還有一個(gè)疑問一直困擾著我。例如，我負(fù)責(zé)的系統(tǒng)中的一個(gè)API接口的可用率是99.99%，那么在部門中，包含了N個(gè)系統(tǒng)和M個(gè)接口，部門的季度可用率是99.98%，這個(gè)數(shù)字又是如何計(jì)算出來的呢？統(tǒng)計(jì)的規(guī)則又是什么？我請教了XXX同學(xué)，給我解惑答疑，非常感謝！

問題（3）

比如我在XXX云購買了100臺(tái)云主機(jī)，在10:00-10:05這5分鐘內(nèi)，有10臺(tái)機(jī)器出現(xiàn)故障，導(dǎo)致API的對外可用率只有90%（在這5分鐘內(nèi)，總請求數(shù)為1萬，失敗的請求數(shù)為1000）。如果一個(gè)月30天，每天發(fā)生一次這樣的5分鐘，那么這可用率到底是多少呢？

帶著以上的這些問題，研究了服務(wù)質(zhì)量的指標(biāo)：SLI（服務(wù)水平指標(biāo)）、SLO（服務(wù)水平目標(biāo)）和SLA（服務(wù)等級協(xié)議）。如果你也對上面的問題感興趣，并且想找到答案，歡迎閱讀本文，以下是我的研究成果，供大家參考，如果有不對的地方，還請大家指正。

一、服務(wù)質(zhì)量術(shù)語

如果你不了解你負(fù)責(zé)的系統(tǒng)內(nèi)部的各種行為的重要程度，并且無法度量這些行為是否正確的話，就無法正確的去運(yùn)維系統(tǒng)，更不用說穩(wěn)定可靠的運(yùn)維了。不管是對外服務(wù)還是內(nèi)部API，都需要制定一個(gè)針對用戶的服務(wù)質(zhì)量目標(biāo)，并且努力去達(dá)到這個(gè)目標(biāo)。

在這個(gè)過程中，我們需要根據(jù)歷史經(jīng)驗(yàn)，主觀判斷以及對服務(wù)的理解來定義一些 服務(wù)質(zhì)量指標(biāo)（SLI）,服務(wù)質(zhì)量目標(biāo)（SLO)，服務(wù)質(zhì)量協(xié)議（SLA）以及這些指標(biāo)的預(yù)期值和應(yīng)對計(jì)劃。

1）服務(wù)質(zhì)量指標(biāo)SLI（Service Level Indicator）

定義：該服務(wù)的某項(xiàng)服務(wù)質(zhì)量的一個(gè)具體量化指標(biāo)

常見的SLI包括：

• 可用率（成功響應(yīng)的請求比例）
• 請求延遲的99%（TP99請求處理耗時(shí)）
• 吞吐量（每秒請求量）
• 持久性（數(shù)據(jù)能夠保存的完整時(shí)間，常用于數(shù)據(jù)存儲(chǔ)系統(tǒng)）

2）服務(wù)質(zhì)量目標(biāo)SLO（Service Level Objective）

定義：服務(wù)的某個(gè)SLI的目標(biāo)值或者目標(biāo)范圍。

SLO的定義是SLI《目標(biāo)值，或者 范圍下限《SLI《范圍上限。

設(shè)置服務(wù)水平目標(biāo)（SLO）的好處主要體現(xiàn)在以下幾個(gè)方面：

1.對于客戶端而言，SLO提供了一種可預(yù)期的服務(wù)質(zhì)量，這使得客戶端的系統(tǒng)設(shè)計(jì)可以更加簡單和穩(wěn)定。客戶可以根據(jù)SLO來規(guī)劃和調(diào)整自己的業(yè)務(wù)流程，減少不確定性帶來的影響。

2.對于服務(wù)提供者而言，SLO帶來的好處包括：

• 可預(yù)期的服務(wù)質(zhì)量：SLO可以幫助服務(wù)提供者明確服務(wù)質(zhì)量的標(biāo)準(zhǔn)和目標(biāo)，從而更好地管理和優(yōu)化服務(wù)。
• 更好的成本/收益取舍：通過設(shè)定合理的SLO，服務(wù)提供者可以在資源投入和服務(wù)質(zhì)量之間找到一個(gè)平衡點(diǎn)，實(shí)現(xiàn)更有效的資源利用和成本控制。
• 更好的風(fēng)險(xiǎn)控制：當(dāng)資源受限或出現(xiàn)故障時(shí)，SLO可以幫助服務(wù)提供者更好地控制風(fēng)險(xiǎn)，避免服務(wù)質(zhì)量下降對業(yè)務(wù)造成的影響。
• 故障時(shí)更快的反應(yīng)和采取正確措施：SLO可以作為一個(gè)參考標(biāo)準(zhǔn)，幫助服務(wù)提供者在故障發(fā)生時(shí)更快地發(fā)現(xiàn)問題并采取正確的措施，減少故障恢復(fù)時(shí)間。

選擇一個(gè)合適的SLO是非常復(fù)雜的過程，難點(diǎn)是可能無法確定一個(gè)具體的值。比如對外API，每秒查詢數(shù)量QPS指標(biāo)由用戶決定的，我們并不能針對這個(gè)指標(biāo)設(shè)置一個(gè)SLO。但是我們可以指定請求TP99時(shí)間小于20ms.確定這個(gè)目標(biāo)可以鼓勵(lì)開發(fā)者優(yōu)化代碼性能.

3）服務(wù)質(zhì)量協(xié)議SLA（Service Level Agreement）

定義：指服務(wù)和用戶之間的一個(gè)明確的，或者不明確的協(xié)議。描述了在達(dá)到或者沒有達(dá)到SLO之后的后果。這些后果可以是財(cái)務(wù)的（賠償）或者其他的。

區(qū)別SLO和SLA的一個(gè)簡單方法是問：“如果SLO沒有達(dá)到時(shí)，有什么后果？”，如果沒有定義明確的后果。那么我們肯定是在討論一個(gè)SLO，而不是SLA。

Google搜索服務(wù)是沒有公開SLA的一個(gè)典型服務(wù)。

4）云服務(wù)級別協(xié)議CSLA（Cloud Service Level Agreement）

詳見第三章節(jié)

圖片

二、SLO實(shí)踐案例

我們可以SLO實(shí)踐案例來指導(dǎo)我們的穩(wěn)定性建設(shè)。

1）服務(wù)分級&核心接口分級

分級規(guī)則

• 根據(jù)業(yè)務(wù)影響，應(yīng)用分為0-3級
• 應(yīng)用里面的接口再次細(xì)分0/1級，因?yàn)楹芏鄽v史原因，很多0/1級系統(tǒng)內(nèi)部N個(gè)接口，但M個(gè)接口是非核心的?；蛘?級應(yīng)用里面有N個(gè)0級接口。關(guān)注核心接口的健壯性（是否可用率治理完成，是否可降級，是否配置合理的限流值）

分級用途

?基于服務(wù)等級，要求核心服務(wù)遵守對應(yīng)標(biāo)準(zhǔn)（比如代碼評審，上線發(fā)布，變更流程，大促管控）。

?報(bào)警基于服務(wù)等級來做分級

?不同等級穩(wěn)定性要求SLO不一樣，如具備熔斷降級能力等。

注意事項(xiàng)

• 全鏈路應(yīng)用定級不統(tǒng)一：比如整個(gè)鏈路既有0級應(yīng)用，也有1級別應(yīng)用，還會(huì)存在很多3級應(yīng)用

解決方案：推動(dòng)下游更新應(yīng)用等級

如下圖，通過工具掃描0/1級依賴的下游等級應(yīng)用是3級，

• 接口定級不統(tǒng)一：比如某個(gè)歷史接口，A部門從自身角度出發(fā)認(rèn)為接口不重要，但上游，上游強(qiáng)依賴，有時(shí)候出現(xiàn)線上故障后才知道該接口的重要性

解決方案：需要鏈路追蹤，從用戶視角（用戶購物、物流一線操作業(yè)務(wù)）看影響，但這個(gè)有時(shí)候挺難的，尤其是歷史接口，鏈路太長

3、接口可用率不準(zhǔn)確：比如內(nèi)部異常被catch吃掉了，沒有反應(yīng)到接口最外層，比如服務(wù)故障了半個(gè)小時(shí)，但ump可用率還是100%

解決方案：進(jìn)行代碼可用率治理，讓API可用率是真實(shí)的。

2）SLI實(shí)踐應(yīng)用

選擇能代表業(yè)務(wù)核心功能的API，按上面的業(yè)務(wù)分級模型對這些API定級，一般只度量L0、L1等級的業(yè)務(wù)和其接口。那么應(yīng)該定義哪些指標(biāo)？為什么定義這些指標(biāo)？這些指標(biāo)是服務(wù)最重要嗎？

比如UMP打點(diǎn)監(jiān)控指標(biāo)有：

1）方法性能：TP50,TP90,TP99,TP999,TP9999,MIN,MAX,AVG

2）方法可用率

3）方法調(diào)用次數(shù)

這些監(jiān)控指標(biāo)我們都需要作為SLI嗎？答案肯定不是。只有理解用戶對系統(tǒng)的真實(shí)需求才能真正決定哪些指標(biāo)是否有用。指標(biāo)太多會(huì)影響重要的指標(biāo)，指標(biāo)太少又會(huì)導(dǎo)致重要的行為被忽略。一般來說，3-5個(gè)具有代表性的指標(biāo)對系統(tǒng)健康度的評估和關(guān)注足夠了。

根據(jù)常見的服務(wù)SLI分為如下幾類

圖片

3）SLO實(shí)踐應(yīng)用

我們應(yīng)該從用戶最關(guān)心的方面入手，而不是目前可以監(jiān)控度量什么著手（當(dāng)然目前UMP監(jiān)控度量的維度已經(jīng)很多，部分指標(biāo)可作為SLI）。制定適當(dāng)?shù)腟LO的第一步是討論SLO應(yīng)該是什么以及應(yīng)該涵蓋什么。SLO為服務(wù)的客戶設(shè)置了目標(biāo)可靠性級別。

為了更清晰的定義，SLO應(yīng)該具體支持他們是如何被度量的，以及其有效條件。例如：99%（在1分鐘時(shí)間范圍內(nèi)的請求匯總）的JSF-API調(diào)用會(huì)在200ms內(nèi)完成（包括全部后端服務(wù)器）

圖片

選擇目標(biāo)SLO策略建議

1.不要追求完美：不要以當(dāng)前的運(yùn)行狀態(tài)為基礎(chǔ)選擇目標(biāo)，而應(yīng)該從全局觸發(fā)，剛開始可以制定一個(gè)寬松的目標(biāo)（前提滿足用戶），逐步收緊。比如目前API的TP99是8ms，對外SLO的TP99是10ms,如果后期接口內(nèi)部邏輯改造,需求變更等導(dǎo)致API的tp99是20ms，則不滿足SLO。

2.留出一定的安全區(qū)：對內(nèi)使用更高的SLO，對外使用稍低的SLO。這樣可以留出一些空間來響應(yīng)需求等。緩沖區(qū)buffer可以保護(hù)我們不會(huì)對用戶產(chǎn)生直接影響。

您第一次嘗試SLI和SLO不一定正確。最重要的目標(biāo)是進(jìn)行適當(dāng)?shù)臏y量并建立反饋環(huán)路，以便您進(jìn)行改進(jìn)。隨著SLA的變更，系統(tǒng)架構(gòu)不斷的迭代演變（比如之前SLA的TP99是1000ms，你采用mysql架構(gòu)存儲(chǔ)數(shù)據(jù)，后面變成面向20ms，這時(shí)候的mysql架構(gòu)就不適合了，需要演變?yōu)楸热鐁edis緩存等形式）

4）SLA實(shí)踐應(yīng)用

研發(fā)需要和業(yè)務(wù)產(chǎn)品同事綜合考慮，目前內(nèi)部通過郵件達(dá)成協(xié)議。外部云廠商則通過合同達(dá)成協(xié)議（保護(hù)未達(dá)到SLO的補(bǔ)償條款）

三、云服務(wù)協(xié)議(可跳過)

對本章節(jié)內(nèi)容不感興趣的，可跳過

1）國家標(biāo)準(zhǔn)：信息技術(shù) 云計(jì)算 云服務(wù)級別協(xié)議基本要求

圖片

2）京東云主機(jī)服務(wù)等級協(xié)議（SLA）

圖片

3）阿里云服務(wù)器 ECS服務(wù)等級協(xié)議

圖片

4）AWS&Google云產(chǎn)品服務(wù)協(xié)議

圖片

圖片

四、API 網(wǎng)關(guān)服務(wù)等級協(xié)議

下面分別介紹不同廠商的API網(wǎng)關(guān)服務(wù)的可用率定義

1）京東云API 網(wǎng)關(guān)服務(wù)等級協(xié)議（SLA）

圖片

2）阿里云API 網(wǎng)關(guān)服務(wù)等級協(xié)議（SLA）

圖片

3）亞馬遜云API網(wǎng)關(guān)服務(wù)SLA

圖片

五、基于SLO告警治理實(shí)踐

SLO是可靠性決策的關(guān)鍵因素。應(yīng)用每天都有無數(shù)的報(bào)警通知，如CPU、內(nèi)存、磁盤、可用率、MAX，tp99，tp999等，產(chǎn)生了大量噪音。但哪些報(bào)警會(huì)影響到可用性，需要SRE和研發(fā)關(guān)注呢？這就是SLO的核心價(jià)值之一了。

告警設(shè)定的目標(biāo)：根據(jù)SLO對重要的事件做出可操作性的告警。

告警設(shè)定的依據(jù)：基于服務(wù)質(zhì)量指標(biāo)（SLI）和錯(cuò)誤預(yù)算，對每一個(gè)消耗大量錯(cuò)誤預(yù)算的事件發(fā)出重大事件的告警通知。

參考上面設(shè)定的SLO配置的報(bào)警信息如下：

1）API告警配置

我們可以通過設(shè)置合理的閾值和規(guī)則，過濾掉那些不必要的告警信息，從而避免告警噪音對開發(fā)運(yùn)維團(tuán)隊(duì)的干擾，讓他們更加專注于真正的問題。

?通過UMP實(shí)現(xiàn)3個(gè)黃金監(jiān)控指標(biāo)（可用率、調(diào)用量、TP99）

在配置報(bào)警機(jī)制時(shí)，我們可以綜合考慮可用率、TP99以及調(diào)用量等因素來進(jìn)行評估。通過這些指標(biāo)的綜合評估，可以幫助我們更全面地了解系統(tǒng)運(yùn)行情況，從而及時(shí)發(fā)現(xiàn)潛在的問題并采取相應(yīng)的措施。

建議在進(jìn)行報(bào)警配置時(shí)，可先采取較為嚴(yán)格的策略，即先緊后松，逐步調(diào)整到最佳狀態(tài)。這樣可以確保在最開始階段就能夠及時(shí)發(fā)現(xiàn)問題，避免出現(xiàn)重大故障。但隨著系統(tǒng)的逐漸穩(wěn)定，我們也可以根據(jù)實(shí)際情況適當(dāng)放寬報(bào)警閾值，以提高系統(tǒng)的可用性和效率。

需要注意的是，在進(jìn)行報(bào)警配置時(shí)，我們需要結(jié)合具體的業(yè)務(wù)場景和系統(tǒng)特點(diǎn)來進(jìn)行調(diào)整和優(yōu)化。不同的系統(tǒng)可能存在不同的風(fēng)險(xiǎn)點(diǎn)和瓶頸，因此我們需要根據(jù)實(shí)際情況來制定相應(yīng)的報(bào)警策略，以保證系統(tǒng)的穩(wěn)定性和可靠性。

比如SLO：分鐘級TP99是200ms，但你日常TP99在80ms，根據(jù)日常接口的行為，電話critical報(bào)警一定得配置<=200ms，warning可配100ms或者150ms等不斷調(diào)整到最佳狀態(tài)

critical告警方式：咚咚、郵件、即時(shí)消息(京ME)、語音 可用率：（分鐘級）可用率 < 99.95% 連續(xù) 3 次超過閾值則報(bào)警，且在 3 分鐘內(nèi)報(bào)一次警。性能：（分鐘級）TP99 >= 200.0ms 連續(xù) 3 次超過閾值則報(bào)警，且在 3 分鐘內(nèi)只報(bào)一次警。

warning告警方式：咚咚、郵件、即時(shí)消息 可用率：（分鐘級）可用率 < 99.99% 連續(xù) 3 次超過閾值則報(bào)警，且在 30 分鐘內(nèi)報(bào)一次警。性能：（分鐘級）TP99 >= 100.ms 連續(xù) 3 次超過閾值則報(bào)警，且在 30 分鐘內(nèi)只報(bào)一次警。調(diào)用次數(shù)：當(dāng)方法調(diào)用次數(shù)在 1 分鐘的總和，連續(xù) 3 次大于 2000000 則報(bào)警，且在 3 分鐘內(nèi)只報(bào)一次警

備注：語音critical告警配置調(diào)用次數(shù)一般意義不大，因?yàn)槿绻憬涌诘目捎寐蕸]問題，并且你的TP99也在預(yù)期內(nèi)，按調(diào)用次數(shù)高又有什么關(guān)系呢。但warning配置調(diào)用次數(shù)有一個(gè)好處，比如你配置了JSF限流，目前JSF限流是觸發(fā)了會(huì)報(bào)警，你可以在UMP或者Pfinder增加調(diào)用次數(shù)的閾值報(bào)警，比如設(shè)置為限流值的80%開始報(bào)警，這樣可提前發(fā)現(xiàn)限流導(dǎo)致的風(fēng)險(xiǎn)點(diǎn)。同時(shí)通過調(diào)用次數(shù)也可知曉流量增長趨勢

2）MQ告警配置

需要根據(jù)MQ延遲（數(shù)據(jù)從生產(chǎn)到消費(fèi)需要多少時(shí)間）配置對應(yīng)告警和應(yīng)急預(yù)案

圖片

?生產(chǎn)者T(1)監(jiān)控：生產(chǎn)者到MQ的時(shí)間監(jiān)控

?消費(fèi)者T(2.1)監(jiān)控：通過MQ的積壓報(bào)警配置進(jìn)行監(jiān)控。

?消費(fèi)者T(2.2)處理邏輯監(jiān)控：配置處理邏輯的UMP報(bào)警。

正常場景：T(3) > T(1) + T(2.1) + T(2.2)   其中T(3)包含讀最終數(shù)據(jù)的耗時(shí)

積壓報(bào)警的配置需要結(jié)合上述耗時(shí)公式，并且經(jīng)過壓力測試來確定。

假設(shè)在積壓20,000消息的情況下，現(xiàn)有服務(wù)能力能夠在N毫秒內(nèi)處理完成，并且滿足[ T(3) > T(1) + T(2.1) + T(2.2) ]的條件。那么，報(bào)警閾值可以設(shè)置為積壓20,000消息以下，例如10,000 warning，15000 critical報(bào)警以預(yù)留處理時(shí)間。

例如，若[ T(3) = 2000ms ]，日常[ T(1) ]的最大值為20ms，在積壓20,000消息的情況下[ T(2.1) = 980ms ]，[ T(2.2) = 1000ms ]。

3）定時(shí)任務(wù)告警配置

由于定時(shí)任務(wù)跟常規(guī)的JSF-API接口或者M(jìn)Q不一樣，定時(shí)任務(wù)是在規(guī)則約定的時(shí)間內(nèi)執(zhí)行，如果UMP是定時(shí)任務(wù)，最重要的一點(diǎn)就是確定好監(jiān)控時(shí)段。只有正確地配置了監(jiān)控時(shí)段，才能確保UMP在預(yù)計(jì)時(shí)間段內(nèi)正常執(zhí)行，這樣一旦UMP未能在預(yù)計(jì)時(shí)間段內(nèi)執(zhí)行，就會(huì)自動(dòng)觸發(fā)報(bào)警機(jī)制，及時(shí)發(fā)現(xiàn)并解決問題。

比如xxx是每天的1點(diǎn)執(zhí)行

我需要監(jiān)控1點(diǎn)是否執(zhí)行了

圖片

六、問題解答

通過閱讀本文，相信你已經(jīng)知道如何解答文章開始的3個(gè)問題了

1）SLA、TP99、超時(shí)時(shí)間的關(guān)系？

1.TP99沒什么好說的，看接口的UMP打點(diǎn)即可，比如這圖接口的TP99是10-15ms。

圖片

• 由于上游是下單前黃金鏈路，對性能要求較高。SLA（其實(shí)是SLO)我們對外承諾的TP99(分鐘）是20ms，預(yù)留6ms的buffer
• 超時(shí)時(shí)間設(shè)置：超時(shí)時(shí)間可以設(shè)置在TP99（業(yè)務(wù)要求高的參考TP999、TP9999、MAX）（包含網(wǎng)絡(luò)延遲）的基礎(chǔ)上加上一定的緩沖時(shí)間。其中緩沖時(shí)間需要根據(jù)經(jīng)驗(yàn)或監(jiān)控?cái)?shù)據(jù)等日常行為統(tǒng)計(jì)學(xué)，增加一個(gè)安全緩沖時(shí)間。例如，如果下游接口的TP99是200ms，您可能將超時(shí)時(shí)間設(shè)置為300ms到400ms。
• 重試次數(shù)設(shè)置：

?下游接口必須支持冪等，方可重試

?重試策略：根據(jù)業(yè)務(wù)場景和下游接口的穩(wěn)定性來決定重試次數(shù)。一般來說，重試次數(shù)不宜過多（1-3次），以避免加重系統(tǒng)負(fù)擔(dān)，同時(shí)要考慮重試后是否會(huì)不滿足你對外的SLA指標(biāo)，尤其下游出現(xiàn)超時(shí)嚴(yán)重的時(shí)候。

?指數(shù)退避：使用指數(shù)退避策略，每次重試的間隔時(shí)間逐漸增加（例如，第一次等待1ms，第二次等待2ms，第三次等待4ms）。

4.實(shí)施和監(jiān)控：監(jiān)控實(shí)際的重試情況和超時(shí)情況，定期評估重試和超時(shí)策略對系統(tǒng)性能的影響。調(diào)整策略以適應(yīng)實(shí)際情況。

請注意，設(shè)置超時(shí)時(shí)間和重試次數(shù)是一個(gè)需要平衡多個(gè)因素的決策過程。它需要考慮系統(tǒng)的穩(wěn)定性、響應(yīng)時(shí)間、資源使用和用戶體驗(yàn)等多個(gè)方面。此外，任何重試策略都應(yīng)該避免可能導(dǎo)致級聯(lián)故障或資源耗盡的情況。

2）團(tuán)隊(duì)系統(tǒng)可用率是怎么計(jì)算的？

問題2：系統(tǒng)中的一個(gè)API接口的可用率是99.99%，那么在部門中，包含了N個(gè)系統(tǒng)和M個(gè)接口，部門的季度可用率是99.98%，這個(gè)數(shù)字又是如何計(jì)算出來的呢？

如A系統(tǒng)為黃金流程生產(chǎn)系統(tǒng)，因系統(tǒng)出現(xiàn)服務(wù)故障，導(dǎo)致生產(chǎn)業(yè)務(wù)無法操作，故障時(shí)長為A，影響業(yè)務(wù)占比率為B，則最終可用率故障時(shí)長為 C=A*B；

可參考問題3的計(jì)算公式

比如黃金鏈路故障時(shí)長150分鐘，影響業(yè)務(wù)占比10%，折合系統(tǒng)不可用時(shí)長=15分鐘。

則月度系統(tǒng)可用率=1-（故障總時(shí)長/統(tǒng)計(jì)周期總時(shí)長）*100%=1-（15/30*24*60)=99.96%

3）云主機(jī)&網(wǎng)關(guān)API可用率

問題3：比如在XXX云購買了100臺(tái)云主機(jī)（按照云主機(jī)SLA），其中在10:00-10:05這5分鐘，有10臺(tái)機(jī)器有故障，導(dǎo)致API對外可用率是90%（5分鐘之內(nèi)總請求數(shù)1W，失敗請求數(shù)1000）。一個(gè)月30天每天發(fā)生類似的5分鐘1次。請問對用戶來說可用率是多少？

從2個(gè)維度來解答

• 從提供基礎(chǔ)服務(wù)的云服務(wù)等級協(xié)議來解答（這個(gè)不同云廠商基本是一致的）。
• 從面向用戶的API角度來解答 （不同廠商定義公式不一樣）

任何產(chǎn)品都不是，也不應(yīng)該做到100%可靠，因?yàn)閷τ脩魜碚f99.999%和100%的可用性大部分沒有本質(zhì)的區(qū)別。那多少合適呢？可靠性目標(biāo)需要考慮的因素：

• 服務(wù)可靠性要達(dá)到什么程度，用戶才會(huì)滿意？
• 如果可靠性不夠，是否有其他替代選擇？
• 服務(wù)的可靠程度是否會(huì)影響用戶對服務(wù)的使用模式？
• 是否直接關(guān)系到收入？
• 服務(wù)是針對消費(fèi)者還是企業(yè)？

七、技術(shù)指標(biāo)&業(yè)務(wù)指標(biāo)

正如上面說的SLA定義了服務(wù)可用性、性能等技術(shù)指標(biāo)。那么業(yè)務(wù)指標(biāo)到底要解決什么問題？解決技術(shù)指標(biāo)（可用率，tp99）看不到的問題。關(guān)注的是數(shù)據(jù)的正確性和完整性。

SLA的技術(shù)指標(biāo)和業(yè)務(wù)監(jiān)控的數(shù)據(jù)正確性通常是相互關(guān)聯(lián)的。技術(shù)指標(biāo)不可用，則肯定業(yè)務(wù)指標(biāo)會(huì)不可用。相反如果業(yè)務(wù)指標(biāo)不可用有異常，不一定技術(shù)指標(biāo)不可用。例如，如果一個(gè)系統(tǒng)的可用性低于SLA中定義的閾值，那么這可能會(huì)影響到業(yè)務(wù)流程的正常運(yùn)行，從而導(dǎo)致數(shù)據(jù)錯(cuò)誤或丟失。因此，為了確保業(yè)務(wù)連續(xù)性和數(shù)據(jù)準(zhǔn)確性，SLA和業(yè)務(wù)監(jiān)控通常需要共同考慮和管理。

八、「以終為始」SLA指導(dǎo)11.11大促備戰(zhàn)

SLA可以作為一個(gè)強(qiáng)有力的工具，指導(dǎo)11.11大促的備戰(zhàn)工作,明細(xì)如下：

1.明確服務(wù)目標(biāo)：上下游明確SLA（服務(wù)性能TP99、可用性、峰值QPS）等方面的承諾。這些目標(biāo)應(yīng)該與11大促的業(yè)務(wù)需求相匹配，例如峰值流量下的系統(tǒng)穩(wěn)定性和快速響應(yīng)能力。

2.制定備戰(zhàn)計(jì)劃：根據(jù)SLA的要求，制定詳細(xì)的備戰(zhàn)計(jì)劃，包括資源配置、系統(tǒng)優(yōu)化、災(zāi)難如何快速恢復(fù)等。例如，如果SLA要求系統(tǒng)在高峰期的可用性達(dá)到99.99%，那么備戰(zhàn)計(jì)劃就需要考慮如何實(shí)現(xiàn)這一目標(biāo)，你的容錯(cuò)方案、降級方案、應(yīng)急預(yù)案等。

3.軍演全鏈路壓測和容量規(guī)劃：為了確保在大促期間滿足SLA的要求，需要進(jìn)行性能壓測&軍演全鏈路壓力測試和容量規(guī)劃。通過壓測高流量場景，驗(yàn)證系統(tǒng)的性能和穩(wěn)定性，并根據(jù)測試結(jié)果調(diào)整資源配置和系統(tǒng)優(yōu)化策略。

4.監(jiān)控和警報(bào)系統(tǒng)：建立一個(gè)全面的監(jiān)控和警報(bào)系統(tǒng)，實(shí)時(shí)跟蹤服務(wù)的性能和健康狀況。如果某個(gè)指標(biāo)超出了SLA的閾值，系統(tǒng)應(yīng)該自動(dòng)觸發(fā)警報(bào)，通知相關(guān)團(tuán)隊(duì)采取行動(dòng)。

5.優(yōu)先級管理：在大促期間，根據(jù)SLA的重要性和影響范圍，設(shè)定問題的優(yōu)先級，確保最關(guān)鍵的服務(wù)得到優(yōu)先處理。

6.團(tuán)隊(duì)協(xié)作和溝通：SLA要求各個(gè)團(tuán)隊(duì)之間的緊密協(xié)作和高效溝通。建立跨部門的協(xié)作機(jī)制，明確每個(gè)團(tuán)隊(duì)的職責(zé)和SLA目標(biāo)，確保所有團(tuán)隊(duì)都朝著同一個(gè)目標(biāo)努力。

7.持續(xù)改進(jìn)：11.11大促結(jié)束后，回顧整個(gè)過程，分析SLA的達(dá)成情況，找出改進(jìn)的空間。將這些經(jīng)驗(yàn)和教訓(xùn)應(yīng)用到下一年的備戰(zhàn)中，持續(xù)提升服務(wù)質(zhì)量。

附:1）SLO文檔示例

服務(wù)概述

常見的有API，MQ消息

圖片

說明和警告

?請求指標(biāo)是在負(fù)載均衡器上測量的。此度量可能無法準(zhǔn)確度量用戶請求未到達(dá)負(fù)載均衡器的情況。

?我們僅將HTTP 5XX狀態(tài)或者約定的API Response里的Code錯(cuò)誤編碼消息視為錯(cuò)誤代碼；其他一切都算成功。

2）云服務(wù)級別指標(biāo)

圖片