# SRE 簡介
# What
SRE 就是由軟體工程師來負責維運工作的設計和執行。
# Why
由熟悉軟體的軟體工程師來負責系統維運，更能掌握軟體、系統間的交互運作關係，他們能在整個應用程式生命週期中瞭解對方的程序，藉此強化發行週期
# Feature
| Feature | Detail |
|---|---|
| Reliability | 確保服務的可靠性，不論運行的服務是成功還是失敗，前提是要可用的狀態 (Monitor) |
| Appropriate | 適當的可靠水準，根據系統使用級別的不同來決定維持可靠性的成本，規劃運行時間與停機時間 (Error Budget) |
| Sustainably | 確保工作的可持續性，也就是開發系統的長時間可靠性 (自動化運維) |
# DevOps vs SRE
如果將 DevOps 視為程式的介面的話，那 SRE 就是他的實作
| DevOps | SRE |
|---|---|
| 減少組織之間的穀倉效應 | 在整個開發週期中，和開發團隊使用相同的工具以及環境 |
| 接受失效，視失效為開發週期中的一個元素 | 對於新的版本，建立一套可以量化的指標去衡量 "意外" 和 " 失效” |
| 逐漸改變 | 鼓勵團隊透過快速交付，來達成降低排除故障的成本的目的 |
| 善用工具和自動化 | 鼓勵團隊把自己今年的工作自動化，最小化” 工人智慧” 要做的事，把精力放在中長期的系統改善 |
| 任何事都是可以被量測的 | 相信維運是軟體工程的範籌，規範關於可用性，運行時間 (uptime)，停機時間 (outages) |
# 服務水準指標 (Service-Level Indicator, SLI)
Google Cloud 的服務水準指標 (Service-Level Indicator, SLI) 是用來衡量服務的使用情況的量化指標，類似對服務的健康狀態設定效能衡量。
SLI 範例：
- 請求延遲
- HTTP 狀態碼為 200 的回應次數，佔總回應次數的比率
# 服務水準目標 (Service-Level Objective, SLO)
測量了 SLI 之後，我們要為系統可用性設定一個更精確的目標，重點是要與一段時間做掛勾來衡量服務期望狀態、目標範圍，我們把這個命名為系統的服務水準目標 (Service-Level Objective , SLO)。
# 服務水準協議 (Service-Level Agreement, SLA)
SLA 通常是關乎對服務使用者的承諾，是一項基於 SLO 制定的商業合約，當中會承諾其 SLO 應在一段時間內達到特定水準，若未達到一段時間內保證的目標則會產生罰則，比如向客戶退款，或免費提供客戶更長的服務訂閱時間等。超出 SLO 會傷害到整體業務團隊，因此服務應努力保持在 SLO 內。
# Error budget
SRE 提出的概念是 Error Budget，所謂的 Error Budget ，其實就是你的 SLO 扣掉之後剩下的就是你可以出錯的空間。
這個 Budget 空間非常的有用，因為在你的 SLO 不變的前提下，這就是允許你做調整及修正的空間，這個容錯空間會是 shared，在 SRE team 跟開發團隊之間的一個共享的容錯空間。這就是 SRE 觀點內，蠻重要的一個關鍵，去影響你的創新跟穩定之間的平衡點在此。
# 50% 原則
意思是只能有 50% 的時間再處理 ticket、on-call、手動要做的事情上，剩下的應該去研究如何自動化 以及高效率的完成。
# 總結
總結來說，SRE 將軟體工程的原則應用於運維工作中，通過自動化、監控、容量規劃等手段，提高系統的可靠性和可維護性。SRE 和 DevOps 緊密合作，以實現更高效、更可靠的服務運營。
