業界流行的一個說法是：一套系統如果已經開發完成，部署在正式作業環境上，那麼它就是「穩定的」，就不需要那麼多工程師花費精力去最佳化、維護。我們認為這種說法是錯誤的，從這個角度來看，如果軟體工程主要專注於設計和建構軟體系統，那麼應該有另外一種職業專注於整個軟體系統的生命週期管理：從其設計一直到部署，歷經不斷改進，最後順利除役。這樣一種職業必須具備非常廣泛的技能，並且和其他職業的專注點不同，Google將這個職位稱為網站可靠性工程師（SRE, Site Reliability Engineering）。

網站可靠性工程師究竟代表著什麼呢？的確，這個詞語並無法清晰地描述這個職位的意義，基本上每個Google SRE都經常被問到這個職位的意義，以及他們的日常工作究竟是什麼。

將這個語詞展開來說：首先，也是最重要的一點，SRE是工程師（engineer），SRE應用電腦科學和軟體工程手段來設計和研發大型、分散式電腦軟體系統。有的時候，SRE和產品研發團隊共同工作，其他時候我們需要開發這些系統的額外元件：例如備份系統和負載平衡系統等。理想情況下，同時推展這些元件在多個專案中重複使用。還有的時候，我們的任務是想出各式各樣的辦法，利用現有元件解決新的問題。

其次，SRE的關注焦點在於可靠性。Google負責全天候（7×24）維運的副總裁Ben Treynor Sloss是SRE名稱的發明者，他宣稱可靠性應該是任何產品設計的最基本概念：任何一套系統若無法讓人能夠穩定使用，就沒有存在的意義。因為可靠性是如此重要，因此SRE專注對其負責的軟體系統之架構設計、維運流程不斷最佳化，讓這些大型軟體系統執行得更可靠，擴展性更好，能更有效地利用資源。但是，SRE並不是無止境地追求完美：當一套系統已經「夠可靠」的時候，SRE通常將精力轉而投入研發新的功能和創造新的產品。

最後，SRE的主要工作是維運在分散式叢集管理系統上執行的具體業務服務（service），不論是遍布全球的儲存服務，還是億萬使用者賴以工作的E-mail服務，還是Google最初的Web搜尋服務。SRE中的「S」最開始指的是google.com網站的維運服務，因為SRE的首要工作就是維持網站正常運轉。隨著時間進展，SRE逐漸接管了Google內部絕大部分正式系統，包括Google Cloud Platform這類開發者平台，也包括內部的一些非網站類的基礎設施系統，例如Bigtable。

如果一定要為SRE尋找一個起源的話，誰才能夠被稱為世界上第一位SRE呢？

我們選擇MIT的Margaret Hamilton教授，她參與阿波羅登月計畫的軟體開發工作，其工作具有現代SRE的一切特性，用她自己的話來講：「團隊文化就是從一切經歷中不斷學習，包括來自那些我們最意想不到的經歷。」

在Apollo 7太空船研發期間的某一天，Margaret帶著她的小女兒Lauren一起來到公司。當Margaret忙著和組員們在大型電腦上執行飛行模擬測試時，她的小女兒偷偷地按下了控制臺上的DSKY鍵，整個模擬程式出乎意料地當機了，導致整個火箭發射程式意外終止。Margaret和組員除錯後發現，原來Lauren意外觸發執行P01這段子程式，導致整個模擬過程失敗。該子程式是起飛前調校程式，執行時會刪除現存的導航資訊，如果在火箭飛行中執行這段程式，電腦將無法繼續維持火箭航線，會造成重大災難。

憑藉著SRE的直覺，Margaret向專案小組提交一份軟體變更，申請在飛行程式中增加一項特殊狀態檢查，以避免飛行員在飛行過程中意外觸發P01程式。但不幸的是，NASA的高層認為：這項錯誤發生的可能性太小，根本不值得為此新增這項修改。因此Margaret並未成功提交這項軟體修改，她只能在火箭飛行手冊中加註一段文字，寫道：「在飛行過程中，請勿觸發P01程式」。在當時增加這段文字，很多NASA工程師都覺得很好笑，認為Margaret小題大做，幾乎所有人都認為太空人經過如此漫長時間的專業訓練，絕對不會犯如此低級的錯誤。

幾天後，在Apollo 8太空船執行下一項飛行任務時，太空人Jim Lovell、William Anders和Frank Borman三人在執行一項長達四天的飛行計畫途中，Jim Lovell意外地觸發執行P01程式，更巧的，當天正好是聖誕節，大部分工程師都休假去了，可想而知，當時NASA一片混亂。這次不是演習，而是人命關天的危急時刻，如果不能及時解決，三名太空人將永遠無法安全返回。所幸，Margaret在更新飛行手冊時也提到這種情形，並且提供重新上傳資料以及恢復執行的辦法，在有限的時間內解決了問題，使任務可以繼續進行。

