各情境中的 SRE

在我們探討與 SRE 相關的一些做法前，應該先將我們在上一個單元學到的想法加入脈絡中。 在這個簡短單元中，我們會了解 SRE 背後的一些歷史，及其如何與您可能熟悉的其他維運做法相關。 此知識會讓我們準備好邁向成功，因為這些做法放入脈絡中會更有道理。 此外，當您的朋友問「SRE 和...有什麼不同」的時候，您會有一個明確的答案。

歷史

用極為精簡的方式來說，SRE 在 2003 年發源於 Google。 Ben Treynor 現在是 Treynor Sloss，接管 Google「生產小組」 (然後只有七位軟體工程師)。 Treynor 建立了這個想法，並著名地將其描述為「這就是要求軟體工程師去設計作業功能的後果。」 了解這段歷史很有幫助，因為這說明了為什麼第一次接觸的維運人員，會覺得 SRE 非常「軟體工程」。 SRE 採用了該領域的價值和工具當作基本工具，例如撰寫程式碼和原始檔控制系統的重要性。 Google SRE 初始和目前的實作完整記載於 O'Reilly 發行的兩本書中 (請參閱「使用者入門」單元)。

隨著 Google 的人們離開了公司 (以及公司裡的人們公開談論他們的做法)，SRE 開始擴張到這個產業中更多的組織中。 隨著 SRE 擴張到新的組織，那些組織採用並調整了 SRE 的準則和做法，以符合自身的文化。 這個擴充過程在 SRE 領域中產生了許多不同的實作方法。

DevOps 與 SRE

有更多產業面臨相同的挑戰，諸如調整、開發速度與營運穩定性，及其他造成網站穩定性工程變動的軟體傳遞問題。 在 Google (及當時較大的幾間公司) 之外，為了處理這些問題而同時付出的努力讓 DevOps 誕生。

如需大量關於 DevOps 的良好資訊，請參閱 DevOps 資源中心。

SRE 和 DevOps 的差異仍然是該領域中經常討論的主題。 有一些廣泛同意的差異，包括：

• SRE 是著重於可靠性的工程專業領域。 DevOps 則是一種文化運動，源於打破與開發和營運組織兩者間隔閡的需求。
• SRE 可以是「我是網站可靠性工程師 (SRE)」這個角色的縮寫名稱，但是 DevOps 不能。 嚴格來說，沒有人可以用 "DevOps" 來維生。
• SRE 傾向提高精準度，DevOps 則刻意不然。 就這方面而言，這兩者最接近的部份是幾乎共同採用了持續整合/持續傳遞和敏捷準則。

DevOps 和 SRE 這兩種維運做法都喜好監視/監測能力和自動化 (但原因可能不同)。 此匯流是其中一個原因，可以說明為什麼在已經有 DevOps 做法的組織中導入 SRE 作法與準則，通常較為容易。 執行這個過程必須多加留意與專注。 此流程也可以而且應該以累加方式實作。 不必突然就切換過去。

結論

這個簡短的單元已經為 SRE 和 DevOps 提供了一小部分的脈絡。 SRE 和 DevOps 最適合被視為作業實務中相近的思想學派。

既然我們已經稍微了解了 SRE 的背景，讓我們馬上來看看一些核心準則。