SRE體系及穩定性建設

• SRE
• • SRE概念
  • SRE的工作職責
• 大型互聯網的5個生命周期中SRE的職責
• • 代碼編寫
  • 資源規劃
  • 系統上線
  • 運行保障
  • 系統下線
• 穩定性建設
• • SLA
  • MTTR
  • 故障管理（三段式）
  • • 故障前
    • 故障中
    • 故障后

SRE

SRE概念

SRE在國內現在也叫應用運維，是面向用戶穩定性的，也就是說對用戶的服務質量負責，這也給了SRE更高的要求，要有全局視角，要對系統的全生命周期進行管理，把質量和成本工作做到前面，需要一系列的流程.制度.規范和一系列的工具提高管理、質量、自動化效率。

SRE以用戶穩定性為目標，業務對資源的規劃管理周轉效率、持續集成上線效率、質量管理效率等。

SRE的工作職責

• 1、保障線上服務的穩定性
• 2、建設工具/平臺/基礎設施 提升效率
• 3、用技術手段來控制、優化服務的運行成本

大型互聯網的5個生命周期中SRE的職責

代碼編寫

SRE的主要工作是搭建和維護代碼管理系統，為CI/CD做好準備，目前最常用的就是GitLab了。

資源規劃

• 1、方案評估
  根據需求規劃系統的基礎資源，包括機型（或容器規格）、機房、資源數量、存儲、4/7層接入方案、域名證書以及是否用CDN等。
• 2、資源申請
  將評估后的資源各自走審批流程。
• 3、資源管理
  對業務使用的海量主機、容器、域名、證書、LB、CDN、存儲、網絡、專線等資源進行管理，體量上來后一定要建設CMDB用系統管，各類信息做到可快速檢索，一般大廠存儲、CDN、網絡、專線都有專門團隊負責，SRE只要管好自己業務的使用即可，強調一點，資源一定要制定一套科學的命名規則。
• 4、權限管理
  大型系統人多、環境復雜，SRE需要對權限做詳細的規劃，制定SRE、開發序列對應每種資源新手和老工程師的權限規則，理想情況開發只要管好代碼即可，任何prod環境操作都只能由SRE處理，開發是不允許有root權限的，開發和測試環境視情況處理，所有操作做好審計方案。
• 5、資源操作
  因為面向的是大型互聯網系統，要保障對海量資源進行高效批量的操作，就需要借助一些技術工具了，比如主機操作類似ansilbe、saltstack，為了安全管理也要結合安全跳板機的使用，容器、LB、證書簽發等也都有對應的技術方案，這些是需要SRE來Ops的。

系統上線

• 1、環境規劃
  一個成體系的系統一般會有4套環境：開發環境（dev）、測試環境（stag）、預發布環境（prew）、生產環境（prod），環境之間相互獨立，視情況做網絡隔離，我在新浪碰到了幾次開發同學把測試環境的數據發布到了生產環境，造成很差的用戶體驗，所以規劃的時候，低安全等級的網絡到高安全等級加墻還是有必要的，SRE提前把環境規劃好、上線流程制定好，會減少很多變更類故障。
• 2、環境搭建
  主機環境配置，看似有了公有云、容器后，只要把鏡像做好，這塊工作要簡單很多，但其實也不然，首先相對云主機而言，物理機的性能高成本低，量能跑起來的前提下用物理機最劃算，所以公有云一般作為彈性資源；二是經過論證，不是所有的服務都適合上容器，所以現實情況還是會有大量的物理機運維，各種裝包、配置、內核和系統調優、維修、過保機器替換等，反而是在原來的基礎之上增加了打容器鏡像的工作，這就是實際情況，環境搭建、系統調優、軟件包升級的工作量還是很大，而且這塊工作經常會出現各種奇葩的事情，特別是搭建GPU機器學習的環境，不是這個庫不對那個依賴版本不對的，一搞就是半天，不過從趨勢上看這塊工作我覺得會越來越標準化。
  接入層配置，包含從域名、證書、解析、負載均衡4/7層、后端這一套配置流程，其中4/7層選擇、調度策略、連接數是否夠用等等都是需要根據具體業務情況制定技術方案。
