關於Google SRE工程師

  今天下午，本身從新思考了一些SRE(Site Reliability Engineering)，略談談SRE的相關概念與自身實踐。

  相信你們可能不多或則沒有聽過SRE這個名詞，我會簡單的分析一下關於SRE工程師，固然，這僅僅是讓你們對SRE有一個初略的概念性理解，若是須要有更深刻的理解, 請你們去看<<Google運維解密>> 或官網  landing.google.com/sre/​

landing.google.com

什麼是SRE工程師

  提到SRE工程師，必須得先提到運維工程師，我從運維這個角度切入到SRE。你們對運維工程師的認識應該會普遍，一提到運維工程師腦海裏都是系統管理員，網管等標籤，也會認爲工做也是低效重複，技術含量相對較低，在公司裏地位也會偏低，能夠說相對最苦逼了，其實真實狀況大體也如此。最近幾年devops比較火，devops給運維帶來了新的活力和更大的空間，用程序去自動化一部分系統，可能會包括自動化代碼構建，部署流程，相關係統軟件安裝，監控，告警等一些自動化工做，這個level看起來會更高一些，也能解決系統大多數重複工做。不過在該模式下，在公司服務到必定規模，或高速發展中，想繼續保持效率和保證服務高SLA，須要招聘更多人去作系統的維護與系統研發。在同事的引薦下，看到<<Google運維解密>>，裏邊介紹了Google提出的概念SRE, 並講述了Goole在運維複雜系統中的運維實踐，也提供了一些新的運維方法論，用程序去自動化整個系統，工程師直接參與研發，設計，維護，優化整個系統，而且在這個長期過程當中，總結了一些重要的方法論。

  能夠看出來，在Google ‘運維'工做內容再也不有低效，重複，技術含量低的相關標籤了，他們須要去有研發工程師的編碼能力，比研發更深刻理解操做系統，計算機網絡，數據庫，甚至到架構設計等模塊，相應要求也會更高。最近也看到，國內也有不少公司也在學習一些SRE的方法論，在招聘上能夠看到不少SRE相關的招聘，或則是不少運維或系統架構師，devops崗位中有一些SRE的相關標籤，筆者的目標方向是架構師，也會在工做中也會去學習應用SRE的一些方法論。

關於Google在SRE中實踐

  爲何Google會提出相似SRE相關運維概念？其實不是，國外像facebook, twitter, 國內一些大廠相信確定都有本身的運維體系，或則是軟件維護服務的高可用方法論，只是Google先提出來SRE這個概念，而後其開源的文化推進它將其開源，這裏不得不稱讚Google以超強的實力和超前的眼光，將運維這個職業作成世界上最高端的技術工種之一,給業界提供了一種運維方法論。

Google維護着幾乎全球最大的服務器集羣，我只從 www.google.com 這個看似簡單網頁，仔細一想就能感覺到他們的系統會有多複雜，提供圖片，視頻，新聞，搜索全球化海量數據服務， 系統複雜度和對可用性要求都很是高，架構上須要考慮自建機房，服務部署全球化，保持服務高性能, 擴展性，可用性。基礎服務來看，須要提供具備高性能，高可用，無擴展問題的基礎服務，像分佈式存儲，分佈式數據庫，分佈式計算引擎，分佈式配置中心等服務，僅僅是www.google.com就須要考慮這些，若是加上play store, youtube, dirve, translate等其餘服務了，面臨的問題也會更多更難，這些一直推進着Google在運維方向的思考實踐和努力。

Google怎麼解決上面的問題？

a 自研相關基礎服務:

  首先他們的運維工程師都是由研發組成，他們特性都是不喜歡重複，低效的工做方式，喜歡用程序去自動化系統，甚至是自治系統。

  他們的系統幾乎都是自研的，並且在自研相關係統的同時，就會去考慮分佈式的應用場景，考慮系統的容錯性，可擴展性，運維簡化等方面，這些系統有直接是SRE進行研發，也有SRE參與設計編碼等。我簡單列舉一些他們內部服務，講一下各自系統解決的問題。

  Borg 管理物理服務器和編排服務， 就是簡化物理機管理與服務管理

  Bigtable, Spinner,GFS 提供存儲基礎服務,知足各類存儲需求，分佈式kv存儲，分佈式sql數    據庫，分佈式對象存儲

  基於 openflow協議相關SDN產品 軟件網絡去解決大規模網絡配置管理問題

  Chubby 分佈式鎖服務

  Borgmon 監控服務

  Grpc,Stubby服務調用

等等

b 方法論:

  光這些還不夠，儘管在軟件設計之初就有考慮了系統的 擴展性，簡化運維，容錯性等方面，不過仍是存在大量主機或基礎服務須要實時管理維護, 異常管理體系。

a 標準化一些基本流程

  1 針對服務定製服務質量目標

  2 sre花費更多的時間在研發上邊，更多減小雜事

  3 標準化監控系統和高效率的告警系統

  4 高效的oncall輪班

  5 事故的響應方式

  6 覆盤與事故管理機制

  等等

b 解決系統性問題的方法論:

  1 前端服務器負載均衡

  2 數據中心內負載均衡

  3 應對服務過載問題，限流

  4 連鎖故障的解決方式

  5 分佈式共識

  6 分佈式週期性任務系統

  等等

這裏沒有很細節的談這些方法論的細節，相關細節可用購買 <<Google運維解密>>，或則直接上官方網站查看  landing.google.com/sre/​

本身對SRE的實踐

a 參與編碼或設計並優化各個系統

  我會主動去參與設計或編碼一些關鍵的系統，如監控系統，消息系統，調度系統，文檔轉換，錄像轉換，甚至是一些web系統。這會讓我對系統的理解程度會更高，更可控，同時在之後尋找系統風險，性能瓶頸會得出更好的方案。

b 擁抱開源,造成自身技術棧，標準化一些技術去解決問題

  不是每家公司都會面對google面對的問題，也不會有這麼大的研發精力和這麼高的標準去自研自身系統，全部從我這邊來看仍是主要是去擁抱開源。

  1 kubernetes/saltstack/ansible/openstack 等解決服務器管理運維部署服務化問題

  2 elasticsearch/filebeat/logstash/kibana/flume 等解決日誌收集問題

  3 prometheus/influxdb/zabbix/grafana/openfalcon 等解決監控問題

  4 jenkins/git流程 解決自動化測試與構建各個組件標準高可用方法論

  5 hadoop/ceph/swift/cinder 等解決存儲問題

  mq, loadbalancer, sql等等

c 大量工做放在如何自動化，如何自治系統這邊。

  最好的系統是徹底自動的，徹底不須要人干預的，也是我和公司一直努力的方向，好比設計自動化的調度系統，完成不須要人工干預管理的上千臺服務器的目標。

d 時刻保持學習，總結的心態，將本身的定位放在系統工程師這個方向。

  不給本身打標籤，不定義本身是如java工程師，測試工程師，python工程師，工做目標是用如何解決問題，而後自身在保持廣度的同時，也要有必定領域的深刻，學習技術要知道其工做原理，優化方式，好比像最近的話是專心研究容器技術和虛擬化技術等相關技術。

最後:

  感謝Google開源其SRE的相關概念與方法論，讓你們有更多思路和方式去解決系統問題。

  貼上之前對sre相關分享的ppt連接.

https://drive.google.com/file/d/1ln_vbHVHuAkoDkRAg3pXV3M8h1JTbH1X/view​ drive.google.com