Margaret曾經說過：「無論對一套軟體系統的執行原理掌握得多麼徹底，也不能阻止人為的意外錯誤。」在這次危機過後，Margaret之前提交的修改申請很快就被批准了。

雖然Apollo 8的事故發生在幾十年前，但是工程師們一定不會對此感到陌生，類似的情節總是在不斷重演，希望讀者以史為鑑，只有不懈關注細節，做好充足的災害預擬和準備工作，隨時保持警戒，不放過絲毫能避免災害發生機會，這就是SRE最重要的理念！

系統管理員模式

業界一直以來的普遍做法是聘僱系統管理員（sysadmin）來負責複雜系統的維運。這些系統管理員（administrator或sysadmin）負責將現成的軟體元件部署於正式作業環境中，對外提供某種業務服務，他們的主要工作在於處理系統產生的各種需要人為干預的事件，以及來自業務部門的需求變更。隨著系統規模變得越來越複雜，安裝的元件越來越多，使用流量不斷上升，相關的事件和需求變更也與日俱增，於是公司需要招聘更多的系統管理員。系統管理員的日常工作與研發工程師相差甚遠，通常分屬兩個不同的部門：「開發部」（Dev）和「維運部」（Ops）。

這種合作模型有許多優點，對新設公司來說，業界已有許多應用案例可供參考，市場上有相關經歷的從業人員也很多，招聘相對容易，而且市面上有許多現成的輔助工具或軟體元件可用，系統整合廠商也有對應的解決方案，可以輔助新成立的系統管理員團隊處理簡單的維護作業，避免重新發明輪子。

不過鮮少有人提到這種做法及Dev/Ops分離的團隊模型存在一些無法避免的問題，主要可從下面兩個大方向來說明。

1. 直接成本。這很容易理解，因為系統管理員團隊大部分依賴人工處理系統維護事件及變更，隨著系統複雜度的增加，部署規模的擴大，團隊的大小基本上會與系統負載成正相關增長。

2. 間接成本。研發團隊和系統維運團隊分屬兩個部門所衍生的間接成本就沒那麼容易估量，往往會比直接成本高很多，由於研發團隊和維運團隊背景各異，技術能力與工具使用習慣也有很大差距，再者，工作目標也截然不同，兩支團隊對產品的可靠程度要求有不同理解，就實務而言，對某項作業的風險評估及可能的防範措施要求也存在落差或代溝。日積月累，這些細節上的分歧終將演化成目標與方向上的差異及內部溝通問題，甚至影響部門之間的信任與尊重。這樣的情形是誰也不願意見到的，但卻是時時上演的。

傳統的研發團隊和維運團隊主要分歧點在於軟體版本、設定變更後的發行速度上。研發部門主要關注的是如何能夠更快速地建構和發行新功能，維運部門則更關心在他們值班期間如何避免故障發生。由於大部分正式系統故障常因部署某項變更而引起的，不管是新版本，還是修改設定，有時甚至只因調整使用者的某些行為，使負載流量分配比率發生變化而導致故障。就個別的業務目標來看，這兩個部門可說是相互矛盾的。

嚴格來說，研發部門想要「隨時隨地發行新功能，不要有任何阻攔」，而維運部門則想要「一旦在正式作業環境中正常工作了，就不要再進行任何改動」，由於兩個部門截然不同的心態，對風險的定義也不一致。在現實生活中，公司內部這兩股力量只能用最傳統的政治鬥爭方式來保障各自利益，維運團隊常常宣稱任何變更在上線前必須通過維運團隊制定的流程，這有助於避免事故發生。例如：維運團隊會列出一份很長的檢核表，臚列過往曾經發生過的事故，要求研發團隊在任何功能上線之前必須將所有這些事故模擬一遍，確保不會重複出現，這份清單可能沒有任何標準，每項事故的可重現程度、問題價值不見得一致。開發團隊在吃過苦頭之後也很快找到因應的辦法：他們宣稱不再「進行」大規模的程式更新，而是逐漸改以「功能開關調整」、「增量更新」，以及「錯誤修補」，採用這些名詞的唯一目的就是為了繞過維運部門設立的各種流程，從而能更快地發行新功能。

Google的解決之道：SRE

SRE模型是Google嘗試著從根本解決前述矛盾的結果，SRE團隊透過聘請軟體工程師開發軟體系統來維護系統執行，以代替傳統模型中的人工操作。

SRE究竟是如何在Google發跡的呢？其實我的答案非常簡單：SRE就是讓軟體工程師來設計一組新型維運團隊的成果。當我在2003年加入Google時，我的任務就是領導一支由七名軟體工程師組成的「正式作業環境維運小組」，當時，我的整個職業生涯都專注於軟體工程，自然而然按照自己最習慣的工作方式和管理方式來籌建這支團隊，時過境遷，當年的七人小組已經成長為公司內部1000餘人的SRE團隊，但是SRE團隊的理念和方針，基本上仍保持我最初的想法。

