什麼是 SRE（網站可靠性工程）？

本文為 Niall Richard Murphy、Jennifer Petoff、Chris Jones、Betsy Beyer 編輯的 《網站可靠性工程》 Site Reliability Engineering 一書的摘錄。

SRE（ 網站可靠性工程 （ Site Reliability Engineering ） ）在 11 月 7-10 日在阿姆斯特丹舉辦的 O'Reilly Velocity 會議上也有提到。

介紹

希望不是一種策略。 （ Hope is not a strategy. ）

—— 傳統的 SRE 如是說

一個公認的事實是系統不會自己運行。 那麼，一個系統 — 尤其是複雜大規模系統 — 應該怎麼運行呢？

系統管理員的服務管理方法

以前，公司僱用系統管理員來運行複雜的計算系統。

系統管理員（或者稱為 sysadmin）這種方式包括整合現有軟體組件，使之互相協作來完成一個服務。系統管理員的任務是運行服務，響應事件，並在事件發生時進行更新。隨著系統複雜度的增長和流量的增長，事件和更新也相應增長，導致管理員團隊也越來越龐大才能完成更多的工作。由於系統管理員的角色需要的技能與產品開發人員有很大不同，開發和系統管理員被分為不同的團隊：「開發」和「運維」。

系統管理員模式的服務管理有幾個優點。對於決定該如何運行和服務的公司而言，這種方法相對容易實現：它作為一個已被人們所熟悉的行業範例，有很多例子可以從中學習和效仿。相關人才庫已經廣泛普及。有一系列現有的工具，軟體組件（現成的或其他）和集成公司可用於幫助運行這些組裝的系統，所以新手系統管理團隊不必重新發明輪子以及從頭設計系統。

此方式將公司開發和運維分離，也有一些缺點和困難。主要有兩類：直接代價和間接代價。

直接代價很顯而易見了。利用依靠手工干預來進行變更管理和事件處理的團隊進行服務管理，當服務和/或流量增長時，成本是很昂貴的，因為團隊隨著系統負載的增長也在相應增長。

開發/運維分離的間接代價可能不那麼明顯，但常常比直接代價還要昂貴。代價來自於兩個團隊背景，技術，激勵都非常不同。他們使用不同的辭彙來描述所面臨的 情境；對技術方案的風險和可能性他們持不同的假設；對產品穩定性的目標級別也會有不同的爭議。團隊的分離很容易導致不只是激勵的不同，還有溝通、目標的不同，以及最終，信任和尊重的分離。這是一種惡性循環。

因此，傳統運營團隊及其在產品開發中的同行往往會發生衝突，最突出的是如何將軟體發布到生產環境。在開發團隊的核心上，他們希望推出新功能，並看到它們被用戶採納。在運維團隊的核心上， 他們希望確保服務在運行中不會中斷。因為大多數中斷是由某種變化引起的 - 新的配置、新的功能發布或者新的用戶流量類型 - 這兩個團隊的目標基本上處於緊張狀態。

兩個團隊都明白，以最想要的條款（「我們可以沒有阻礙地在任何時間發布任何東西」以及「我們不想在系統工作後改變任何東西」）來表達他們的利益是不可接受的。因為他們的辭彙和風險假設都不同，兩個團體經常採用常見的鬥爭形式來提高他們的利益。 運維團隊試圖通過提高發布和變更門檻來保護運行中的系統免受更改的風險。例如，發布審查可能包含對每個問題的顯式審查，這些問題過去都曾經引起過服務中斷 - 它可能是一個任意長度的列表，並且不是所有檢查元素都一樣重要。開發團隊很快學會了如何回應。他們通過較少的「發布」和更多的「功能切換」、「增量更新」或 「選擇性失明」來規避。他們採取諸如分割產品功能的策略，以便更少的功能受到發布審查。

Google 的服務管理方法：網站可靠性工程

衝突不是提供軟體服務的必然部分。Google 選擇以不同的方式運行自己的系統：我們的網站可靠性工程團隊專註於僱傭軟體工程師來運行我們的產品，並創建系統來完成那些本來由系統工程師手動完成的工作。

什麼是 網站可靠性工程 （ Site Reliability Engineering ） ，是如它在谷歌定義的那樣么？我的解釋很簡單：SRE 是當你要求一位軟體工程師設計一個運維團隊時所發生的結果。當我在 2003 年加入 Google 並負責運行一個由 7 名工程師組成的「生產團隊」時，那時我工作的全部都是軟體工程。所以我以自己是一名 SRE 的方式，設計和管理了一個我想要的團隊的樣子。這個團隊已經成為了 Google 的目前的 SRE 團隊，它仍如最初一名終生軟體工程師所想像的那個樣子。

Google 服務管理方法的主要構成部分是由每個 SRE 團隊組成的。作為一個整體，SRE 可以分為兩大類。

50-60％ 的人是 Google 軟體工程師，或者更確切地說，是通過 Google 軟體工程師的標準程序招聘的人。其他 40-50％ 的候選人非常接近 Google 軟體工程師資格（即擁有所需技能集的 85-99％），以及一些具有大多數軟體工程師沒有的一些 SRE 技術技能的人。到目前為止，UNIX 系統底層和網路（第 1 層到第 3 層）的專業知識是我們尋求的兩種最常見的替代技術技能。

