編譯自： https://opensource.com/article/18/10/sre-startup

作者： Craig Sebenik

譯者： BeliteX

大型企業里 SRE 角色比較常見，不過小公司也需要 SRE。

雖然 站點可靠性工程師(site reliability engineer)（SRE）角色在近幾年變得流行起來，但是很多人 —— 甚至是軟體行業里的 —— 還不知道 SRE 是什麼或者 SRE 都幹些什麼。為了搞清楚這些問題，這篇文章解釋了 SRE 的含義，還有 SRE 怎樣關聯 DevOps，以及在工程師團隊規模不大的組織里 SRE 該如何工作。

什麼是站點可靠性工程？

谷歌的幾個工程師寫的《 SRE：谷歌運維解密 》被認為是站點可靠性工程的權威書籍。谷歌的工程副總裁 Ben Treynor Sloss 在二十一世紀初 創造了這個術語 。他是這樣定義的：「當你讓軟體工程師設計運維功能時，SRE 就產生了。」

雖然系統管理員從很久之前就在寫代碼，但是過去的很多時候系統管理團隊是手動管理機器的。當時他們管理的機器可能有幾十台或者上百台，不過當這個數字漲到了幾千甚至幾十萬的時候，就不能簡單的靠人去解決問題了。規模如此大的情況下，很明顯應該用代碼去管理機器（以及機器上運行的軟體）。

另外，一直到近幾年，運維團隊和開發團隊都還是完全獨立的。兩個崗位的技能要求也被認為是完全不同的。SRE 的角色想嘗試把這兩份工作結合起來。

在深入探討什麼是 SRE 以及 SRE 如何和開發團隊協作之前，我們需要先了解一下 SRE 在 DevOps 範例中是怎麼工作的。

SRE 和 DevOps

站點可靠性工程的核心，就是對 DevOps 範例的實踐。 DevOps 的定義 有很多種方式。開發團隊（「dev」）和運維（「ops」）團隊相互分離的傳統模式下，寫代碼的團隊在將服務交付給用戶使用之後就不再對服務狀態負責了。開發團隊「把代碼扔到牆那邊」讓運維團隊去部署和支持。

這種情況會導致大量失衡。開發和運維的目標總是不一致 —— 開發希望用戶體驗到「最新最棒」的代碼，但是運維想要的是變更盡量少的穩定系統。運維是這樣假定的，任何變更都可能引發不穩定，而不做任何變更的系統可以一直保持穩定。（減少軟體的變更次數並不是避免故障的唯一因素，認識到這一點很重要。例如，雖然你的 web 應用保持不變，但是當用戶數量漲到十倍時，服務可能就會以各種方式出問題。）

DevOps 理念認為通過合併這兩個崗位就能夠消滅爭論。如果開發團隊時刻都想把新代碼部署上線，那麼他們也必須對新代碼引起的故障負責。就像亞馬遜的 Werner Vogels 說的 那樣，「誰開發，誰運維」（生產環境）。但是開發人員已經有一大堆問題了。他們不斷的被推動著去開發老闆要的產品功能。再讓他們去了解基礎設施，包括如何部署、配置還有監控服務，這對他們的要求有點太多了。所以就需要 SRE 了。

開發一個 web 應用的時候經常是很多人一起參與。有用戶界面設計師、圖形設計師、前端工程師、後端工程師，還有許多其他工種（視技術選型的具體情況而定）。如何管理寫好的代碼也是需求之一（例如部署、配置、監控）—— 這是 SRE 的專業領域。但是，就像前端工程師受益於後端領域的知識一樣（例如從資料庫獲取數據的方法），SRE 理解部署系統的工作原理，知道如何滿足特定的代碼或者項目的具體需求。

所以 SRE 不僅僅是「寫代碼的運維工程師」。相反，SRE 是開發團隊的成員，他們有著不同的技能，特別是在發布部署、配置管理、監控、指標等方面。但是，就像前端工程師必須知道如何從資料庫中獲取數據一樣，SRE 也不是只負責這些領域。為了提供更容易升級、管理和監控的產品，整個團隊共同努力。

當一個團隊在做 DevOps 實踐，但是他們意識到對開發的要求太多了，過去由運維團隊做的事情，現在需要一個專家來專門處理。這個時候，對 SRE 的需求很自然地就出現了。

SRE 在初創公司怎麼工作

如果你們公司有好幾百位員工，那是非常好的（如果到了 Google 和 Facebook 的規模就更不用說了）。大公司的 SRE 團隊分散在各個開發團隊里。但是一個初創公司沒有這種規模經濟，工程師經常身兼數職。那麼小公司該讓誰做 SRE 呢？其中一種方案是完全踐行 DevOps，那些大公司里屬於 SRE 的典型任務，在小公司就讓開發者去負責。另一種方案，則是聘請專家 —— 也就是 SRE。

讓開發人員做 SRE 最顯著的優點是，團隊規模變大的時候也能很好的擴展。而且，開發人員將會全面地了解應用的特性。但是，許多初創公司的基礎設施包含了各種各樣的 SaaS 產品，這種多樣性在基礎設施上體現的最明顯，因為連基礎設施本身也是多種多樣。然後你們在某個基礎設施上引入指標系統、站點監控、日誌分析、容器等等。這些技術解決了一部分問題，也增加了複雜度。開發人員除了要了解應用程序的核心技術（比如開發語言），還要了解上述所有技術和服務。最終，掌握所有的這些技術讓人無法承受。

另一種方案是聘請專家專職做 SRE。他們專註於發布部署、配置管理、監控和指標，可以節省開發人員的時間。這種方案的缺點是，SRE 的時間必須分配給多個不同的應用（就是說 SRE 需要貫穿整個工程部門）。 這可能意味著 SRE 沒時間對任何應用深入學習，然而他們可以站在一個能看到服務全貌的高度，知道各個部分是怎麼組合在一起的。 這個「三萬英尺高的視角」可以幫助 SRE 從系統整體上考慮，哪些薄弱環節需要優先修復。

有一個關鍵信息我還沒提到：其他的工程師。他們可能很渴望了解發布部署的原理，也很想盡全力學會使用指標系統。而且，雇一個 SRE 可不是一件簡單的事兒。因為你要找的是一個既懂系統管理又懂軟體工程的人。（我之所以明確地說軟體工程而不是說「能寫代碼」，是因為除了寫代碼之外軟體工程還包括很多東西，比如編寫良好的測試或文檔。）

因此，在某些情況下讓開發人員做 SRE 可能更合理一些。如果這樣做了，得同時關注代碼和基礎設施（購買 SaaS 或內部自建）的複雜程度。這兩邊的複雜性，有時候能促進專業化。

總結

在初創公司做 DevOps 實踐最有效的方式是組建 SRE 小組。我見過一些不同的方案，但是我相信初創公司（儘早）招聘專職 SRE 可以解放開發人員，讓開發人員專註於特定的挑戰。SRE 可以把精力放在改善工具（流程）上，以提高開發人員的生產力。不僅如此，SRE 還專註於確保交付給客戶的產品是可靠且安全的。

via: https://opensource.com/article/18/10/sre-startup

作者： Craig Sebenik 選題： lujun9972 譯者： BeliteX 校對： wxy

本文由 LCTT 原創編譯， Linux中國 榮譽推出

點擊「了解更多」可訪問文內鏈接

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！