SRE文化與工程原則

1）什麼是SRE文化

SRE文化是一套價值和實踐，可以使可靠性得到控制：SLO目標→錯誤預算→有意識的變化風險→快速穩定→事件培訓。
關鍵範式：可靠性的速度≠敵人。當風險被分配和自動化時，發行速度是可能的。

• 用戶中心：用用戶看到的方式表示可靠性（SLI/SLO）。
• 自動化第一：任何可重復的活動→腳本/策略/控制器。
• Blamelessness：錯誤-系統性,調查原因而不是人。
• 數據驅動：基於指標和錯誤預算的解決方案。
• Simplicity：簡單、可驗證的機制>「魔術」解決方案。

2） SRE基本工程原則

1.SLO/SLI和錯誤預算是優先級和排序的基礎。
2.事件→穩定→ RCA-首先是癥狀，然後是原因。
3.減少體力勞動（toil）-目標≤ SRE時間的50％，隨著時間的推移而降低。
4.準備就緒-「生產就緒」在外部流量之前是強制性的。
5.簡單和隔離-關系更少,觸發無線電的限制更多。
6.默認可觀察性是度量/logi/軌跡，SLO小部件，合成。
7.可管理更改-漸進式交付，金絲雀布局，自動滾動。
8.Security by design-秘密、可用性、審核、最低權限。
9.學習周期-演習，混沌遊戲，驗屍和回顧展。
10.FinOps正念是「九點價格」，成本服務，有效的SLO。

3）儀式和過程

3.1 Production Readiness Review (PRR)

• SLI/SLO，dashboard和Alertes（快速/慢燒傷）。
• 健康終點「/healthz」，「/readyz」，「/startupz」。
• Runbook/事件花花公子，所有者/呼叫中，逃逸鏈。
• Backups/DR計劃、資源限制、預算計算。
• 容錯測試（幻燈片標誌，滾回腳本）。

3.2每周SLO簡報

按服務劃分的錯誤預算狀態。
一周內的事件，CAPA進展。
發布風險：允許/限制派遣的地方（按預算）。

3.3 Mortham無罪指控

事實和時間線，用戶影響，幫助/阻礙。
系統原因（過程/工具）而不是「有罪」。
具有所有者和截止日期的特定CAPA，在公司內部進行宣傳。

3.4遊戲混亂和演習

計劃性故障註入（網絡，DB，緩存，noda）+目標SLO。
「遊戲日」：穩定時間，MTTR測量，花花公子調整。

4）警戒和噪音

• 僅在符號上發出警報：SLO或用戶路徑中斷。
• 多窗口、多燃燒：快慢通道。
• Quorum/反翻轉：延遲「for」，在維護時抑制。
• Doloy 「CPU> 80%」是進入死板的此類信號，不是傳呼機。

• Actionable的份額≥ 80％。
• Median時間到ack ≤ 5分鐘（P1）。
• 減少「Pager fatigue」：每位工程師每周≤ 1個晚上分頁。

5）變更管理

Progressive delivery: canary → 10% → 25% → 50% → 100%.

通過SLO信號自動回滾（錯誤/潛在性）。
Feature-flags和kill-switch代替全局回滾。
Change policy by risk: fast lane для low-risk;CAB只是高風險。

yaml steps:
- setWeight: 10
- analysis: { template: "slo-check" } # fail ⇒ rollback
- setWeight: 25
- analysis: { template: "slo-check" }

6）減少toil（例行體力勞動）

Toil來源示例：手動除塵器，重新啟動，tikets「訪問」，清理隊列。

• 可重復任務的清單→自動化/自我服務。
• KPI：toil，「自動步驟/事件」，「分鐘到自我服務」的時間百分比。
• 平臺服務目錄（namespaces，DB，隊列，dashbords，alertes）。

7）可觀察性和SLO第一設計

Golden Signals (latency, traffic, errors, saturation).

每個團隊的SLO卡：目標，窗口，預算，burn-alerta。
Drilldown：從指標到邏輯/軌跡；默認邏輯中的「trace_id」。
合成：blackbox+無頭腳本（登錄/deposit/checkout）。

8）設施管理和可持續性