所有的 SRE 的共同點是有開發軟體系統以解決複雜問題的信念和能力。在 SRE 中，我們密切跟蹤兩個團隊的職業發展，並且迄今為止發現在兩種工程師之間的表現沒有實際差異。事實上，SRE 團隊的多樣性背景經常產生聰明、高質量的系統，這顯然是幾個技能集合成的產物。

我們這樣招聘 SRE 的結果是，我們有了這樣一個團隊：（a）手動執行任務很快會變得無聊。（b）他們有必要的技能集來寫出軟體以取代以前的手動操作，即使解決方案很複雜。SRE 還會與其他開發部門分享學術以及知識背景。因此，SRE 從根本上做了一個運維團隊歷來做的工作，但它使用具有軟體專業知識的工程師，並期望這些內在傾向於使用軟體並且有能力用軟體的人用軟體設計並實現自動化來代替人力勞動。

按照設計，至關重要的是 SRE 團隊專註於工程。沒有恆定的工程，運維工作增加，團隊將需要更多的人來上工作量。最終，傳統的以運維為中心的團隊與服務規模呈線性關係：如果服務支持的產品成功，運維工作將隨著流量而增長。這意味著僱用更多的人一遍又一遍地完成相同的任務。

為了避免這種命運，負責管理服務的團隊需要寫代碼，否則就會被工作淹沒。因此，Google 為 SRE 們設置了一個 「運維」 工作的上限，如任務單、緊急呼叫、手動任務最多只佔 50% 工作量。此上限確保 SRE 團隊在其計劃中有足夠的時間使服務穩定及可操作。50% 是上限；隨著時間的推移，除了自己的設備，SRE 團隊應該只有很少的運維工作，他們幾乎可以完全從事開發任務，因為服務基本上可以運行和維修自己：我們想要的系統是自動的，而不只是自動化。在實踐中，規模和新功能始終是 SRE 要考慮的。

Google 的經驗法則是，SRE 團隊必須花費剩餘的 50％ 的時間來進行實際開發。那麼我們該如何執行這個閾值呢？首先，我們必須測量 SRE 如何花費時間。通過測量，我們確保團隊不斷花費不到 50% 的時間用於開發改變他們實踐的工作上。通常這意味著會將一些運維負擔轉移回開發團隊，或者給團隊添加新的員工，而不指派該團隊額外的運維責任。意識到在運維和開發工作之間保持這種平衡使我們能保證 SRE 具有參與創造性的自主工程的空間，同時仍然保留從運維那學來的智慧。

我們發現 Google SRE 的運行大規模系統的方法有很多優點。由於 SRE 是直接修改代碼以使 Google 的系統可以運行自己，SRE 團隊的特點是快速創新以及大量接受變革。這樣的團隊能相對價廉地支持相同的服務，面向運維的團隊需要大量的人。相反，運行、維護和改進系統所需的 SRE 的數量隨系統的大小而線性收斂。最後，SRE 不僅規避了開發/運維分裂的障礙，而且這種結構也改善了我們的產品開發團隊：產品開發和 SRE 團隊之間的輕鬆轉移交叉訓練了整個團隊，並且提高了那些在學習構建百萬級別分散式系統上有困難的開發人員的技能。

儘管有這些好處，SRE 模型的特點是其自身獨特的挑戰。 Google 面臨的一個持續挑戰是招聘 SRE：SRE 不僅與產品開發招聘流程競爭相同的候選人，而且我們將招聘人員的編碼和系統工程技能都設置得如此之高，這意味著我們的招聘池必然很小。由於我們的學科相對新穎獨特，在如何建立和管理 SRE 團隊方面沒有太多的行業信息（不過希望這本書能朝著這個方向邁進！）。一旦 SRE 團隊到位，他們潛在的非正統的服務管理方法需要強有力的管理支持。例如，一旦錯誤預估耗盡，除非是管理層的強制要求, 否則在季度剩餘的時間裡決定停止發布可能不會被產品開發團隊所接受。

DevOps 或者 SRE？

「DevOps」 這個術語在 2008 年末出現，並在寫這篇文章時（2016 年早期）仍在發生變動。 其核心原則：IT 部門在系統設計和開發的每個階段的參與、嚴重依賴自動化與人力投入、工程實踐和工具在操作任務中的應用，與許多 SRE 的原則和實踐一致。 人們可以將 DevOps 視為幾種核心 SRE原則向更廣泛的組織，管理結構和人員的推廣。 可以等價地將 SRE 視為具有某些特殊擴展的 DevOps 的特定實現。

作者簡介：Benjamin Treynor Sloss 創造了「 網站可靠性工程 （ Site Reliability Engineering ） 」一詞，他自 2003 年以來一直負責 Google 的全球運營、網路和生產工程。截至 2016 年，他管理著全球範圍內一個大約 4000 名軟硬體和網路工程師團隊。

via: https://www.oreilly.com/ideas/what-is-sre-site-reliability-engineering

作者：Benjamin Treynor 譯者：geekpi 校對：jasminepeng

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

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive