可靠性工程

1）什麼是SRE，為什麼需要它

可靠性工程（Site Reliability Engineering，SRE）是開發和運營交界處的一門學科，可將可靠性轉化為可測量的產品屬性。SRE連接用戶體驗度量（SLI），質量目標（SLO），錯誤預算，自動化和托管更改，以更快地交付價值而不會失去可持續性。

關鍵目標：可預測的UX、快速發布、最低停機時間和可控的擁有成本。

2） SRE原則

可靠性作為遠景。優先於SLO和業務目標設定的限制。
錯誤預算控制更改的速度。如果預算被燒毀-關註穩定性。
自動化>手動操作。任何可重復的任務都是腳本/語句/引導線。
可測量性。只有測量的（SLI/SLO）才能改善。
Just Culture.無罪後面部表情，專註於系統原因。
Shift-left.質量，安全性，測試和可觀察性是開發周期的一部分。

3）組織和角色

平臺的SRE命令：共享工具，策略，pipline，GitOps，服務目錄。
嵌入式SRE （embedded）：與產品團隊一起工作,在SLO上實現聯合目標。
職責（呼叫中）：輪換，負載限制，補償，訓練。
RACI：服務的所有者，SLO的所有者，事件中的IC，Comms Lead，Scribe。

4） SLI/SLO和錯誤預算（產品捆綁）

SLI：可用性，潛在性，業務運營成功，數據相關性。
SLO：窗口目標28-30天+例外。
Error Budget = 1 − SLO.政策：發布，實驗，金絲雀和fichi受實際燃燒率的約束。
按隊列設計：區域，提供商，VIP段-單獨的SLO，以免失去異常。

5）默認可觀察性

指標：成功/錯誤，p50/p95/p99，saturation（CPU/mem/IO/conn）。
Logs：結構化,具有查詢/版本/標記的相關性。
Tracing：端到端的延遲和錯誤映射,熱路徑。
合成+RUM：外部采樣和真實客戶遙測。
SLO dashbords：預算下降，發行註釋，金絲雀，提供商。

6）變更與發行管理

Pipline CI/CD：確定性裝配、工件簽名、安全掃描、合同測試。
漸進策略：金絲雀/藍綠色/陰影；具有生命周期的幻燈片標誌。
Gate's quality： policy-as-code, SLO-guardrails,退化時自動回滾。
GitOps：配置/策略作為代碼,在星期三促銷,審核。

7）事件和後面面孔

SEV/P級別聲明,IC立即分配,SEV-1+發布凍結。
Burn-rate alerta：短而長的窗口，按區域和樣本類型劃分的法定人數。
花花公子：回滾，退化，收費提供商，限制/撤退。
RCA和CAPA：事實，因果關系，可測量的行動，控制點（D+14/D+30）。
知識目錄：我們重新使用模板和課程。

8）可靠性測試

微服務合同測試和消費者驅動合同。
按實際模式的負載配置文件,p99 測試/GC暫停/隊列尾巴。
Chaos/Resilience案例：關閉依賴項、網絡、延遲；遊戲日和DR演習。
DB遷移：expand→migrate→contract，可逆性，兩個版本的兼容性測試。

9）容量與成本管理（FinOps）

Capacity Units和headroom在關鍵路徑上。
HPA/VPA/KEDA按用戶指標和隊列滯後。
多供應商：配額，SLO/潛伏路由，自動收發器。
單元經濟學：$/1k查詢，$/成功交易；優化緩存、日誌、egress。

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

SAST/DAST/SCA，秘密搜索，SBOM，映像簽名。
mTLS和訪問策略（OPA/ABAC）；最低特權。
關鍵字/證書輪換，截止日期控制，測試到期方案。
安全事件-單獨的花花公子，強制，監管通知。

11）文化和過程

SLO評論：每周/每月，債務優先於「紫羅蘭」。
培訓和模擬：電話培訓，事件排練，混沌日。
統一標準：準備就緒檢查單，通信的SLA，後太平間格式。
Alert疲勞指示器：噪音≤目標閾值,定期調諧。

12）SRE函數的成熟度量

DORA度量：降級頻率，領先時間，MTTR，更改失敗率。
SLO執行：綠區服務份額，燃燒率趨勢。
Alert衛生：分頁活動的百分比，Alert/班次的中位數，假比例。
RCA/CAPA：按時執行，系統性（非個人）原因的比例，reopen-rate。
費用：$/SLO項目，$/1K查詢，自動軌道的效率。

13）「服務準備就緒」支票清單"

• 由SLI/SLO，SLO所有者和監視窗口定義。
• Dashbords和burn-rate alerta定制，有外部合成。
• 管道：簽名/掃描,合同/集成測試,金絲雀/標誌,自動滾動。
• DB遷移是可逆的，負載輪廓覆蓋峰值。
• 事件花花公子和供應商聯系；狀態頁面。
• Capacity headroom已確認；HPA/KEDA和提供商配額已驗證。
• Configi和政治家-在Git中，周三的促銷活動包括審計。
• Security：代碼外秘密,mTLS/輪換, TLS時機受控。

14）反模式

«99.999％或什麼都沒有"-無法實現的目標→永恒的紅色燃燒率。
沒有金絲雀和幻想旗的發行→大爆炸。
一個監控點→虛假警報和跳過。
手動更換銷售中的configs →漂移和不可操作性。
沒有CAPA的後太平間→反復發生的事件。
SRE是「消防員」，沒有改變建築的權利→債務不會關閉。

15）SRE實施路線圖（3-6個月的示例）

1.第1個月：服務和關鍵路徑清單；SLI/SLO草稿；基本的dashbords和burn-rate alerta；開始呼叫。
2.第2個月：金絲雀/幻燈片，自動回滾；GitOps configs；事件花花公子目錄；狀態頁面。
3.第3個月：合同測試，負載配置文件，DB expand/contract方案遷移；第一個遊戲日。
4.4-6月份：多供應商路線，DR演習，成本優化，成熟度量標準，團隊的KPI。

16）結果

SRE是一個開發操作系統：透明的質量目標（SLO），可控的變更率（錯誤預算），自動化和事件紀律，穩定性測試以及有意識的成本。通過這種方法，發行成為常規，可靠性成為競爭優勢。