SRE — 反脆弱性與學習

1. 從故障中學習
2. 反脆弱的效益
3. 組織變革

從故障中學習

透過反脆弱性我們可以優化以下指標:

• MTTD(Mean time to Detect) — 要偵測的是故障與事故
  透過引入故障，我們可以優化監控能力，使我們更有可能偵測到真實事故
• MTTR(Mean time to Recover) — 要回復的是服務中的各組件
  模擬組件故障使我們能夠建立自動化去嘗試自動恢復。我們還可以增強韌性以防止單一組件故障。
• MTRS(Mean time to recover Service)
  混沌工程方法識別跨服務的關鍵介面和依賴項，精確指出可能需要更高韌性的領域
• SLO(Service Level Objects)
  對資料庫進行演習，例如讓資料庫下線可能會讓我們的SLO不達標。使用快取機制來應對資料庫下線的資料不可用也可能讓我們的SLO達標。
• RPO(Recovery Point Objective)
  引入故障，例如meaasging queue呈現資料遺失過多，會超出 RPO。可能需要更頻繁地備份queue data才能滿足 RPO

組織變革

改變組織成為高效能的SRE團隊會有以下四個部分。而唯一真正的錯誤是組織沒有從故障中學到任何東西。

運用DevOps三步工作法的第三步 — 持續的實驗與學習

這一原則讓組織的文化中培養兩件事:

1. 持續學習，承擔風險並從失敗中學習
2. 認知到重複的持續練習是精通的先決條件

未達成這兩件事組織需要:

1. 分配時間來改善日常工作
2. 創造獎勵團隊冒險的儀式
3. 將故障引入系統以提高韌性
4. 規劃安全的實驗和創新的時間(例如黑客松)

文化的轉變 — Westrum Model

高度信任的組織鼓勵良好的資訊流動，跨職能的協作，共享的責任，從失敗與新思維中進行學習。所以組織的文化跟資訊的流動有非常大的關係。根據社會學家 Ron Westrum的理論，他將組織分為三種並且與資訊流動相關性如下。

導入演習

演習建立在已存在數十年的 BCP 和 DR 概念之上。這是確保企業在發生不可預見的事故或故障（例如自然災害或緊急情況）時能夠繼續營運。而且這通常是稽核需求。對許多組織企業來說，這是年度資料中心故障轉移測試。而演習對於朝向渾沌工程是良好的第一步。

演習可以超越單一技術的地方在於:

• 設施故障 — 資料中心或雲端的整個region掛掉
• 技術遺失 — 例如資料庫掛掉
• 資源的遺失 — 例如很厲害的員工工程師
• 重要的第三方供應商無法支援

甚麼是渾沌工程?

混沌工程是在生產環境中對軟體系統進行實驗的學科，目的是建立對系統承受動盪和意外條件的能力的信心。 最著名的例子是 Netflix 的《Simian Army》。渾沌工程通常有以下步驟:

• 將系統拆分出關鍵組件
• 在關鍵組件可用的情況下測試系統
• 搞掛系統(先在非正式環境中執行)
• 在正式環境中將故障導入關鍵組件
• 將故障導入整個系統

事後回顧:

1. 檢視"整體"日誌，例如是甚麼讓整個服務是活著的
2. 辨識相依性
3. 透過Error handling和recovery進行優化(從手動變自動)
4. 從真實的故障中學習

爆炸半徑

渾沌工程同時也協助我們將事故/故障的影響範圍最小化。而任何中斷都應盡可能減少對整個體系的影響。故障測試可以呈現該半徑的目前跨度。

自動化恢復應該遵循以下步驟：

1. 建立不可變的IaC
2. 透過自動化測試涵蓋所有系統狀態和功能代碼
3. 佈署一個整體性的日誌與監控系統 — 讓服務具"可觀測性"
4. 實施智慧告警、智慧觸發器和規範分析(prescriptive analytics)
5. 在最合適的地方建立能自我修復的基礎設施/應用程式
6. 測試、測試、不斷的測試

而自動擴展機制，如K8S或AWS Auto-Scaling能夠:

1. 偵測伺服器或容器的受損實例並銷毀/替換
2. 將基礎設施維護在代碼定義的級別
3. 根據需求自動擴展基礎設施/應用程式
4. “即時”執行維護命令，例如更換Image
5. 與監控服務整合