SRE Team Lifecycles

整理並且簡譯 Google Blog 文章：Do you have an SRE team yet? How to start and assess your journey 的摘要，這篇文章描述如何建立 SRE 團隊，以及三種階段的 SRE 團隊。

簡譯

標題：你還沒建立 SRE 團隊？如何開始評估？

SRE: Just getting started

三個 SRE 實踐的關鍵原則：

必須定義一些 SLOs (Service-Level Objectives)，符合最近幾個月遭遇的問題
不究責得事後檢討會議 (Blameless Postmortems)
建立全面性的 Production 的事件管理程序

Beginner SRE teams (初階 SRE 團隊)

Google 會以這些基礎 (fundamental) 來確認是否為有效率的 SRE 團隊：

人員配置與招聘計畫
團隊有 on-call，並負責部分的服務
針對 Release 程序文件化，包含開始、結束等生命週期管理
有 Canary Release 程序
Rollback 機制
針對維運設計的 playbook or runbook
災難還原測試
SRE 的執行計畫工作，這些工作是 Developer 看不到，而且不會有立即性效果的，但會減少維運工作量

除了上述，底下通常也是必要的：

足夠的 On-Call 工作，用以實踐 production 緊急事件處理 (每週)
SRE 團隊的規章由團隊以外的管理階層 (像是 CTO) 審核
固定時間，SRE 與 developer 針對問題討論、分享、目標
專案規劃由開發者與 SRE 共同規劃工作項目，管理者才能從中看到 SRE 的價值與影響

Intermediate SRE teams (中階 SRE 團隊)

必須包含以下特性：

週期性的與業務管理者 (Biz Leader) 檢核 SRE 工作與影響
週期性與業務管理者檢核 SLIs 和 SLOs
瑣碎時間減少到 50% 以下
Rollback 機制可以處理 Canary 故障
週期性測試事件管理流程 (類似於 Chaso Monkey)
週期性檢核事後檢討與產出行動
週期性災難還原測試
使用主動性的容量預測，判斷線上是否有足夠的容量
有長期計畫，像是年度計畫

Advanced SRE teams (進階 SRE 團隊)

底下是更進階、資深的 SRE 團隊具備的特質：

團隊中有一些角色，可以對商業產生影響
專案的影響是橫向的，同時可以影響多個服務
大多的告警是以 SLOs 為基礎
災難還原是自動化的

結語

這篇文章其實是 The Site Reliability Workbook Chapter 22 SRE Team Lifecycles 的整理。

相關文章 (站內)

SRE 相關

延伸閱讀 (站外)

Comments