天天看點
傳回

讀《SRE：Google運維解密》一點思考

0、為什麼誕生SRE？

  • 原因一：企業成本的增長通使用者的增長不成線性變化。但是随着系統的複雜度提升，組建越來越多，使用者的流量壓力也越來越大，相關的變更也會越來越多，各子產品之間的變更順序也會越來越複雜。在這樣的情況下，單純的靠運維人力的數量提升無法滿足業務的發展需求，而且會提升企業的成本；
  • 原因二：傳統的研發團隊和運維團隊天然具有沖突。公司的IT人員的配置：研發（Dev）和運維（Ops），研發部門聚焦在快速建構和快速釋出；運維部門關注的是如何避免發生故障，從目标上将就是沖突的。且随着IT技術的發展，對IT從業者的要求也越來越高，既要懂得底層系統，也要懂得資料算法，同時對主流技術還要快速追趕，滿足這樣要求的人才太少；
  • 原因三：生産工具為适配生産力發展的必然産物。為了提高IT行業的整體效率和品質，使得從手工運維時代，逐漸過度到腳本工具運維，在發展到平台資料運維，再到平台軟體運維，在發展到智能自動化運維。通過一系列手段、工具、理念的進步，将Ops技術發展到DevOps、DataOps、AIOps等；

一、什麼是SRE？

1.1 SRE的基本了解

  • 那麼差別于研發同學和運維同學，SRE要做一些什麼工作，又要具備什麼樣的能力呢？
Google試從解決Dev和Ops之間的沖突出發，雇傭軟體工程師，創造軟體系統來維護系統運作以替代傳統運維模型中的人工操作。SRE團隊和産品研發部分在學術和工作背景上非常相似，從本質上将，SRE就是在用軟體工程的思維和方法論完成以前由系統管理者團隊手動完成的任務。
  • Google的SRE具體會負責哪些
SRE在Google不負責某個服務的上線、部署，SRE主要是保障服務的可靠性和性能，同時負責資料中資源配置設定，為重要服務預留資源，SRE并不負責某個業務邏輯的具體編寫，主要負責在服務出現當機等緊急事故時，可以快速作出響應，盡快恢複服務，減少服務掉線而造成的損失。
  • SRE日常工作和職責包含哪些

一般來說，SRE團隊要承擔以下幾類職責：可用性改進、延遲優化、性能優化、效率優化、變更管理、監控、緊急事物處理以及容量規劃與管理。

Tools Don't create reliability. Humans do. But tools can help.

  • SRE的使命

在減少資源消耗的同時，從可用性和性能層面，提升使用者的體驗。

Operations should NOT be a part of SRE missions. Operation is a way to understand production.

在書中對各個職責有較為清晰的說明，感興趣的朋友去可以翻翻原文，這裡就談一下個人的體會。

1.2 SRE的技能堆棧

  • 語言和工程實作
    • 深入了解開發語言（Java/Golang等）
    • 業務部門使用開發架構
    • 并發、多線程和鎖
    • 資源模型了解：網絡、記憶體、CPU
    • 故障處理能力（分析瓶頸、熟悉相關工具、還原現場、提供方案）
    • 常見業務設計方案，多種并發模型，以及相關 Scalable 設計
    • 各類底層資料庫和存儲系統的特性和優化
  • 問題定位工具
    • 容量管理
    • Tracing 鍊路追蹤
    • Metrics 度量工具
    • Logging 日志系統
  • 運維架構能力
    • Linux 精通，了解 Linux 負載模型，資源模型
    • 熟悉正常中間件（MySQL Nginx Redis Mongo ZooKeeper 等），能夠調優
    • Linux 網絡調優，網絡 IO 模型以及在語言裡面實作
    • 資源編排系統（Mesos / Kubernetes）
  • 理論
    • 機器學習中相關理論和典型算法
    • 熟悉分布式理論（Paxos / Raft / BigTable / MapReduce / Spanner 等），能夠為場景決策合适方案
    • 資源模型（比如 Queuing Theory、負載方案、雪崩問題）

二、SRE是如何解決問題的？