SRE方法論中的主要模組，就是SRE團隊的構成，每個SRE團隊裡基本上有兩類工程師。

第一類是團隊中50%~60%的軟體工程師，也就是通過正常的Google軟體工程師招聘流程所僱用的人；另一類佔40%~50%，是滿足Google軟體工程師標準（具備85%~99%所要求的技能），但同時擁有一定程度的其他技術能力的工程師。目前來看，UNIX系統內部細節和第1至3層網路經驗是Google最看重的兩種額外的技能。

除此之外，所有的SRE團隊成員都必須非常願意、也非常相信用軟體工程方法可以解決複雜的維運問題，Google一直密切關注這兩類人選在獲得聘用後於SRE團隊的表現，截至目前為止還沒有發現他們在工作和績效上有何顯著差異，事實上，由於這兩類工程師的技術背景互補，SRE團隊常能夠找到全新的、高效的問題解決方法。

按照這個標準招聘和管理SRE團隊，很快發現SRE團隊成員具有如下特點：

1. 打從心底排斥重複性、手工性的作業。

2. 有足夠的技術能力快速開發出軟體工具來取代手工操作。

同時，SRE團隊和產品研發部門在學術和工作背景上非常相似，因此可以說SRE就是運用軟體工程的思維和方法，完成由傳統系統管理員團隊手動處理的任務，這些SRE傾向於利用設計、建構自動化工具來取代人工操作。

SRE模型成功的關鍵在於對工程的關注，如果沒有持續工程化的解決方案，維運的負荷將會不斷增加，團隊也就需要更多的人來分攤工作。傳統維運團隊規模基本上會與所服務的產品負荷成正相關，如果一套產品非常成功，使用者流量越來越大，就需要更多團隊成員來重複進行同樣的工作。

為了避免這一點，維運團隊必須要有足夠的時間撰寫自動化維運程式，否則就會被維運工作所淹沒，因此，Google為所有SRE團隊從事傳統維運工作訂立一個50%的上限值，傳統維運工作包括：工單處理、輪值待命（on-call）、手工操作等。訂立上限值可確保SRE團隊有足夠時間維護系統正常、穩定，讓系統更容易維護，這個上限值並不是目標值，隨著時間演進，SRE團隊應該傾向消弭所有的基本維運工作，全力投入研發任務，讓整個系統可以自主執行，自動修復問題，終極目標是推動整個系統趨向於無人化執行，而不僅是將人工作業自動化。當然，實務上，不斷擴張的服務規模和新功能發行已經讓SRE夠忙了！

依照Google的經驗法則，SRE團隊必須將50%的精力花在真實的開發工作上。那麼要如何確保每支團隊都這樣做呢？首先，必須不斷地度量每支團隊的工作時間分配，根據這些資料，對於投入開發工作時間不足的團隊，SRE管理階層會進行調整，通常會要求該團隊將一些常見的維運工作交還產品研發部門負責，或者從產品研發部門抽調人力參與團隊on-call工作，此外，還可以停止該SRE團隊的一切新增維運工作。只有管理階層主動維持每個SRE團隊的工作均衡，才能保障他們有足夠時間和精力進行真正有創造性、自主性的研發工作，同時，也保障SRE團隊有足夠的維運經驗，進而設計出確實解決問題的系統。

我們發現Google SRE模型在維運大規模複雜系統時有很多優勢，由於SRE在調整Google系統的過程中常常直接參與開發、修改程式碼，SRE文化在公司內部基本上是代表一種快速、創新、擁抱變化的文化，實際證明SRE團隊執行、維護、改進一套複雜系統所需要的成員數量不會與系統部署規模呈正相關增長，對於維運同樣規模的系統，傳統的系統管理員模型可是需要更多人力。最後，SRE模型不僅消除了傳統模型中研發團隊和維運團隊的衝突，反而推升整個產品部門的水準，因為SRE團隊和研發團隊之間的成員可以自由流動，整個產品部門的人員都有機會學習和參與大規模維運部署活動，從中獲得寶貴知識。普通的開發人員能有多少機會將自己的程式同時執行於100萬顆CPU的分散式系統上呢？（摘錄整理自《網站可靠性工程｜Google的系統管理之道》）

 書籍資訊 

網站可靠性工程｜Google的系統管理之道

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Murphy／著；孫宇聰／譯

碁峰資訊出版

售價：780元

 作者簡介 

Betsy Beyer

Google紐約分部專責SRE的技術文件作家，之前曾為遍布全球的Google資料中心與Mountain View硬體維運團隊撰寫文件。

Chris Jones

Google App Engine的SRE。每天處理超過280億個請求。

Jennifer Petoff

Google SRE團隊的專案經理。

Niall Murphy

Google愛爾蘭團隊廣告SRE的負責人。