你真的瞭解性能壓測中的SLA嗎？

你真的瞭解性能壓測中的SLA嗎？

做者簡介：襄玲(花名)，阿里巴巴技術專家，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，讓壓測再也不手忙腳亂。有不一樣意見處請指正，謝謝！

參考閱讀：

• 正式支持多線程！Redis 6.0與老版性能對比評測
• 一百人研發團隊的難題：研發管理、績效考覈、組織文化和OKR
• 一個Netflix開發的微服務編排引擎，支持可視化工做流定義
• 你真的瞭解壓測嗎？實戰講述性能測試場景設計和實現
• 關於Golang GC的一些誤解--真的比Java算法更領先嗎？

技術原創及架構實踐文章，歡迎經過公衆號菜單「聯繫咱們」進行投稿。轉載請註明來自高可用架構「ArchNotes」微信公衆號及包含如下二維碼。

高可用架構

改變互聯網的構建方式