實錄問答 | SRE 是如何煉成的

2017 年 2 月 7 日晚上 8 點 30 分，數人云CTO 肖德時爲你們帶來了主題爲「運維達爾文： SRE 的自動化演進」的交流。

本文轉自 GitChat 的交流實錄，由主持人 Jacty 整理。

SRE 方法論

問： SRE 和 DevOps 有什麼區別？

答： 這個問題其實出現過不少次，之全部此一問，必然是二者之間有不少共同點。確實， DevOps 和 SRE 都重視自動化，拒絕手工勞動，利用軟件工程手段執行運維任務等等。咱們能夠認爲 DevOps 是 SRE 核心理念的普適版，能夠用於更廣範圍內的組織結構、管理結構和人員安排， SRE 能夠看作是 DevOps 模型在某種組織結構中的具體實踐。 DevOps 通常多指一個工做方式或者流程， DevOps 的定義中就包括 Dev 和 Ops 互相協做，識別並規避風險，整體來講仍是比較抽象。雖然 SRE 也是一種方法一種體系，可是 SRE 有許多更具體的操做實踐。好比在《 SRE-Google 運維解密》這本書中詳細地介紹了監控報警、應急事件處理、變動管理、需求預測和容量規劃以及資源部署等具體化方法和工具。

問：關於自動化演進的 5 個階段，能結合實例作一些更詳細的介紹麼？

答： SRE 思想上傾向於儘量使用機器管理機器，可是實際狀況須要必定的變通。將每一個系統的每一個組件都自動化是不合適的，同時不是全部人都有能力或者傾向於在一個特定的時間開發自動化系統。

自動化的演進遵循以下路徑:

沒有自動化。
外部維護的系統特定的自動化。
外部維護的通用的自動化。
內部維護的系統特定的自動化。
不須要任何自動化(自主化)。
講起來就是 SRE 討厭手動操做，然而有時手動操做不可避免的。自動化的演進是一套方法論。

舉個具體的例子，集羣上線自動化進化遵循這樣一個路徑:

操做人員觸發手工操做(無自動化)，採用 shell 腳本經過 ssh 來應對繁瑣的包分發和服務初始化問題。咱們本身也存在這個案例，不是說懂就所有上 SRE ，實施起來，水平仍在第一階段。

操做人員編寫，系統特定的自動化，可以使用生產用測試腳本 Prodtest 檢測不一致狀況。這個的難度會高一點，基本開始往 SRE 的方向在跑了

外部維護的通用自動化，冪等地解決不一致狀況，增長自動修復程序。能實現這一步，基本達到國內頂級運維水平了。

內部維護，系統特定的自動化。經過消除運維相關服務的團隊維護和運行自動化代碼的責任，創造新的組織激勵機制，讓最好用的工具由那些天天使用它們的人來寫。改職責，上 SRE 的激勵機制，讓用的人來寫運維工具。這個難度不在人，是文化和職責的再次明確，對我的仍是公司都是一次成長。

不須要人爲干預的自治系統。由服務團隊維護上線流程，每一個團隊按照合同(API)提供自動上線所需的自動化，不限制底層的實現細節。

基本第五層就是平臺分層的運維方式了， SRE 的角度也深刻到最內核集羣的調度。國內有過這樣的場景，阿里，滴滴都有，可是也在發展中，你們還在一個積累階段。

問： SRE 在設計、開發階段有投入麼？投入的內容是什麼？對系統的第三方開發者或者本身的開發團隊提供服務或者工具麼？

答： SRE 要解決的是實際業務多方面的問題，在設計、開發階段並無實際的投入。而是在投產前交給 SRE ， SRE 就徹底接管了業務。且對於開發來講，須要的 SLO ，都會給予明確的評估和監控。

對工具或者服務，是有投入的。原來是一波人開發，一波人使用。可是 SRE 是本身開發本身使用，徹底解決本身的問題。這個能力有點理想化，可是從 SRE 的實踐中，大量的例子告訴你們，這個是收益最大的，因此纔有了運維自動化的 5 個階段。

問：不太理解爲何 SRE 須要掌握 「算法，數據結構，編程能力...」這類技能。

答： SRE 按照約定， 50%時間用於開發。因此這些開發經常使用的技能是須要的，可是這個是理想。國內阿里保障部，用一堆人來創建起 SRE 團隊，也是很好的實踐，整體上也保障了淘寶的業務發展。因此技能是一種訴求，不是徹底前提。從實際業務出發，能深刻研究問題，解決問題的方法和技巧就是 SRE 的產出。

SRE 中的開發與運維

問：若是從技術上轉型，是否程序員比純運維更容易適合 SRE 工做？