能力規劃：目標RPS/競爭性，AZ/區域庫存。
Bulkhead/shedding：隔離池,首先拒絕次要功能。
背景和隊列：脫位控制，DLQ，自適應競爭力。
Failover和DR：RPO/RTO，常規DR鉆。

9）安全性作為可靠性的一部分

Secrets： Secret Manager, JIT訪問,審核。
外圍的WAF/DDoS守衛，對客戶/tenant的限制。
PII最小化，事件中的DSAR/法律保留。
供應鏈安全：工件簽名，基本映像策略。

10）健康的電子

沒有「單身」的輪換，清晰的休息窗口。
「晚上醒來」的門檻僅P1/P2 SLO。
Psychogyene：睡眠不足被記錄為手術風險。
指標：佩奇/奈德,夜間佩奇/工程師,恢復時間。

11） SRE成熟度量

SLO覆蓋：具有SLO/Alert的關鍵路徑的比例≥ 90％。
錯誤預算政府：有自由規則並適用。
Toil：≤ 30-40%的時間，趨勢下降。
MTTD/MTTR：季度動態中的中位數。
自動移動率：自動操作事件的百分比。
PRR通行率：已完成程序準備的版本比例。
Postmortem SLA：SEV-1-mortem ≤ 48小時。

12）文檔和知識

• Runbooks/Playbooks（頂級腳本：5xx spike，DB lag，Kafka lag，NodeNotReady，TLS）。
• SLO卡和行車記錄儀。
• PRR支票清單和發行模板。
• 平臺服務目錄和OLAs/SLAs。
• 培訓材料：SRE 101、Chaos 101、On-call 101。

13）反模式

英雄文化：「救援人員」而不是系統虛構。

嘈雜的警報： CPU/驅動器到尋呼機,數百個不必要的信號.

「DevOps是人」：塗抹責任，沒有業主。
缺乏SLO：「保持綠色」→優先混亂。
延遲的驗屍和「獵巫」。
沒有金絲雀的全球回滾。
Configa/Repo中的秘密；沒有活動審核。
Observability是「美麗的圖形」，沒有可操作的信號。

14）工件模板

14.1 SRE憲章（片段）

yaml mission: "Make reliability manageable and economical"
tenets:
- "User - SLI/SLO Center"
- "Automation-first, minimizing toil"
- "Blameless & learning"
governance:
error_budget:
freeze_threshold: 0. 8 # 80% of the budget burned ⇒ release frieze review_cadence: "weekly"
oncall:
paging_policy: "SLO-only, P1/P2 at night"
health_metrics: ["pages_per_week", "night_pages_per_engineer"]

14.2 Mini-PRR支票清單

• SLI/SLO和burn-alertes調音
• 健康終點和合成
• Runbook/花花公子+所有者/呼叫上
• Rollback/Fich-Flags/金絲雀
• Dashbords latency/errors/traffic/saturation
• 安全限制/配額/guardrails
• DR-plan和backaps測試

15）按階段實施（4沖刺）

Sprint 1-基礎

定義關鍵用戶路徑和SLI。
制定SLO並運行burn-alertes。
引入PRR和最小花花公子。

Sprint 2-變更管理

金絲雀布局，SLO上的自動回滾。
自我服務操作，服務目錄。
Toil庫存和自動化計劃。

Sprint 3-學習周期

後太平間儀式，混沌遊戲日歷。
Dashboard SLO+事件，錯誤預算報告。

Sprint 4-優化和縮放

SLO產品組合，FinOps 「cost per 9」。
實施DR紀律，安全審核。
KPI上電，預防倦怠。

16）迷你常見問題

SRE=「修復一切」？
沒有。SRE管理可靠性系統：SLO，Alerting，過程，自動化和培訓。

如何說服企業投資於可靠性?

顯示ROI： MTTR下降,轉換增加,SLA信用較少,低於成本服務,穩定發布。

是否需要單獨的SRE命令?

混合模型：戰略性SRE在關鍵產品的平臺+嵌入式SRE中。

底線

SRE文化不是職位，而是處理風險的方法：SLO →錯誤預算→可管理的更改→自動化→培訓。確定原理，建立儀式（PRR，驗屍程序，混沌遊戲），拍攝玩具，建立「默認」可觀察性，並註意其呼叫。因此您可以獲得穩定的開發速度、可預測的版本以及可靠、經濟高效的平臺。