• 3、CI/CD
  協同開發制定CI/CD的技術方案，為Dev提供部署系統（大廠有專門團隊研發），制定上線審批流程，按理生產環境的上線應由SRE操作，但因為開發和SRE的數量差距大，成長期的系統迭代又快，由誰上線就視情況處理了，我們這處理方式是牽涉到代碼變更的上線由開發操作，其余的遷移擴縮容等由SRE處理。

運行保障

SRE是質量擔當，面向的就是用戶穩定性，所以系統運行保障是SRE工作最重的階段，也是占用精力、工作量最大的部分，質量越好，意味著故障越少，下面就從故障全生命周期的角度對這塊的工作做個梳理。

• 1、故障前——目標：減少問題流入“故障中”
  ①變更管控
  ②容器管理
  ③災備建設
  ④業務巡檢
  ⑤活動重保
  ⑥故障演練
  ⑦日志管理
  ⑧技術調優
  ⑨服務管制
• 2、故障中——目標：快速發現故障，止損
  ①監控告警
  ②故障定位
  ③預案執行
• 3、故障后——目標：消滅同類故障
  ①故障復盤

系統下線

資源釋放

系統下線階段的主要工作就是資源釋放，不僅僅要釋放服務器，關聯的域名、LB、ACL等等資源要全部釋放，干干凈凈的來、干干凈凈的去。

穩定性建設

SLA

業內喜歡用SLA （服務等級協議，全稱：service level agreement）來衡量系統的穩定性，對互聯網公司來說就是網站服務可用性的一個保證。9越多代表全年服務可用時間越長服務越可靠，停機時間越短。就以一個標準99.99%為例，停機時間52.6分鐘，平均到每周也就是只能有差不多1分鐘的停機時間，也就是說網絡抖動這個時間可能就沒了。保證一個系統四個9或者更高的五個9，需要一套全體共識嚴格標準的規章制度，沒有規矩不成方圓。創建的規范有如下幾種：

• 1、研發規范、自身穩定；
• 2、事務中不能包含遠程調用；
• 3、超時時間和重試次數要合理；
• 4、表數據操作必須double check，合理利用索引，避免出現慢查詢、分庫分表不走分表鍵；
• 5、沒有有效的資源隔離， 避免不同業務共用一個線程池或連接池；
• 6、合理的系統拓撲，禁止不合理服務依賴，能依賴就依賴，否則同步盡量改成異步弱依賴；
• 7、精簡的代碼邏輯；
• 8、核心路徑流程必須進行資源隔離，確保任何突發情況主流程不能受影響。

MTTR

MTTR即平均恢復時間，里面包括了MTTI（平均識別時間）、MTTK（平均定位時間）、MTTF（平均恢復時間）、MTTV（平均驗證時間）。我們提供工具賦能、制定完備預案實現一鍵應急、平時自動校驗等來縮短整體MTTR的時間。

故障管理（三段式）

• 故障前：故障預防、災備預案
• 故障中：故障發現、故障定位、故障恢復
• 故障后：故障復盤、故障改進

故障前

監控體系的建設（構建立體化的監控：全鏈路監控）

• 基礎準備：監控大盤-基礎監控
• 基礎準備：監控大盤-SLA
• 基礎準備：監控大盤-日志
• 基礎準備：監控大盤-客戶端監控
• 基礎準備：監控大盤-客戶端監控
• 基礎準備：架構設計、 梳理
• 基礎準備：容量評估
• 基礎準備：災備預案/災備演練
• 基礎準備：災備預案/故障演練

故障中

• 故障管理—監控告警
• 故障管理-日志分析
• 故障管理-鏈路跟蹤
• 故障管理-預案執行
• 故障管理-恢復結果確認

故障后

• 故障復盤：關鍵時間線回顧
• 故障復盤：黃金三問
• 故障復盤：故障報告

總結

以上是生活随笔為你收集整理的SRE体系及稳定性建设的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。