SRE — 原則與實踐
- 什麼是SRE(服務可靠度工程)?
- SRE與DevOps的不同之處?
- SRE的原則與實踐
什麼是SRE?
SRE 是一門融合軟體工程各個面向並將其應用於基礎設施和維運問題的學科。也就是如果我們讓軟體工程師承擔過去所謂的維運任務時會發生什麼。
SRE的目標是建立大量可擴展性且高度可靠的分散式軟體系統。SRE工程師應該 花費 50% 的時間進行「維運的」相關工作,例如問題解決、on-call和手動干預,另外50%的時間應該就是開發任務,例如新功能,擴展性或自動化作業。而監控、告警與自動化也占了SRE作業的很大部分。
SRE與DevOps的不同之處?
以Google的定義來說,SRE 是 DevOps 的具體實現,並帶有一些延伸。Google定義DevOps有五個成功的支柱,分別是:
- 減低組織的穀倉效應
- 接受失敗是常態
- 進行逐步變更
- 運用工具與自動化
- 衡量任何事
SRE可以輔助DevOps,因為:DevOps 是一套實踐、指南和文化,旨在打破 IT 開發、營運、架構、網路和安全方面的孤島。而SRE 是有效的一組實踐、推動這些實踐的一些信念以及一個工作角色。
SRE的原則與實踐
原則一:維運其實是一種軟體問題
據估計,TCO的 40% 到 90% 是在軟體發布後產生的。而SRE的基本宗旨是,做好維運其實是軟體問題。所以SRE應該用軟體工程的方法來解決維運問題。而軟體工程作為一門學科是專注於設計和建造而不是維運和維護。
原則二:聚焦於服務等級
SLO需要一種後果,如果它無法達標的話。
SLO(Service Level Objective)是一種針對產品或服務的可用度目標,而這個目標永遠不會是100%。既使可以達到100%,我們的成本將遠遠高於效益。在 SRE 中,服務/產品由 SLO 主導。
原則三:減少過勞
SRE必須要有時間來優化服務,也就是明天要比今天更好(即使只有一點點)。所以任何手動且必要的維運作業都是很差的工作。所以如果該作業能夠被自動化,哪它就應該這麼做。SRE的作業應該要提供一種“生產智慧”,為更好的系統設計和行為提供資訊。
PS: 過勞的定義:
一種與維運"平台/產品/服務"相關的工作,往往是手動的、重複的、機械化的、臨時性的、缺乏長久價值的。
原則四: 運用自動化
SRE團隊要有能力能夠調節他們的工作負載。
- 自動化現行的手動作業
- 決定甚麼應該自動化以及如何自動化該作業
- 採用基於工程的方法來解決問題,而不是無限輪迴解決問題
- 自動化應該主導 SRE 的作業
- 不要為自動化而自動化,也就是自動化有問題的流程。而是先搞定流程
原則五: 減少失敗的成本
失敗為成功之母,因為它是一種優化機會。因為後期問題(因為產品缺陷)的成本很高,因此 SRE 尋找方法來避免這種情況。對SRE來說,MTTR(Mean time to repair)是一種要不斷優化的指標。所以我們不應該用大霹靂式的變更,而是用小量的變更。例如可以用金絲雀佈署(Canary Deployments)。
原則六:共同承擔責任
SRE會與產品開發團隊分享他們的技能。所以開發與維運團隊之間的邊界應該要被移除。SRE需要“shift left ”,並為開發團隊提供“生產智慧”。而目前非常多的組織的激勵措施尚未協調一致。