SRE角色在大型企業中很常見，但小型企業也需要它。
儘管網站可靠性工程師(SRE)的角色在最近幾年變得很普遍，但許多人，甚至是軟件行業的人，並不知道它是什麼或做了什麼。本文的目的是通過解釋什麼是SRE，它與DevOps的關係，SRE是如何工作，能讓你的整個工程組織悠閒的喝咖啡時。
什麼是站點可靠性工程師SRE？
《谷歌SRE解密》一書：由一組Google運行生產系統的工程師編寫，被認為是關於站點可靠性工程的權威書籍。谷歌工程副總裁Ben Treynor Sloss在21世紀初創造了這一術語。他將其定義為：“當要求軟件工程師設計運維功能時會發生的事情。”
系統管理員已經編寫了很長一段時間的代碼，但在這些年中，一組系統管理員手動管理了許多機器。那時候，“很多”可能已經有幾十個或幾百個，但是當你擴展到成千上萬或幾十萬個主機時，你根本無法繼續引發人們解決這個問題。當機器數量變得那麼大時，顯而易見的解決方案是使用代碼來管理主機（以及在它們上運行的軟件）。
此外，直到最近，運維團隊才與開發人員完全分開。每項工作的技能組合被認為完全不同，SRE角色試圖將兩個工作結合在一起。
在我們深入研究SRE的內容以及SRE如何與開發團隊合作之前，我們需要了解站點可靠性工程如何在DevOps範例內工作。
站點可靠性工程和DevOps
站點可靠性工程的核心是DevOps範例的實現，似乎有很多方法來定義DevOps。開發和運維團隊分離的傳統模型，導致編寫代碼的團隊不理解代碼如何幫助工作。開發團隊將“將代碼拋到牆上”給運維團隊進行安裝和支持。
這種情況可能導致大量功能障礙，開發和運維團隊的目標始終存在爭議，開發人員希望用戶使用“最新且最好的”代碼，但運維團隊希望穩定的系統儘可能少地進行變更。他們的前提是任何變更都會引入不穩定性，而沒有改變的系統應該繼續以相同的方式行事。（注意儘量減少軟件方面的變化並不是防止不穩定的唯一因素。例如，如果你的Web應用程序保持完全相同，但客戶數量增長了10倍，擬的應用程序可能會以多種不同的方式中斷。 ）
DevOps的前提是通過將這兩個不同的作業合併為一個，可以消除爭用。如果“dev”想要一直部署新代碼，他們必須處理新代碼創建的任何後果。正如亞馬遜的Werner Vogels所說，“誰建造，誰運行”（在生產系統中）。但開發人員已經有很多需要擔心的問題，們不斷推動為其僱主的產品開發新功能。要求他們瞭解基礎設施，包括如何部署，配置和監控他們的服務，可能會對他們提出太多要求，這是SRE介入的地方。
開發Web應用程序時，通常會有很多人做出貢獻。有用戶界面設計師，圖形設計師，前端工程師，後端工程師和許多其他專業（取決於所使用的技術）。要求包括如何管理（例如，部署，配置，監控）代碼，這是SRE的專業領域。但是，就像工程師為應用程序開發一個漂亮的外觀，而受益於後端工程師工作的知識（例如，如何從數據庫中獲取數據），SRE瞭解部署系統的工作原理以及如何使其適應特定代碼庫或項目的特定需求。
因此，SRE不僅僅是“代碼操作員”。相反，SRE是開發團隊的另一個成員，具有不同的技能，特別是在部署，配置管理，監控，指標等方面。但是，正如工程師為應用程序開發一個漂亮的外觀和感覺必須知道數據是如何從數據存儲中獲取，SRE並不單獨負責這些區域。整個團隊共同努力，提供可輕鬆更新，管理和監控的產品。
當一個團隊正在實施DevOps時，自然會出現對SRE的需求，但他們意識到他們要求開發人員過多，並且需要專家來處理運維團隊過去所處理的問題。
SRE如何在創業公司工作
當有數百名員工時（特別是如同Google或Facebook大小時），這很棒。大型公司的SRE團隊分散並嵌入到每個開發團隊中。但是一家創業公司沒有那種規模經濟，工程師經常戴著很多帽子。那麼，“SRE帽子”適合小公司嗎？一種方法是完全採用DevOps並讓開發人員負責SRE在大公司中執行的典型任務。另一方面，你可以聘請了專家，比如SRE。
試圖將SRE帽子戴在開發人員頭上的最明顯優勢是隨著團隊的發展，它可以很好地擴展。此外，開發人員將瞭解該應用程序的所有怪癖。但許多初創公司使用各種SaaS產品來為其基礎設施賦能。最明顯的是基礎架構平臺本身。然後添加指標系統，站點監控，日誌分析，容器等。雖然這些技術解決了一些問題，但它們會增加複雜性。除了應用程序使用的核心技術（例如，語言）之外，開發人員還需要了解所有這些技術和服務。最後，掌握所有這些技術可能會讓人無法抗拒。
另一種選擇是聘請專家來處理SRE工作，他們的職責是專注於部署，配置，監控和指標，從而節省開發人員編寫應用程序的時間。缺點是SRE必須在多個不同的應用程序之間分配時間（即，SRE需要在整個工程中支持應用程序的廣度）。這可能意味著他們可能沒有時間對任何應用程序獲得任何深度的知識;然而，他們可以看到所有不同的部分如何組合在一起。這個“30,000英尺的視圖”可以幫助確定弱點的優先級，以便在整個系統中進行修復。
我忽略了一條關鍵信息：你的其他工程師。他們可能非常希望瞭解部署的工作原理以及如何盡最大努力使用度量系統。此外，僱用SRE並非易事。你正在尋找各種系統管理員技能和軟件工程技能。（我特別關注軟件工程師，而不僅僅是“能夠編程”，因為軟件工程不僅僅涉及編寫代碼[例如，編寫好的測試或文檔]。）
因此，在某些情況下，“SRE帽子”在開發者的頭上更有意義。如果是這樣，請密切關注代碼和基礎架構（SaaS或內部）的複雜程度。在某些時候，兩端的複雜性可能會推動更專業化。
結論
SRE團隊是在創業公司中實施DevOps範例的最有效方法之一。我已經看到了幾種不同的方法，但我相信在你的創業公司僱用一個專門的SRE（很早就會）可以騰出時間讓開發人員專注於他們的具體挑戰。SRE可以專注於改進使開發人員更高效的工具（和流程）。此外，SRE將專注於確保你的客戶擁有可靠且安全的產品。
原文鏈接：
https://opensource.com/article/18/10/sre-startup
閱讀更多 CloudMSP社區 的文章
