網站可靠性工程（SRE）在維護雲端服務的穩定性和性能方面發揮著關鍵作用。在這個文章中，我們將介紹SRE工程師武器庫，重點關注服務水準協議（SLA）、服務水準目標（SLO）和服務水準指標（SLI）等三個重要的維運數據。閱讀本文結束時，您將對這些關鍵概念以及它們對數字服務的可靠性有堅實的理解。
圖片來源: unsplash – https://unsplash.com/
瞭解網站可靠性工程 Site reliability engineering – SRE
SRE的演進
網站可靠性工程（SRE），一詞最早由Google提出，已經改變了組織對軟體可靠性和系統穩定性的處理方式。它是一門將軟體工程的方面應用於基礎設施和運營問題的學科。其主要目標是創建可擴展且高度可靠的軟體系統。
SRE工程師的主要職責
SRE工程師的責任是確保軟體系統的可靠性、可擴展性和效率。他們通過結合軟體開發、系統工程和運營任務來實現這一目標。監控服務指標如SLA、SLO和SLI是他們角色的核心，提供了一種數據驅動的方法來衡量和改進系統的可靠性。
理解服務水平協議（SLA）
圖片來源: unsplash – https://unsplash.com/
定義與重要性
服務水平協議（SLA）是定義客戶對服務提供者期望的服務水平的正式文件。它們在設定明確的期望和建立責任中至關重要。
有效SLA的組成部分
有效的SLA是具體的、可衡量的、可實現的、相關的和有時間限制的。它們涵蓋了如正常運行時間、響應時間和支持條款等方面。瞭解這些組成部分對於SRE來說至關重要，以確保他們的策略與約定的服務標準保持一致。
服務水平目標（SLO）：SRE的指南針
圖片來源: unsplash – https://unsplash.com/
設定現實的SLO
設定SLO包括為服務性能定義具體目標。這些目標應該是現實的，考慮到系統的能力和業務要求。
平衡SLO與業務目標
SLO應與整體業務目標保持一致。這種一致性確保SRE的努力直接促進公司的成功，平衡技術性能與業務成果。
服務水平指標（SLI）：衡量重要事項
圖片來源: unsplash – https://unsplash.com/
辨識關鍵SLI
服務水平指標是用於衡量服務對SLO的性能的指標。辨識正確的SLI至關重要，因為它們提供了評估服務質量所需的數據。
實踐中實施SLI
實施SLI包括選擇正確的工具和設置持續監控的過程。它需要對系統架構和用戶期望有深入的瞭解。
案例研究：線上零售平台
SLA、SLO和SLI是相互聯繫的。SLA設定了整體期望，SLO將這些轉化為具體目標，而SLI提供了評估這些目標遵從情況的測量。分析有效實施SLA、SLO和SLI的案例研究可以提供寶貴的見解，瞭解最佳實踐和常見陷阱。
假設我們有一個線上零售平台，名為 “ShopFast”。ShopFast 與其客戶（商家和買家）簽訂了一個服務等級協議（SLA），並根據這個協議設定了服務等級目標（SLO）和服務等級指標（SLI）。
1. 服務等級協議（SLA）
在 ShopFast 的例子中，SLA 可能包含如下內容：
- 系統可用性保證：確保平台每月的正常運行時間至少達到 99.9%。
- 響應時間承諾：所有客戶服務請求的響應時間不超過 24 小時。
- 數據保護和隱私承諾：保證客戶數據的安全性和隱私。
2. 服務等級目標（SLO）
針對 SLA 中的每一項承諾，ShopFast 需要設定具體可衡量的目標：
- 系統可用性：每月的正常運行時間目標為 99.95%。
- 響應時間：95% 的客戶服務請求在 12 小時內得到回應。
- 數據安全性：確保每年進行至少兩次安全審計，以及實施最新的安全協議。
3. 服務等級指標（SLI）
為了測量是否達到 SLO，ShopFast 需要具體的指標：
- 系統可用性 SLI：系統正常運行的時間百分比。
- 響應時間 SLI：客戶服務請求的平均響應時間。
- 數據安全性 SLI：每年實施的安全審計次數和違反安全協議的事件數。
實際應用
在實際操作中，ShopFast 的 SRE 工程師團隊會利用各種監控工具來追蹤這些 SLI，並定期檢查是否達到或超過了 SLO。如果發現任何 SLO 未達標，團隊將迅速採取行動進行必要的調整或修復。這可能包括優化系統架構、改善客戶服務流程，或加強安全措施。
此外，ShopFast 還會定期與其客戶溝通這些指標的表現，以增強透明度和信任。這樣的做法不僅有助於維護客戶關係，也使得公司能夠持續改進其服務質量。
監控與報告：工具與技巧
SRE常用的監控工具
有多種工具可供SRE有效監控SLI。本節將探討一些流行的工具，如Prometheus、Grafana和Google Cloud的運營套件。實務上，其實要配合service mesh or open telementry才會比較容易量測到對應的 lattercy 的SLI，一開始建議先針對http response的部分建立SLI。
參考 Google SRE fundamentals: SLIs, SLAs and SLOs 中可以看到，GCP 服務儀表板允許您按多種方式分組：按服務、按方法和按響應碼分組任何第 50、第 95 和第 99 百分位圖表。您還可以在對數刻度上查看延遲圖表，以快速找出異常值。這就可以作為SLI的指標，並根據上述的SLO來得知目前服務整體的狀況，確認服務品質是可以被量測的，符合SMART原則。
參考連結：https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-slis-slas-and-slos
報告指標的最佳實踐
報告與監控同等重要，這邊建議可以考慮不同等級的SLA報告，可以使用Uptime kuma 來建立healthcheck的服務SLA報告作為直覺的第一級SLA，他可以統計24小時與30天的uptime SLA，以及對應的平均回應時間，對於掌握服務狀況是SRE工程師的神兵利器。
參考連結：github – https://github.com/louislam/uptime-kuma
事件管理與SLA
事件管理與服務等級協議（SLA）之間的關係是網站可靠性工程（SRE）領域的重要組成部分。當發生 SLA 違規時，即服務提供商未能滿足協議中規定的服務標準，SRE 團隊的回應方式將對企業的運營和客戶滿意度產生深遠影響。沒做好就是業務一直要去客戶那邊跪算盤，然後給賠償，所以真的是蠻重要的，以下是對這些過程的詳細探討：
回應SLA違規
SRE對SLA違規的回應至關重要。這不僅涉及立即的補救行動，還包括預防未來發生的長期策略。
一般來說事件一發生會建議立即開啟P0戰情室War room，也有人利用page duty來做自動化開啟。我們則是在Slack寫自動化機器人，會開啟對應的服務儀表板與google meeting room。各家做法不一，能夠迅速解決最重要
- 立即補救行動：
- 當發現 SLA 違規時，SRE 團隊首先需要快速識別問題並採取行動以盡快恢復服務，P0戰情室War room。
- 這可能包括部署臨時解決方案，以減少對用戶的影響，比如切換到備用系統或啟動額外的資源。
- 通訊和透明度：
- 對於所有影響到的利益相關者，包括內部團隊和外部客戶，及時準確地通報事件的性質、影響範圍以及預期的解決時間是非常重要的，通報時間的policy。
- 維持透明度有助於建立信任，即使在面對挑戰的時候。
- 長期策略和預防措施：
- 除了立即的補救措施外，SRE 團隊還需要分析導致 SLA 違規的根本原因，並開發長期策略來防止類似事件再次發生。
- 這可能包括改進系統架構、增強監控和警報系統、以及修訂運營流程。最建議利用後續的 SRE Postmortem 來做再次的檢討。
事件後審查
進行事件後審查是從SLA違規中學習的關鍵方面。這些審查有助於瞭解根本原因並改進系統和流程。最重要的是要進行Postmortem (驗屍報告)，可以參考SRE Handbook – Postmortem Culture: Learning from Failure，他有提供對應的表格可以調整後變成自己團隊需要的樣子，這邊提供大家 SRE Postmortem (副本使用）。也可以參考對應的google Example Postmortem – Shakespeare Sonnet++ Postmortem (incident #465) 後，自行修改喜歡的樣子
- 分析和學習：
- 事件後審查是一個深入分析事件原因、影響、處理過程和恢復措施的過程。
- 目的是從這些事件中學習，識別改進機會，並應用這些教訓來加強未來的響應和預防策略。
- 跨部門合作：
- 進行有效的事件後審查需要跨部門的合作，包括 SRE 團隊、開發人員、產品管理人員以及客戶服務代表等。
- 涉及不同視角和專業知識可以幫助更全面地了解事件並制定更全面的解決方案。
- 持續改進：
- 事件後審查的結果應該被用來持續改進系統的可靠性和性能。
- 這可能包括更新 SLA、調整 SLO 和 SLI、改善基礎設施和流程、或提升團隊的技能和響應能力。
SRE中的風險管理：考慮SLA和SLO
評估與緩解風險
風險管理是SRE角色的關鍵部分。本節將探討如何使用SLA和SLO識別和緩解風險。實作就是利用SLI來建立警報機制，同時要避免告警疲勞來執行整體的演練任務。
基本上參考消防事件的編制是最簡單的，先確認問題的嚴重性也就是風險識別，在執行對應的風險量化與優先級設定來決定要不要開P0戰情室，當然有些不是P0的警報，例如資料庫的CPU一直頂到80%，那這時候就視情況在離峰時間進行資源升級。
- 使用 SLA 和 SLO 進行風險識別：
- SLA 和 SLO 可以作為識別潛在風險的工具。例如，一個過於嚴格的 SLA 可能會導致資源過度集中在維持 SLA 上，而忽略了其他重要的維護任務。
- 透過評估 SLA 和 SLO 的可實現性和維持成本，SRE 團隊可以預見到可能對系統穩定性和效能產生負面影響的風險。
- 風險量化與優先級設定：
- 將風險量化並根據其可能造成的影響和發生概率進行分類。這有助於團隊確定哪些風險需要首先關注和解決。
- 例如，一個可能導致長時間停機的風險應該比導致短暫性能降低的風險獲得更高的優先級。
- 實施緩解措施：
- 開發和實施針對特定風險的緩解措施，如增加冗餘系統、改善監控和警報機制，以及優化自動化回應流程。
持續改進SRE
持續改進的概念是SRE的核心。這包括定期審查和更新SLA、SLO和SLI，以應對新的見解和不斷變化的業務需求。
這邊建議每季定期審查 SLA 和 SLO，這樣比每個月的壓力要低，又不會拖太長時間不更新。同時定期也可以利用上面Uptime kuma的SLA指標來決定是否要針對服務做調整，例如常常downtime又起來的服務，是不是應該調整資源，這都是屬於使用數據驅動的決策。
這邊我們會利用不同slack的頻道建立告警機制，在邀請不同研發團隊在對應服務的頻道一起收到告警，這樣自然而然的促進跨團隊合作，一起為問題買單並解決，不會出現別人家的部門孩子死不完的情況。
- 定期審查 SLA 和 SLO：
- 定期評估現有的 SLA 和 SLO 是否仍適用於當前的業務和技術環境。隨著業務需求和技術能力的變化，這些標準可能需要調整。
- 這包括考慮客戶的反饋、分析系統的性能趨勢，以及評估新的技術或方法如何影響服務交付。
- 使用數據驅動的決策：
- 利用收集的性能數據和指標來指導決策。這有助於確定哪些改進措施最有效，並且提供了實際證據來支持變更的必要性。
- 包括持續監控 SLI（服務等級指標）以評估對 SLO 的符合度，並在必要時進行調整。
- 促進跨團隊合作：
- SRE 的持續改進需要來自不同背景和專業知識的團隊成員之間的合作。這包括與開發、運營、產品管理等團隊的緊密合作，以確保全面理解風險和改進的機會。
- 鼓勵開放的溝通和知識共享，以促進創新和解決問題的協作。
服務監控指標的未來趨勢
SRE領域不斷演進，隨著技術的演進和業界需求的變化，這些指標和相關策略也在不斷發展。像是近年火紅的service mesh or open telementry 等 kubernetes的新技術，SRE工程師要掌握的技能也是越來越多。
預測與演變
下面這五個其實是未來除了CPU/RAM/Lattency以外，針對微服務架構、生成式AI到資安議題都有可能要面對的問題與觀測指標。
- 更大的自動化和智能化：
- 未來的服務監控將更加依賴自動化工具和智能算法來預測問題、優化性能和管理系統健康狀態。這包括使用機器學習來識別模式和異常，從而提前預防問題的發生。
- 集成式監控解決方案：
- 隨著系統變得更加復雜，集成多個監控工具和平台的需求將日益增加。這樣可以提供更全面的視角，幫助 SRE 團隊更有效地管理和優化服務。
- 使用更細粒度的指標：
- 為了更準確地衡量和改進服務質量，我們可能會看到更多細粒度的指標被採用。這些指標可以更精確地反映用戶體驗和系統性能。
- 關注可持續性和效能：
- 隨著環境可持續性成為全球關注的焦點，未來的 SRE 可能會更加重視減少能源消耗和碳足跡。這可能會導致開發新的監控指標來衡量和優化數據中心的能源效率。
- 強化安全性和隱私性能指標：
- 在數據安全和隱私日益受到重視的背景下，將這些因素納入服務監控也變得越來越重要。這意味著將安全和隱私相關的指標整合到服務監控體系中。
適應技術變革
隨著技術的演進，監控和維護服務水平的策略也在變化。下面四點雖然是老生常談，但卻是跑不了的問題，這邊最重要的其實是協作與溝通，在企業中的服務其實最大的問題是人，只要建立團隊文化到企業文化，那SRE就會舉足輕重。但如果大家身上都有一層油油的膜，那我覺得SRE只能一直吃虧，所以挺身而出去溝通與協作，並建立團隊文化是SRE到DevOps文化中的必修課
- 靈活適應新技術：
- SRE 團隊需要保持對新技術的敏感度和適應能力，如雲計算服務、容器化技術和微服務架構等。這需要持續學習和實驗，以便快速整合新技術進入現有的監控框架。
- 跨領域技能發展：
- 隨著技術的演進，SRE 專業人員需要具備更廣泛的技能，包括編程、系統架構、數據分析和機器學習等。這有助於他們更好地理解和應對從各種技術引發的挑戰。
- 增強協作與溝通：
- 在快速變化的技術環境中，與開發團隊、運營團隊和業務團隊之間的協作和溝通變得更加重要。共享知識和最佳實踐有助於團隊更快地適應技術變革。
- 重視數據驅動的決策：
- 隨著數據分析和機器學習技術的發展，SRE 團隊將能夠更加依賴數據來指導決策。這涉及收集、分析和運用大量數據來優化監控策略和改進服務。
常見問題解答
SLA、SLO和SLI之間有什麼區別？
總結來說，SLA 是一份合同，定義了服務提供者的承諾和客戶的權利，SLO 是服務提供者設定的性能目標，而 SLI 則是用於衡量實際服務性能的具體指標。這三者通常一起使用，以確保服務達到或超出客戶的期望。如果服務提供者無法達到 SLA 中規定的水平，可能需要支付賠償金。同時，SLO 和 SLI 也用於內部監控和不斷優化服務的目的。
SRE如何使用SLA提高系統可靠性？
SRE 使用 SLA 作為確保系統可靠性的框架，通過監控、警報、目標設定和事後分析等方法，來持續改進和維護服務的高可用性和高可靠性。這種方法有助於提供更好的用戶體驗，並確保服務能夠達到業務需求。
SLO是否會隨時間改變，SRE應該如何應對？
SLO（Service Level Objective，服務水平目標）可能會隨時間發生變化，而且應該根據服務的需求和環境變化進行調整。SRE（Site Reliability Engineering，網站可靠性工程）團隊應該定期檢討和調整 SLO，以確保它們仍然反映了用戶的需求並支持業務目標。
SRE中常用的SLI有哪些？
可用性 SLI： 這是衡量服務是否可用的指標，通常以百分比表示。例如，一個常見的可用性 SLI 是 “99.9% 可用性”，表示服務每個月只能有不到 0.1% 的停機時間。
延遲時間 SLI： 用來衡量服務處理請求的速度。這可能包括平均請求延遲時間、百分位延遲時間（例如 P95、P99）等指標。
錯誤率 SLI： 這是用來衡量服務處理請求時發生錯誤的頻率。錯誤率 SLI 可以根據不同類型的錯誤進行區分，例如 HTTP 500 錯誤、數據庫查詢錯誤等。
吞吐量 SLI： 用來衡量服務處理請求的速度。吞吐量 SLI 可以是每秒處理的請求數或其他相關指標。
可擴展性 SLI： 衡量系統的擴展性，通常以負載測試的結果來表示。這可以包括最大同時連接數、並發請求數等。
資源使用率 SLI： 用來衡量服務使用的硬件或軟件資源（例如 CPU、內存、網絡帶寬）的利用率。高資源使用率可能會導致性能問題。
故障回復時間 SLI： 衡量系統恢復正常運行所需的時間。這可以是從故障發生到服務恢復的時間。
事件管理在維護SLA中有多重要？
即時響應和恢復： 事件管理有助於即時檢測和響應服務中的問題和故障。當 SLI（Service Level Indicator，服務水平指標）未達到 SLO（Service Level Objective，服務水平目標）時，事件管理使得團隊能夠迅速識別問題並采取必要的措施來恢復服務，以確保 SLA 的達成。
減少潛在的影響： 有效的事件管理可以減少故障和問題對用戶和業務的影響。透過快速識別和處理事件，可以縮短故障的持續時間，減少數據損失，提高用戶滿意度，並減少潛在的金融損失。
監控 SLI： 事件管理可以用於監控 SLI，以確保服務的性能和可用性處於預期水平。當事件管理系統警報時，它們通常是基於 SLI 的閾值，這有助於確保團隊可以快速回應 SLI 未達到 SLO 的情況。
持續改進： 事件管理不僅僅是問題的快速解決，還包括事後分析和根本原因分析。這些分析有助於識別和解決反復發生的問題，從而提高服務的可靠性，進一步確保 SLA 的達成。
風險管理在設定SLO中扮演什麼角色？
風險評估： 風險管理幫助確定可能影響服務性能的各種風險因素，包括硬件故障、軟件漏洞、網絡問題、安全攻擊等。通過評估這些風險，可以更好地了解潛在的問題和危害。
定義 SLO： 風險評估幫助確定了服務需要達到的最低性能水平。根據風險，可以設定不同層次的 SLO。對於高風險的服務，可能需要設定更嚴格的 SLO，以確保在面臨風險時仍然能夠滿足用戶需求。
可接受的風險水平： 通過風險管理，可以確定業務可以接受的風險水平。這有助於確定 SLO 是否在這個風險水平內，並確保業務在風險下運營仍然是可行的。
訂定緊急計劃： 風險管理也涉及制定應對風險的計劃和措施。這包括制定應急方案，以應對可能發生的問題，並確保即使面臨風險，服務也能夠快速恢復正常運行。
持續改進： 風險管理是一個持續的過程，它有助於不斷評估和減少風險，同時確保 SLO 的目標仍然是合理的。隨著時間的推移，風險可能會發生變化，因此需要持續監測和調整 SLO。
結論
總之，理解和有效實施 SLA、SLO 和 SLI 對任何網站可靠性工程師來說都至關重要。這些指標不僅確保服務可靠性，還將技術努力與業務目標保持一致。隨著技術的持續發展，這些服務監控指標周圍的策略也將變化，使得在SRE工程師需要在領域取得成功的關鍵，則在於不斷學習和適應。
參考連結
SRE fundamentals: SLIs, SLAs and SLOs
Defining SLOs for services with dependencies—CRE life lessons