2.1 解耦中台系統與應用

  • 研發同學為生産環境負責，而SRE為元件或叢集的可服務能力和穩定性負責

    SRE工程師中大部分是标準的軟體工程師，他們擅長使用系統工程的方法去解決基礎系統中的問題，同時持續的、工程化的解決問題，使得運維的壓力不會随着上層應用的增加而線性增加（通常20人的SRE團隊，可以支援上千研發同學的應用開發）。同時SRE同學對Unix系統内部細節、1～3層網絡比較了解，可以同研發一起分析應用程式性能問題。

  • SRE應該更好的進行系統中繼資料的管理

    系統的中繼資料應該是系統的架構拓撲圖，通過動态、準确的更新中繼資料可以将采集到的Event、Message、Metric等資料映射到真實環境中去，并能通過各種手段進行系統健康程度的診斷，是的自動化監控和管理成為可能。

  • SRE通過穩定性進行抽象，可以通用的解決穩定性問題

    為了讓龐大系統的運作效率提高，要不斷的優化系統中的熱點，并将系統中的熱點服務擴充、更新、重構成為一個組建化的服務，這也是SRE中解耦系統的方法。不僅如此，SRE對各個服務的可用性進行标準化定義，将統一的标準應用到不同的服務中去，将穩定性作為各個服務的重要度量名額，通過上述操作，收攏服務治理問題，提供系統的魯棒性。

2.2 明确服務之間的可用性依賴

2.2.1 面向SLO程式設計标準的推行

讀《SRE：Google運維解密》一點思考

針對SLO，我們舉一個例子來說明以下，

讀《SRE：Google運維解密》一點思考

為什麼要有SLO，設定SLO的好處是什麼呢？

  • 對于客戶而言，是可預期的服務品質，可以簡化用戶端的系統設計
  • 對于服務提供者而言
  • 可預期的服務品質
  • 更好的取舍成本/收益
  • 更好的風險控制(當資源受限的時候)
  • 故障時更快的反應，采取正确措施
注：

2.2.2 面向SLO監控的設計 --- SLO結果導向的告警，而不是原因導向的告警

四個黃金信号
  • 當平台服務不可用，或通路速度變慢時，往往會影響到産品的整體品質，目前了解到的一些基礎監控名額就達到上百種，通常的做法是在這些名額當中需要選取平台或業務比較關注的名額進行監控報警；
  • Google的網站可靠性工程師小組（SRE）定義了四個需要監控的關鍵名額。他們稱之為“四個黃金信号”：延遲（Latency），流量（Traffic），錯誤（Errors）和飽和度（Saturation）。這四個信号應該是服務級别非常關鍵部分，因為它們對于提供高可用性的服務至關重要。
如何定義高品質的監控：
  • 明确業務服務的SLO（應該與該業務提供給客戶的期望達成一緻），并采用合理的SLI來描述；比如計數資訊（總量、成功量）、測量資訊（同比、環比）；
  • 主觀上監控應該有豐富的内部狀态資料、具備高可觀測性條件；客觀上具備業務視角，能夠快速定位是全局問題還是局部問題；系統本身的魯棒性，不會因為某個局部問題影響監控的權威性；具備quota限制能力，防止出現容量的問題；
  • 報警清理和定期的規則優化，定期進行盤點告警，并優化掉無SLO影響的規則；

2.3 完善的場景化演練

自動化系統的建設中除了要考慮系統的能力外，還要考慮人在其中所發揮的重要作用，畢竟一旦一些突發的時事件若必須由人來處理，則這時刻人的穩定性和準确性也是需要保證的。微軟在SRE大會中提出了一個有意思的觀點：如果一個系統能夠比人做的更好，那人應該知道如何監控這個系統本身。是以，在保證SLO的情況下，可以做一些攻防演練（關閉SRE系統的UI後，SRE該如何操作？）；或建構一個模拟系統，讓人來執行系統；并學習故障的複盤報告等。

三、淺談SRE的觀察

3.1 從SRE2019觀察

SRE CONF 2019 傳送門：
推薦幾篇不錯的Session：

3.2 幾個應該多花精力關注的點

  • 系統的可觀測性，換句話說是你真的了解你的系統麼？你真的了解你的應用麼？（不僅是背景系統、還有一些移動端系統和應用）要從Logs中索取更多的知識，挖掘出更多的内容供SRE使用
  • 随着觀測性要求的不斷提供，靈活、新穎的可視化工具被大家越來越認可，單獨使用線圖進行可視化名額是遠遠不夠了，需要更加新穎和便捷的可視化方案；同時要讓資料産生價值，而不是簡單的可視化，越來越多的公司使用Pipeline來解決相關任務的建立和管理，讓資料清洗和規整後變的更優價值，使得算法産生最大的效用
  • SRE不僅僅要發現系統中存在的熱點問題，也要能快速解決這些熱點問題，并在以後的架構演進中消除這樣的問題，則系統的自愈能力應該成為每個公司都關注的問題
運維 監控 kubernetes 資料可視化 算法 Linux 應用服務中間件 分布式資料庫 nginx 容器 sdk google.com ssl google.com google官方下拉重新整理 google附源碼 海外google跳轉
上一篇: 5G架構之NFV和SDN | 《5G移動無線通信技術》之十一5G架構
下一篇: AutoScaling 伸縮組活動流程暫停與恢複

繼續閱讀