SRE，了解一下？35+歲程式設計師新選擇
摘要：隨著雲業務的發展，今後會有越來越多的工程師深入到SRE領域。
本文分享自華為雲社區《淺談SRE角色認知》，作者： SRE確定性運維。
一、什麼是SRE？
SRE（Site Reliability Engineer）從2003年被Google公司提出，已經將近20年，它不僅是一個崗位，而是一個體系化的工程。最早Google公司提出SRE是為了解決兩個核心衝突點：1、開發、運維兩個團隊在上線速度和現網系統穩定性之間的衝突；2、軟體的快速上線，模糊了運維和研發的邊界。GoogleSRE通過軟體工程技術，持續改進現網可用性和自動化運維能力，SRE作為一個新的技術崗位走上歷史舞台。
SRE是站點可用性工程師：強調軟體和系統工程能力，SRE需要編寫自動化腳本，優化和改進配置。寫程式碼是必須的技能要求，因為程式碼是支撐工具開發和自動化的手段，但不鼓勵寫大量程式碼，希望能通過簡單的工具或者配置解決問題。
SRE素質能力模型主要有：軟技能（合作、溝通、獨立解決問題），實踐經驗（IT運維、基礎設施、安全等），流程和框架（DevOps、敏捷等），新技術（CICD工具、微服務升級與API）。
二、云為什麼要走SRE道路
雲業務相較傳統業務存在兩個變化，運維對象和運維模式都發生了本質改變，傳統運維模式已不能滿足要求，運維專業必定向SRE發展。
面向運維對象的四點變化：
1）傳統產品局點規模海量，單局點規模有限。但云業務單系統就支援幾十上百萬的伺服器規模；
2）傳統IPD版本周期長達半年，DevOps模式1～4周一個版本；
3）雲計算L0～L4堆棧複雜，系統整體可用性依賴全棧可用性；
4）運維對象不是可批量交付的成熟產品，而是微服務架構下的不斷演進的服務組件，同時各個行業的特質也會發生變化。
商業模式改變引起運維模式的變化：
1）商業模式轉變導致運維的責任邊界產生變化，傳統模式客戶服務運維，廠家做二線保障。現在需要端到端負責可用性設計以及1/2線運維，這種模式下，僅靠後端保障可用性是不夠的，需要介入前端頂層架構設計。
2）傳統模式只對交付的產品可靠性負責，不需考慮周邊可用性制約因素，但是作為服務運營商，需要對服務全棧可用性負責。
3）傳統模式，運維人員只是對運維繫統的使用者，但是現在除了使用者外，還是運維繫統的建設者，由最懂現網業務的SRE主導設計和開發運維工具。
三、SRE角色認知
有別於傳統運維工程師，SRE在服務生命周期中扮演以下三個關鍵角色：
1）現網可用性的守護者。是現網的Owner，守護現網穩定性是SRE的第一職責，圍繞現網保障會建立一整套的事前、事中、事後的SLA保障體系和能力。事前：監控告警、變更管理、容量管理、重大保障、應急演練等一系列業務活動。事中：事件管理、warroom、應急恢復能力。事後：故障Postmortem、現網數據分析、通過現網數據持續驅動產品改進。SRE強調全棧、端到端能力，是系統性專家；
2）系統高可用性的設計者。是高可用設計的Owner，聯合產品研發圍繞SLI/SLO目標設計服務高可用，將高可用軟體架構和工程方法應用到產品。SRE作為高可用性設計的專家參與到產品設計和上線活動中，運用系統和軟體工程科學解決產品可用性問題；
3）運維軟體工程能力的構建者。用軟體工程的思維和方法管理現網，通過可信開發構築系統可用性和自動化能力。打造安全可靠的運維平台，建設自動化運維服務，支撐雲服務的高可用落地，提升運維安全和運維效率。持續關注業務和技術發展，引入並採用業界新軟體技術，引導系統優化演進，圍繞運維業務目標，構築運維領域技術競爭力。
四、SRE素質能力要求
相對傳統運維，SRE需要既懂開發，又懂運維，能端到端參與產品研發生命周期全過程，圍繞高可用和自動化建立四大關鍵能力。
1）編碼能力是SRE的基本技能要求，強調軟體和系統工程能力；
2）具備「軟體工程」思維，要有站點和服務高可用設計能力，同時將高可用架構和軟體工程方法應用到產品研發過程；
3）有能力進行自動化研發，用自動化軟體完成運維和系統高可用性工作；
4）SRE要有SLI/SLO體系化設計能力，通過SLO將服務可用性顯性化度量。
同時，SRE要將現網優秀實踐經驗固化到流程規範中，形成一套可複製的標準化運維體系。