答： 這個對兩類人羣都會有幫助，沒有誰是最合適的。只是，這個崗位給年輕人新的機會，而且它是和業務相關的，老闆最關心的就是業務，因此 SRE 的工做回報率很高。對我的的技術能力的培養和成長都有一個清晰的規劃。當你熱血沸騰的去國內招聘網站找 SRE 的職位的時候，是找不到的，這個是由於國內的雲計算髮展水平限制致使的，你們不用擔憂。短時間內，當一個開發或者運維沒有關係，可是你的思想高度若是提升到 SRE 的理論高度，必定會受到同事和領導的承認。機會永遠是留給有準備的員工。

問：自動化運維如何逐步開展起來？都有哪些事情要作？這些事情之間的依賴關係如何？自動化運維將來的方向在哪裏？

答： 自動化運維是一個理想，應該沒有最好，只有更好。運用 SRE 的理論，應該腳踏實地的專一在業務層面，定義 SLO 。而後在此基礎上，再作容量規劃，這個容量規劃是對現有資源的規劃，和水平擴展時指標的實時監控。這個是很難作到的任務，必定會花費你不少精力。而後在切入實際的問題點，總結經驗，一次性的解決問題。

這些事情在 SRE 的想法裏，它是有固定的場景和解決方案的，這就是 SRE 十年磨練出來的體系化的內容。自動化運維應該是工具集的一種理論發展，可是和 SRE 對比起來， SRE 十多年的發展已經很是成熟，應該更有價值。工具的自動化是沒有盡頭的，但針對業務保障的 SRE 仍是一個不錯的方向。我推薦你們關注和積累這方面的知識和方法論，在自動化運維將來發展過程當中也會有一個主心骨來引導。

問：感受自動化運維會不會與開發造成競爭 這個職業到必定熱度後，開發會進入這個行業搶飯碗？

答：如今就是在互相搶飯碗。單純的開發和運維都是比較枯燥的職業，並非全部的開發能有機會能開發本身喜歡的工具或者產品。因此運維要提高本身，就會去走業務保障的路數，開發要提高本身，也會有大量的人員會走這條路，這個在國內是必經之路。

從擔憂本身的飯碗，到強調運維的重要性，須要一個高度。不是簡簡單單的說運維會開發了，就牛了，開發會運維了，就革掉運維的命了。這個我不太認同，而是應從業務出發，真正的去思考業務問題，把本身的工做自動化思想高度提升，你們看的境界就不同了。一切以業務出發，深度的去解決問題的能力，是須要磨練和時間的沉澱的，毫不是今天咱們你們講講 SRE 就能升級。

問：看評論有人提到，開發應該比運維更適合 SRE 崗位，和我想的， SRE 的新人是往開發方向發展仍是運維方向發展？如果開發方向那爲什麼不直接先去開發崗位，而後再轉爲 SRE ？如果運維方向，那麼今後開發能力就會很低了，遲早都得被 SRE 崗位淘汰？對此，肖老師怎麼看？

答： SRE 最重要的是 Engineering ，用軟件工程的方法論來解決業務問題，保障業務的持續發展。因此不管是開發，仍是運維，若是想我的發展， SRE 是一個不錯的方法。有了思想的武裝，在具體的事情上，你會考慮更全面，不用擔憂淘汰的事情。全部事情不是有了思想就比別人先進了。掌握了 SRE 的思想，其 10 年的實踐足以支撐你的發展方向沒錯。

SRE 與企業實踐

問： SRE 是否只適合有大規模 IT 系統的企業？

答： 從本質上來講 SRE 主要關注提高 IT 的效率，而不關注 IT 規模。可是從國內外的實際狀況來看，確實是 IT 規模比較大的企業纔會考慮設置 SRE 崗位。這主要的緣由在於 SRE 理念的實施有兩個很現實的問題，人與錢。

首先說人，對於 SRE 人員的技能要求是比較高的，他既要具備必定的開發能力又須要對系統管理知識有所掌握，不管是從外部招聘仍是從本身的傳統運維團隊中培養都須要必定的人才儲備和資金支持。通常而言 IT 規模比較大的企業總體規模也比較大，這種大企業相比小企業而言對於採用先進的運維理念會有更多的支持。可是這並非說 SRE 只適合 IT 規模比較大的企業。總體而言 SRE 對提升企業 IT 系統的效率都是有所助益的，不管企業規模或者說 IT 規模的大小。

第二個方面就是錢的方面，想省錢，可是業務一多，就須要招人。如何解決這個瓶頸。就是須要走 SRE 的操做路線。

因此， SRE 是通用型的理論思想，推薦任何須要服務支持的企業應用起來這種思想。

問：在企業內部踐行 SRE 體系，除了啓用自助化和自動化工具，是否意味着要增長 SRE 崗位？

答： 回答這個問題的時候我要先放一張圖。

