作者簡介：襄玲(花名)，阿里巴巴技術專家，PTS 研發，近期主導整理和推動云時代性能壓測的思想和標準,云計算性能測試國標項目組成員，內部穩定性保障系統之預熱系統負責人。

本文是《Performance Test Together》(簡稱PTT)系列專題分享的第6期，該專題將從性能壓測的設計、實現、執行、監控、問題定位和分析、應用場景等多個緯度對性能壓測的全過程進行拆解，以幫助大家構建完整的性能壓測的理論體系，并提供有例可依的實戰。

本文主要介紹如何正確的使用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，讓壓測不再手忙腳亂。有不同意見處請指正，謝謝！

高可用架構

改變互聯網的構建方式

總結

以上是生活随笔為你收集整理的oralce load的时候使用触发器会导致load慢吗_你真的了解性能压测中的SLA吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。