SRE就是程序測試員么？
有人跟我說SRE就是程序測試員，換了個名字而已，是這樣么
胡說八道。
SRE絕對不是程序測試員。
今年8月份被調到了UCloud的SRE團隊，為了適應工作，翻了一下Google SRE的中文版，也有些許體會。
為什麼出現SRE- SRE是在軟體上線過程中為了解決DEV和OPS的矛盾產生的。矛盾點在於軟體變更上線的發布速度。DEV希望新功能快速部署上線，接入用戶；OPS則希望服務儘可能少的有變更，因為變更容易引起故障。
- SRE是一幫有研發能力的工程師，可以設計並實現自動化運維繫統。
- 在變更速度和服務穩定性的博弈中，SRE逐漸全面和智能化運維繫統。逐漸包含了容量規劃、自動化部署、系統監控、服務自動化修復、增加測試、故障跟蹤。最後能夠對現網的服務進行工程性的優化，比如增加負載均衡，增加重啟機制等。
- 高效和智能的SRE運維繫統，不僅能夠減輕運維壓力，改變研發的工作習慣，甚至可以主動地去推動研發部門的工作。
SRE的主要工作
- on-call：因為有專門的運維團隊，目前UCloud的SRE部門還不需要過多的值班。但是，on-call可以幫助SRE團隊成員了解現網服務的問題，這是有助於設計SRE運維繫統的。
- 研發：開發高效和智能的SRE運維繫統。
- 溝通：由於SRE是介乎於研發、測試和運維中間的部門，所以SRE團隊成員需要跟不同部門的同時有交集。保證服務穩定性的工作必須在測試階段、部署階段、上線階段同時進行。
Site Reliability Engineering - OReilly Media不是。看書，自己判斷。
中文裡面最接近的詞應該是運維。
SRE就是DevOps，只不過因為Google起了個高大上的名字還寫了本書，SRE就火了
DevOps = Development + Operations，簡而言之，通過研發(dev)把運維(ops)全部自動化(automation)
所涉及的範圍呢：代碼管理和部署，配置管理，監控，應急響應，故障處理，壓力測試，容災等等
Devops的核心概念就是通過腳本實現自動化 -&> Automation
現在有一個新的概念叫做NoOps，目的是實現自主運維，系統自動發現並解決問題，完全不再需要自動化腳本 -&> Autonomy
傳統運維將死，不會寫代碼的都該失業了...
SRE（Site Reliability Engineering）是Google於2003年提出的概念，將軟體研發引入運維工作。現在漸漸已經成為各大互聯網公司技術團隊的標配。
例如：美團點評作為綜合性多業務的互聯網+生活服務平台，覆蓋「吃住行游購娛」各個領域，SRE就會面臨一些特殊的挑戰。
- 業務量的飛速增長，機器數量劇增，導致人工維護成本增大；而交易額的增長，對SLA的要求也不斷提高。與此同時，一些新業務會面臨大流量衝擊，資源調度的挑戰也隨之增大。
- 業務類型複雜多樣、業務模型千差萬別，對應的技術方案也多種多樣，因此SRE的整體維護成本大大提高。
根據上述挑戰，我們需要制定相應的解決策略，策略原則主要聚焦在以下三點：
- 穩定，這也是SRE工作的核心。
- 效率，包括雲主機交付效率，也包括我們自己內部的一些系統效率。
- 成本，用最少的機器提供最優質的服務。
在此原則的基礎上，我們開始了對SRE進行的一系列改進。
SRE作為一個新的職位類型來說可以翻譯為 Site Reliability Engineer， 它也可以翻譯成Site Reliability Engineering，它是由Google最早提出，又經由Google發展完善的一個嶄新運維理念。在新一代信息系統架構（大規模、分散式、高並發、多業務、多租戶）下DevOps 思想應運而生，正是DevOps思想在運維領域的具體實踐。如果把這個職位強行翻譯過來可以說是運維工程師，他們一般具備運維人員的基本技能還需要懂得一定的開發技能，在Google，SRE需要保證50%的工程開發時間，通過開發工具來保證系統穩定性和快速創新之間的平衡。
越來越多的美國公司都在依照Google的方式來組織和運作SRE部門。而很多國內企業對SRE也越來越重視。比如阿里這樣的巨型互聯網企業已經設立起自己的SRE部門，一些技術驅動的企業如數人云甚至已經開始了有關SRE的專門培訓。
抄自百度百科----------------------SRE是指Site Reliability Engineer (網站可靠性工程師)。他是軟體工程師和系統管理員的結合，一個SRE工程師基本上需要掌握很多知識：演算法，數據結構，編程能力，網路編程，分散式系統，可擴展架構，故障排除。
推薦閱讀：
※「開發靠 Google，運維靠 Baidu」的說法靠譜嗎？
※國內程序員怎樣競爭 Google 總部的工作機會，需要滿足哪些條件？