what's site reliability engineer
站點可靠性工程（site reliability engineer SRE）是 IT 運維的軟件工程方案。SRE 團隊使用軟件作爲工具，來管理系統、解決問題並實現運維任務自動化。
SRE 執行的任務以前通常由運維團隊手動執行，或者交給使用軟件和自動化來解決問題和管理生產系統的工程師或運維團隊執行。
在創建可擴展和高度可靠的軟件系統時，SRE 是寶貴的實踐。它可幫助您通過代碼管理大型系統，對於管理成千上萬臺機器的系統管理員（sysadmin）來說，代碼更具可擴展性和可持續性。
站點可靠性工程的概念由 Google 工程團隊的 Ben Treynor Sloss 第一個提出。
2003年，Benjamin Treynor Sloss 加入了谷歌。他的首要任務之一，就是被要求管理一個由七名工程師組成的“生產環境團隊（Production Team）”。
在此之前，他之前的工作經驗是軟件工程。因此，如果他擔任 SRE ，他會按照自己希望的方式設計和管理團隊。自那以後，這個團隊已經發展成熟，成爲谷歌現在的 SRE 團隊，這一團隊目前仍舊忠於這位終身軟件工程師所設想的原始目的。
SRE 就是當你要求軟件工程師設計一個運維團隊時，所發生的事情
谷歌的幾個工程師寫的《SRE：谷歌運維解密》被認爲是站點可靠性工程的權威書籍。谷歌的工程副總裁 Ben Treynor Sloss 在二十一世紀初創造了這個術語。他是這樣定義的：“當你讓軟件工程師設計運維功能時，SRE 就產生了。”
雖然系統管理員從很久之前就在寫代碼，但是過去的很多時候系統管理團隊是手動管理機器的。當時他們管理的機器可能有幾十臺或者上百臺，不過當這個數字漲到了幾千甚至幾十萬的時候，就不能簡單的靠人去解決問題了。規模如此大的情況下，很明顯應該用代碼去管理機器（以及機器上運行的軟件）。
另外，一直到近幾年，運維團隊和開發團隊都還是完全獨立的。兩個崗位的技能要求也被認爲是完全不同的。SRE 的角色想嘗試把這兩份工作結合起來。
SRE 可以幫助團隊在發佈新功能和確保用戶可靠性之間找到平衡。
在這種背景下，標準化和自動化是 SRE 模型的兩大重要部分。在這裏，站點可靠性工程師尋求增強和自動化運維任務。
通過這些方式，SRE 有助於提高當今的系統可靠性，並且隨着時間的推移不斷提高。
SRE 支持團隊從傳統 IT 運維方案遷移至雲原生方案。
站點可靠性工程師的工作是什麼？
站點可靠性工程師是一個獨特的崗位：
-
具有系統管理員背景
-
運維經驗的軟件開發人員
-
有軟件開發技能的 IT 運維人員
SRE 團隊負責部署、配置和監控代碼，以及生產服務的可用性、延遲、變更管理、應急響應和容量管理。
SRE 團隊根據服務水平協議（SLA）確定新功能的推出，並利用服務水平指標（SLI）和服務水平目標（SLO）定義系統所需的可靠性。
SLI 測量所提供服務水平的特定方面。關鍵 SLI 包括請求延遲性、可用性、錯誤率和系統吞吐量。SLO 基於根據 SLI 而指定的服務水平的目標值或範圍。
然後，根據確定可接受的停機時間，確定所需系統可靠性的 SLO。這個停機時間稱爲誤差量，即出錯和中斷的最大允許閾值。
SRE 並不是要實現 100% 可靠性，而是針對故障做好計劃並妥善應對。
一旦建立，開發團隊就可以在發佈新功能時允許出現這一定量的誤差。利用 SLO 和誤差量，團隊隨後可確定產品或服務是否能夠在可用誤差量的基礎上啓動。
如果某個服務在運行時處於誤差量以內，則開發團隊可在任何時間發佈它，但是，如果系統當前有太多錯誤或停機時間超過誤差量的允許範圍，則必須使錯誤數減少至誤差量以內後才能發佈。
開發團隊可執行自動化運維測試以驗證可靠性。
站點可靠性工程師的時間要均衡分配給運維任務和項目工作。根據 Google 的 SRE 最佳實踐，站點可靠性工程師最多隻能將一半的時間花在運維上，所以應該監控確保不會超過這個時間。
他們剩餘的時間應專注於開發任務上，比如創建新功能，擴展系統，以及實施自動化。
額外的運維工作和表現欠佳的服務應重新指定給開發團隊，這樣站點可靠性工程師就不用將太多時間花在應用或服務的運維上。
自動化是站點可靠性工程師的重要工作部分。如果他們一直在反覆處理同一個問題，就會努力實現解決方案自動化。
保持運維和開發工作之間的平衡是 SRE 的重要組成部分。
SRE 團隊的組成
谷歌服務管理方式的主要組成部分就由每個 SRE 團隊的組成。總體而言，SRE 可分爲兩大類。
-
50-60 % 的人是谷歌軟件工程師，他們是通過谷歌軟件工程師的標準程序聘用的。
-
另外 40-50% 的應聘者也非常接近谷歌軟件工程資格，同時擁有一套對 SRE 有用，但對大多數軟件工程師來說很少用的技術技能。
到目前爲止，UNIX 系統內部知識和網絡專業知識是他們尋求的兩種最常見的替代技術技能。
所有 SRE 的共同點是，他們都有通過開發軟件系統，來解決複雜問題的信念和能力。
在 SRE 內部，他們密切跟蹤了這兩個羣體的職業發展。到目前爲止，他們還沒有發現工程師在這兩個領域的實際表現存在差異。事實上，SRE 團隊有不同的背景，這通常會產生一些智能且高質量的系統，這顯然是多種技能組合的產物。
谷歌爲招聘 SRE 所用的方法，最終的結果就是，他們最終擁有這樣一個團隊：
-
會很快對使用手工方式完成任務感到厭倦
-
具備編寫軟件以取代以前手工工作所需的技能，即使解決方案很複雜，也是一樣。
SRE 最終會與其他開發組織分享了學術和知識背景。因此，SRE基本上是在做原來運維團隊所做的工作，但其方式是啓用具有軟件專業知識的工程師，並基於這些工程師固有的使用軟件設計和實施自動化的能力，來設計和實施自動化的能力。
SRE 和 DevOps
“DevOps” 這個術語在 2008 年末出現，其核心原則：
-
IT 部門在系統設計和開發的每個階段的參與
-
嚴重依賴自動化與人力投入
-
工程實踐和工具在操作任務中的應用
與許多 SRE 的原則和實踐一致。 人們可以將 DevOps 視爲幾種核心 SRE原則向更廣泛的組織，管理結構和人員的推廣。 可以等價地將 SRE 視爲具有某些特殊擴展的 DevOps 的特定實現。
站點可靠性工程的核心，就是對 DevOps 範例的實踐。DevOps 的定義有很多種方式。開發團隊（“dev”）和運維（“ops”）團隊相互分離的傳統模式下，寫代碼的團隊在將服務交付給用戶使用之後就不再對服務狀態負責了。開發團隊“把代碼扔到牆那邊”讓運維團隊去部署和支持。
這種情況會導致大量失衡。開發和運維的目標總是不一致 —— 開發希望用戶體驗到“最新最棒”的代碼，但是運維想要的是變更儘量少的穩定系統。運維是這樣假定的，任何變更都可能引發不穩定，而不做任何變更的系統可以一直保持穩定。（減少軟件的變更次數並不是避免故障的唯一因素，認識到這一點很重要。例如，雖然你的 web 應用保持不變，但是當用戶數量漲到十倍時，服務可能就會以各種方式出問題。）
DevOps 理念認爲通過合併這兩個崗位就能夠消滅爭論。如果開發團隊時刻都想把新代碼部署上線，那麼他們也必須對新代碼引起的故障負責。就像亞馬遜的 Werner Vogels 說的那樣，“誰開發，誰運維”（生產環境）。但是開發人員已經有一大堆問題了。他們不斷的被推動着去開發老闆要的產品功能。再讓他們去了解基礎設施，包括如何部署、配置還有監控服務，這對他們的要求有點太多了。所以就需要 SRE 了。
開發一個 web 應用的時候經常是很多人一起參與。有用戶界面設計師、圖形設計師、前端工程師、後端工程師，還有許多其他工種（視技術選型的具體情況而定）。如何管理寫好的代碼也是需求之一（例如部署、配置、監控）—— 這是 SRE 的專業領域。但是，就像前端工程師受益於後端領域的知識一樣（例如從數據庫獲取數據的方法），SRE 理解部署系統的工作原理，知道如何滿足特定的代碼或者項目的具體需求。
所以 SRE 不僅僅是“寫代碼的運維工程師”。相反，SRE 是開發團隊的成員，他們有着不同的技能，特別是在發佈部署、配置管理、監控、指標等方面。但是，就像前端工程師必須知道如何從數據庫中獲取數據一樣，SRE 也不是隻負責這些領域。爲了提供更容易升級、管理和監控的產品，整個團隊共同努力。
當一個團隊在做 DevOps 實踐，但是他們意識到對開發的要求太多了，過去由運維團隊做的事情，現在需要一個專家來專門處理。這個時候，對 SRE 的需求很自然地就出現了。
參考文章：
https://www.redhat.com/zh/topics/devops/what-is-sre
什麼是 SRE？它和 DevOps 是怎麼關聯的？ https://cloud.tencent.com/developer/article/1881362
谷歌的 SRE 是怎麼來的？ https://www.continuousdelivery20.com/blog/sre-how-google-come-up-with/