SRE的含義及與 DevOps 如何關聯？

雖然站點可靠性工程師（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 還專一於確保交付給客戶的產品是可靠且安全的。