本文是《Performance Test Together》（簡稱PTT）系列專題分享的第6期，該專題将從性能壓測的設計、實作、執行、監控、問題定位和分析、應用場景等多個緯度對性能壓測的全過程進行拆解，以幫助大家建構完整的性能壓測的理論體系，并提供有例可依的實戰。
該系列專題分享由阿裡巴巴 PTS 團隊出品，歡迎在文末處加入性能壓測交流群，參與該系列的線上分享。
本文主要介紹如何正确的使用SLA來确定備容的目标，同時提高壓測效率。主要分為理論和實踐兩個部分。
SLA無處不在
在雲計算時代，越來越多企業的服務遷移到雲上，各大雲服務廠商有自己服務釋出的SLA，比如阿裡雲的ECS伺服器/RDS服務/REDIS服務等，都有對應的SLA,SLA是服務提供商與客戶之間定義的正式承諾。
除了雲服務廠商，提供各種服務的APP/網站，如果在客戶在購物時無法下單/或者在周末刷着小視訊的視訊打不開了，這個會嚴重影響使用者的體驗，如果故障出現的時間比較久，會流失一大批的客戶，給業務帶來損失。那麼，如何衡量給客戶提供的服務品質呢？進而如何衡量系統的穩定性呢？毋庸置疑，也需要統一的語言SLA。那麼，具體什麼是SLA呢？
在新系統上線，大促以及系統面臨大的架構調整等各種場景中，架構組以及開發人員，需要提前為系統進行備容,對系統進行性能壓測，在壓測過程中，與SLA又有什麼聯系呢？
SLA定義
服務級别協定（英語：service-level agreement，縮寫SLA）也稱服務等級協定、服務水準協定，是服務提供商與客戶之間定義的正式承諾[維基百科定義]。SLA的概念，對網際網路公司來說就是網站服務可用性的一個保證。
SLA包括兩個要素，一個是SLI,一個是SLO，其中SLI定義的是測量名額；SLO定義的是服務提供的一種狀态。
SLI：SLI是經過仔細定義的測量名額，它根據不同系統特點确定要測量什麼，SLI的确定是一個非常複雜的過程。SLI确定測量的具體名額，在确定具體名額的時候，需要做到該名額能否準确描述服務品質以及該名額是否可靠。
SLO：SLO(服務等級目标)指定了服務所提供功能的一種期望狀态，包含所有能夠描述服務應該提供什麼樣功能的資訊。一般描述為：每分鐘平均qps > 100k/s；99% 通路延遲 < 500ms；99% 每分鐘帶寬 > 200MB/s。
設定SLO時的幾個最佳實踐：
- 指定計算的時間視窗
- 使用一緻的時間視窗(XX小時滾動視窗、季度滾動視窗)
- 要有一個免責條款，比如：95%的時間要能夠達到SLO
SLA以面向人員的次元區分，可以劃分為以下兩個次元。
第一：業務次元：客戶對這部分的名額最有體感，直接與使用者的體驗好壞挂鈎。
-
例如，響應時間，錯誤率等。有統計資料顯示，如果響應時間大于1s，80%的使用者就會流失掉；錯誤率名額，是對功能正确性的保障，如果開始有業務錯誤，那麼客戶都無法直接完成期望的操作，流失也是避免不了的。這部分的名額直接影響使用者的體驗。
第二：服務側次元：描述的是服務端的名額，這部分名額主要是面向開發以及測試人員的，為了在發生問題的時候，可以快速定位問題。
- 比如，ECS/RDS等的系統名額，包括 CPU/LOAD等。
壓測中的SLA
在進行性能壓測設計階段,有一個重要的環節是确定“性能壓測通過标準”。缺少了這個标準,意味着壓測可能是沒完沒了的,誰都不知道什麼時候該結束,影響性能壓測效果,浪費人力财力。是以需要通過“性能壓測通過标準”中一系列量化下來的名額來确定,壓測結果是否符合預期,可以停止了。這個"标準"的來源,可能是來自業務方的期望,研發組對系統的性能期望等等,最終整理彙總下來的我們稱為壓測中的SLA。這個SLA與産品對外的SLA有緊密聯系,但是又存在差別。聯系就是,系統對外的SLA是壓測中的SLA的重要來源,而差別就是,壓測中的SLA可能會涵蓋更多更細的名額,而對外的SLA并不關心這麼多細節。
在正确壓測嗎？
在壓測中，看似一個簡單的業務請求，實則後端是複雜的系統架構，比如統一接入層/容器層/存儲層，即使容器層，也涉及到了很多不同應用/不同服務，面對紛繁複雜的架構，如何快速判斷壓測結果是否滿足了業務需求？如何快速判斷是否達到了系統的水位不能再往上施壓了呢？
作為備容的一份子（開發或者測試），可以想象一下，常态是怎樣的？
一聲号令，開始壓測！好了，A開發看A系統，B開發看B系統，C開發看網絡層，D測試看壓測結果等。大家手忙腳亂，這個時候，有人在群裡一聲喊，我的系統扛不住了，停止吧（當然還有一種風險，是不是這位同學的誤判呢）。好的，這個時候壓測停止。當然這種還是比較好的情況，而有些壓測場景，就隻有一個測試同學，他怎麼分工呢？一會看看壓測結果，一會看看A系統，一會看看B系統，忙得不亦樂乎。
這樣壓測能否達到效果，當然能。但是這樣的狀态是最好的一種狀态嗎？當然不是！這個時候SLA就派上用場了。
- 首先，開發/測試/業務同學在壓測之前，對齊SLA名額，即意味着明确系統需要持續提供的服務能力，以及系統的整體水位，減少後續的溝通流程，大家都以此目标備容。
- 其次，配置好SLA之後，壓測的負責人則隻需要重點關注是否存在SLA告警，如果連續告警則說明系統已經扛不住了，直接停止壓測或者由SLA直接停止壓測。對于壓測的小夥伴來說，省時省力，既不會漏掉一些名額，同時也不會浪費壓測時間。
如何在PTS中正确使用SLA
想象一下，開發同學都在忙，隻有“我”一個測試人員有時間全盤盯着壓測。壓測起來之後，直接把不合格的業務次元資料以及系統次元資料，統統通知給“我”，“我”隻是決策要不要停止壓測，同時直接産出系統容量水位報告，這樣是不是爽歪歪？PTS就提供了這樣的功能，即設定SLA。設定SLA需要基于采集到的各種名額，采集的名額越豐富，則SLA越豐富，越能滿足不同業務的需求。
在具體使用中，首先了解PTS提供的名額，然後選取與自己業務相契合的名額并設定對應的門檻值，最後進行壓測。
首先，了解一攬子名額
監控名額，可以分為用戶端相關名額，即業務次元名額；另一個是服務端相關名額。
- 用戶端監控名額，是最直覺的判斷系統提供的服務是否滿足了業務的訴求，PTS提供了RPS/請求失敗RPS/響應時間等名額。
- 服務端相關名額，則是從研發人員角度區分的，一方面服務端系統的表現會直接影響用戶端的各個名額，是關聯的。另一方面，在用戶端或者服務端出現問題的時候，可以更加友善的定位到問題。PTS服務端名額，包含了SLB/ECS/RDS等相關元件的監控資料。
第二，選取核心名額并設定門檻值
- 首先，用戶端的SLA名額包含了 RT/RPS/成功率三個名額，分别從 響應時間/可用性以及通路負載 描述了用戶端的通路是否正常，直接反映了客戶的使用體感，以及提供的核心服務是否在提供可持續性可用的服務；用戶端的名額通常需要測試人員與業務方根據具體的業務具體設定。
- 成功率是一個衡量系統是否可用的核心名額。同時成功率優先考慮的是業務成功率，若未設定業務成功率，則是code碼等預設的成功率。
- RT反映了客戶通路網站的速度，一般情況下，網際網路使用者都不是特别有耐心。KissMetrics 的研究結果顯示，“1 秒的網頁響應延遲可能會導緻轉化次數減少 7%”，“47% 的消費者都希望網頁能夠在 2 秒内加載完畢”。
- RPS則是系統能承載的最大的RPS，也即系統容量最大水位。
- 其次，服務端的名額，包括了 SLB/ECS/RDS 三個層面的名額，每個層面的名額，由具體元件提供服務的特點決定。例如ECS名額包括 CPU/記憶體使用率/LOAD ；SLB名額包括 丢棄連接配接數/異常後端server數；RDS名額包括 CPU/記憶體使用率/IOPS/連接配接使用率；這部分的名額大部分情況下由開發人員确定，有個大的規則，比如CPU一般不超過80%，LOAD不超過核數的1.5倍等，具體情況具體分析。
第三，選擇好名額，以及為名額設定好對應的門檻值之後，就可以放心的壓測了。在壓測中，如果觸發了設定的SLA則進行報警，或者直接停止壓測。同時還會有事件的彙總資訊。
這樣，通過前期各方對齊相應的SLA名額，并且在PTS中設定SLA，既可以對齊目标，又可以解放壓測過程中的人力，很直覺的看到哪些名額達到了門檻值。未設定SLA之前，大家手忙腳亂的觀看各種名額資料，生怕漏掉，而加了SLA之後，就可以喝着茶把壓測做完。同時，除了通過設定SLA幫助小夥伴們更好的提高壓測效率外，我們還會将SLA與智能壓測相結合，大家敬請期待。
小結
SLA無處不在，本文主要從SLA是什麼，壓測過程中設定SLA的意義，以及如何正确使用SLA進行了簡述。正确利用并設定SLA，讓壓測不再手忙腳亂。有不同意見處請指正，謝謝！