從這張圖上能夠看出 SRE 成功的標誌是業務快速增加，但運維事務並不隨着業務增加的速度而增加。引入 SRE 理念，不是要增長運維團隊的規模，而是要提升運維的效率，保持運維團隊規模不隨業務規模的增加而同比增加。若是僅僅是在原有運維團隊的基礎上增設 SRE 崗反而擴大了運維團隊的規模，這與 SRE 的初衷是不一致的。比較合理的作法是在啓用自動化工具的同時，把部分的傳統運維工程師升級爲 SRE 工程師，這些工程師須要具有必定研發能力和具體的系統知識。

問：如今國外都有哪些公司有 SRE 崗位？

答： Google 是最早設置 SRE 崗位的，其實也能夠說是國外 SRE 的黃埔軍校，不少國外公司的 SRE 其實都是從 Google 裏面出來的。如今據咱們所知的還有 LinkedIn ， Twitter ， Facebook 、 Pivotal 、 Bloomberg 。

問：肖總提到用共享經濟來在國內推廣 SRE ，可否結合實際案例介紹下如何在中小企業中實施，對於企業的 IT 基礎平臺的業務系統是否有一些要求？

答： 舉個實際例子：咱們在賣的是一套數人云 PaaS 平臺，同行也在賣一套 PaaS ，除了功能上的對比，實際上從一開始和客戶接觸，就會造成一個壁壘。客戶的痛點解決不了，產品賣出去也很是累。因此，如今業界有一個 B4B 的模式，就是讓客戶和產品公司能坐在一塊兒共同討論客戶本身的問題。提及來很容易，可是實際操做起來，咱們確實面臨過問題。在一家金融機構裏面，最後仍是對方在給咱們疏導痛點。由於傳統企業的運維規章制度很嚴格，從 SRE 的角度來落地，對方不必定承認，由於規模小，用人就能頂住。最可能是看到自動化的需求，買一個工具來自動化一下。可是從咱們這些要堅持 SRE 理念的公司，也適度的和客戶深刻交流，幫助客戶把具體的痛點問題梳理成有體系的模塊。這樣對客戶來講，他們都是反饋很好，而且容許咱們工具的不完善。按照以前閉門造車製做的產品，到客戶那裏就是定製。而且由於產品已經有一個方圓，你很難就場景下把工具作的更通用。因此貼近客戶，纔能有機會就痛點問題找到工具的實現範圍。

問： SRE 是否認位爲系統運行階段？仍是產品的全生命週期？以前瞭解到谷歌的數據中心運維人員極少，是否和踐行 SRE 有關？在國內的大環境下，一箇中等規模的 IT 公司若要踐行 SRE ，組織結構應當作何調整，績效方面當如何評估？

答： SRE 應該貫穿業務運行的全部階段，否則沒法有效的保障業務的平穩發展。能夠按照不一樣的階段劃分 SRE 團隊，可是就咱們國內的現狀，能把現有的人利用起來就已經很好了。

谷歌的數據中心 SRE 不多，是谷歌實踐出來的科學的方法論。國外大量的公司不可能複製谷歌，可是在此方法論下實踐已經獲得很高的收益。不要把目光放在谷歌之上，由於谷歌的工具自動化程度已經很是高，這個階段的 SRE 問題咱們無法複製。在國內大環境下，從最實際的角度，是走 DevOps 路線。這個上到老闆，下到基層，你們都知道。組織結構能夠先從運維開始，可是解決問題的方式要有變化，從應用的全生命週期來全局考慮運維自動化。而且自動化的 5 個發展階段也很好的解讀了一個實際問題，大大小小的問題，必須深究下去，保證到最後能一次性解決。

咱們通常的運維都是解決完問題，就完事了，不會深究。從軟件工程角度，咱們把具體問題寫成報告，不斷演練，自動化的冪等實現。若是沒有一套合適的理論，咱們是無法堅持下去作研發的。

問：初創或小型公司可否推行 SRE ，人員配比是否有要求？若是推行，是否有特別注意的地方？

答：小公司，通常就 1 個，要麼開發要麼運維。強推 SRE ，是霸王硬上弓。從合理的角度是，是把如今的問題列出來，從 SRE 的方法論，指定本身的發展路線，天然就對人員配比和推廣 SRE 有了一個現實的能夠作的事情。 SRE 是務實的，就是爲了要解決業務問題，而且一次性把問題想的很深，經過實踐不斷提出更深的解決辦法。

特別注意的是， SRE 不是一個簡單的崗位，而是給出了一個建議。從咱們實際的實踐中，運維在推行 SRE 的時候想不通，爲何要這麼幹。可是當你們一塊兒討論的時候，就會發現這裏的難度，我的的水平達不到，正好激勵人員提高。人很重要，可是方法論就是一盞明燈，給咱們走下去指明方向。而且， SRE 是解決具體問題，不是搞一些心得來分享。那個沒有意義，你們要解決的是業務的真正可持續的發展。因此 SRE 的理論和實踐方法是須要小公司的人員重視起來，把實際的事情作好，而不是看重谷歌的名頭，那就廢了。