什么是SRE(Site Reliability Engineering)？

從根本上說，當您要求軟件工程師設計操作功能時會發生這種情況。軟件工程師傾向于使用軟件來解決歷史上手工解決的問題。因此，當需要創建一個正式的團隊來完成這項運營工作時，很自然地將“一切都視為軟件問題”的方法與之一起運行。

因此，SRE從根本上開展了一項歷史上由運營團隊完成的工作，但使用具有軟件專業知識的工程師，并依賴于這些工程師本身就傾向于并且有能力替代人工自動化的事實。

最重要的是，在谷歌，我們有一系列參與規則，以及SRE團隊如何與他們的環境互動的原則 - 不僅是生產環境，還包括開發團隊，測試團隊，用戶等等。上。這些規則和工作實踐有助于我們繼續主要從事工程工作而不是運營工作。

這如何反映在SRE團隊的日常工作和責任中？

通常，SRE團隊負責可用性，延遲，性能，效率，變更管理，監控，緊急響應和容量規劃。

今天許多運營團隊都有類似的角色，有時沒有我發現的一些部分。但SRE的做法卻截然不同。這是由于幾個原因造成的。

排名第一的是招聘。我們聘請具有軟件開發能力和傾向性的工程師。

對于SRE，軟件工程師是對編程語言，數據結構和算法以及性能有足夠了解的人，能夠編寫有效的軟件。至關重要的是，雖然軟件可能在啟動時完成任務，但即使任務增長，它也必須高效地完成該任務。

通常情況下，我們雇傭大約50-50名擁有更多軟件背景的人和擁有更多系統背景的人。這似乎是一個非常好的組合。

在我們的招聘過程中，我們會檢查即將通過Google SWE欄的人員，以及誰還有一套對我們有用的補充技能。網絡工程和Unix系統管理是我們看到的兩個常見領域; 還有其他人。一個擁有良好軟件技能但可能沒有專業開發經驗的人，他也是網絡工程或系統管理方面的專家 - 我們雇用這些人進行SRE。通常，我們雇傭大約50-50名擁有更多軟件背景的人和擁有更多系統工程背景的人。這似乎是一個非常好的組合。

多年來我們一直認為這個招聘規則是不變的，即使在很難找到人的時候也是如此，為了增加招聘量，放松這個準則的壓力很大。我們從未改變過這方面的標準。我認為，這對該集團來說非常重要。因為你最終得到的是一個團隊，他們從根本上不會接受手工一遍又一遍地做事，而且還有一個與開發組織其他人有很多相同學術和知識背景的團隊。這確保了SRE和SWE之間的相互尊重和相互融合。

通常在操作角色中看到的與工程角色相反的事情之一是，不僅在職責方面存在鴻溝，而且在背景和理解方面存在鴻溝，最終還是尊重。對我來說，這是一種病態。

在Google之外，我們經常觀察到SWE和運營團隊之間沒有平等的尊重，這與他們經常有不同做法的事實相結合。這就是我們最終得到當今行業中存在的模型的方式，SWE團隊在這些模型中寫了一些東西并將其扔到了運營團隊的墻上，然后運營團隊試圖讓它運作，并且不能，并將其丟回，等等。

在這種背景下，有趣的是，還要考慮使SRE成為現實的組織差異，而不僅僅是個人的工作習慣。

SRE的一個關鍵特征是它們可以在SRE團隊之間自由轉移，并且該團隊足夠大，可以擁有充足的移動性。此外，SWE可以自由轉到SRE。但是，一般來說，他們沒有。

這種行動自由的必要條件是一般的SWE，恰好是SWE的SRE，以及SRE中的系統工程師之間的補償平等。他們所有的團體都遵循相同的績效標準，相同的產出標準，相同的專業標準。SWE和SRE SWE團隊之間有免費轉移。關于SRE組中任何發現他們正在處理項目或“糟糕”系統的人的自由和輕松遷移的關鍵點在于它是一個極好的威脅，為開發團隊提供了一個不構建系統的激勵跑得太可怕了。

這是我一直使用的威脅。說，“看，基本上，我們只雇用工程師進入SRE。如果你建立一個操作災難的系統，SRE將會離開。我會讓他們。” 當他們離開并且團隊降到臨界質量以下時，我們會將運營責任交給您，即開發團隊。

在谷歌，我們已將這種回應制度化，包括生產準備評估（PRR）。PRR通過在接受之前檢查系統及其特征，以及通過共同承擔責任來幫助我們避免陷入這種情況。這是我所知道的最簡單，最有效的方法，可以消除任何關于現實世界中系統的幻想。它還為開發團隊提供了一個巨大的激勵，使其能夠構建一個運行負載較低的系統。

獲得正確的激勵措施非常重要。為此，為什么SRE很稀缺很重要？

我們將分配SRE，以便他們做最好的事情。

在早期，我們沒有太多的選擇方式。我們不能像對它們的需求一樣快地雇用SRE，因此總是存在稀缺性。我通過簡單地說“我們將SRE分配到他們將要做的最好的地方”來利用它。僅運營項目的投資回報率相對較低。我沒有把SRE放在那些上面。還有其他項目更加成熟和成熟，這些項目的SRE將具有更高的邊際效益。從歷史上看，我們所看到的是一個SRE將取代兩個從事相同工作的SWE，部分原因是它們往往是生產相關技術和支持模型的專家。粗略地說，這是幫助SRE需求保持高位的方程式。

SRE如何確保一旦啟動，就能正確維護？

我們非常關心保持SRE的工程功能，因此我們的經驗法則是SRE團隊必須至少花費50％的時間進行開發。

SRE每季度進行一次服務評估，旨在衡量團隊的運營工作量。您可以習慣這種工作負載，并將大部分時間花在操作上。評論是外部檢查，以確保如果您進入該模式，我們會注意到并采取糾正措施，這有時可能意味著解散團隊！

我們非常關心保持SRE的工程功能，因此我們的經驗法則是SRE團隊必須至少花費50％的時間來實際開發。那么你如何執行呢？首先，你必須測量它。在測量之后，您確保團隊在開發工作上花費不到50％的時間用于重定向或解散。

我不知道工業同類工作的50％分工。

確實; 就谷歌的SRE與其他理念上的“SRE”工作之間的區別而言，這將是了解你所涉及的內容的簡單方法之一。因此，當您與其他小組進行面談，并與團隊中您可能會加入的人員交談時，請嘗試了解他們最近編寫了多少行代碼，以及他們的工作時間花在了多少上？編寫代碼。如果他們的答案是“我上個月寫了三個函數”，那么，你有答案。

在Google SRE中，無論系統或軟件背景如何，我們都會密切關注每個人的促銷率，并將其與整體Eng and Eng Software Engineering促銷價格進行比較，以確保它們在統計上相同。<u>他們是</u>。

您可以問的另一個問題是，他們是在SRE團隊內部還是在SRE團隊外部工作的資深開發人員？他們多久經常升職？他們的推廣率是否與SWE團隊相同？

在Google SRE中，無論系統或軟件背景如何，我們都會密切關注每個人的促銷率，并將其與整體Eng and Eng Software Engineering促銷價格進行比較，以確保它們在統計上相同。他們是。

你能談談運營和發展小組中的一些更經典的沖突嗎？

開發團隊的動機是啟動功能并讓用戶采用該產品。而已！具有運維職責的團隊的動機是確保事物不會在他們的手表上爆炸。所以這兩個人肯定會處于緊張狀態。

業界的一個典型沖突是，運營團隊提出了一個長清單，開發團隊必須經過這些清單才能說出支持的內容。這是一個重要的沖突，因為它是你清楚地看到兩個群體的激勵實際上是不同的地方之一。剝離其他所有東西時，開發團隊的動機就是啟動功能并讓用戶采用該產品。而已！如果你剝奪了其他所有東西，那么具有運營職責的團隊的動機就是確保事情不會在他們的手表上爆炸。所以這兩個人肯定會處于緊張狀態。你是如何解決這個問題的？

業務或產品必須確定系統的可用性目標。完成后，減去可用性目標就是我們所說的<u>錯誤預算</u>。

理想情況下，我們會花費所有不可用預算來承擔我們推出的產品的風險，以便快速啟動它們。

我們在SRE中的解決方案 - 它運行得非常好 - 是一個錯誤預算。錯誤預算源于這一基本觀察：100％是基本上所有事情的錯誤可靠性目標。也許心臟起搏器是一個很好的例外！但是，一般而言，對于您可以想到的任何軟件服務或系統，100％不是正確的可靠性目標，因為沒有用戶可以區分100％可用的系統，比如99.999％可用。因為通常在用戶和正在運行的軟件服務之間存在許多其他因素，所以其他所有可能出錯的噪音都會丟失邊際差異。

如果100％是系統的錯誤可靠性目標，那么系統的正確可靠性目標是什么？我建議這是一個產品問題。這根本不是技術問題。這是一個問題，考慮到用戶支付的金額，無論是直接還是間接，以及他們的替代品是什么，用戶會對此感到滿意。

業務或產品必須確定系統的可用性目標。一旦你完成了這個，減去可用性目標就是我們所說的錯誤預算; 如果99.99％可用，則意味著它不可用0.01％?，F在我們被允許有0.01％的不可用性，這是一個預算。我們可以把它花在任何我們想要的東西上，只要我們不超支它。

那么我們想要在錯誤預算上花多少錢？開發團隊希望啟動功能并獲得用戶。理想情況下，我們會花費所有不可用預算來承擔我們推出的產品的風險，以便快速啟動它們。這個基本前提描述了整個模型。一旦你以這種方式概念化SRE活動，那么你說，哦，好吧，所以有分階段推出或1％實驗的東西，所有這些都是讓我們的不可用預算少于風險的方法，以便我們可以采取我們推出的機會更多，因此我們可以更快地推出。聽起來不錯。

這種方法還有另一個好的結果，即如果服務本身就位于那里并拋出錯誤，你知道，.01％的時間，你將整個不可用預算都用在什么東西上。因此，您在開發領域和SRE團隊中都有動力來提高服務的本地穩定性，這樣您就可以節省預算，例如功能發布。

另一個關鍵優勢是SRE不再需要對開發團隊正在做什么做出任何判斷。SRE測量和執行，但我們不評估或判斷。我們的看法是“只要您測量它的可用性高于您的服務水平目標（SLO），您顯然做得很好。您正在做出關于風險有多大的準確決策，您應該運行多少實驗等等。所以你要把自己踢出去，發動任何你想要的東西。我們不會干涉?！?這一直持續到你打破預算為止。

一旦你預算完畢，我們就不知道你的測試情況如何。開發團隊和SRE團隊之間可能存在巨大的信息不對稱關于功能，風險程度，測試程度，工程師是誰等等。我們通常不知道，我們猜測也不會有成效。所以我們甚至都不去嘗試。我們可以恢復可用性級別的唯一可靠方法是停止所有啟動，直到您獲得了不可用性。這就是我們所做的。當然，這種情況很少發生，但確實發生了。我們只是凍結啟動，而不是P0錯誤修復 - 這些東西本身代表了改進的可用性。

這有兩個很好的效果。其一，SRE并不在這場猜測開發團隊正在做什么的游戲中。因此，不需要對抗關系或信息隱藏或其他任何東西。那正是你想要的。

另一件事，也就是我沒想到但事實證明非常重要的一點是，一旦開發團隊發現這就是游戲的運作方式，他們就會自我警察。通常，對于我們在Google運營的那種系統，它不是一個開發團隊; 它是一群致力于不同功能的小型開發團隊。如果從個體開發者的角度考慮這個問題，這樣的人可能不會想要一個測試不佳的功能來破壞錯誤預算并阻止一周后出現的酷炫發布。鼓勵開發人員找到團隊的總經理，以確保在發布之前完成更多測試。通常，開發團隊內部的信息不對稱程度遠遠低于開發團隊和SRE團隊之間的信息不對稱性，

SRE的道德權威說不，目前在谷歌已經確立。

這至關重要。

外部組織如何啟動SRE功能有助于獲得此權限？

道德權威是一個物理問題。確定目標SLO的前期至關重要，因為這是您同意測量服務的標準。那時SRE只是衡量和執行我們已經同意的事情。非常方便的位置。

就你如何實際產生道德權威而言，這很容易。您，開發團隊已經告訴我們這項服務的SLO必須是什么，現在我們低于它。我們無能為力; 這是一個物理問題。你現在無法改變主意。我們已經確定這個數字符合用戶的最佳利益 - 目前，數據清楚地表明我們低于這個數字。所以我們必須等到我們回到可用性級別。您可以使用這段等待時間來確保您的下一個版本不會再次爆炸。

我們來談談SRE團隊的生命周期。在生命周期中，參與度如何變化？

今天通常采用的方式是通過能力成熟度 模型。有很多，他們都大多說同樣的事情。他們都從基本問題開始，你知道你作為一個團隊在做什么嗎？或者你只有一個人的集合，每個人都知道問題空間的一部分？大多數球隊都是從那時開始的; 你有一群人，每個人都知道一些事情，當你需要做某事時，你會嘗試讓具有足夠綜合專業知識的人能夠完成你所需要的。

通過這種方式，當服務出現問題時，結果取決于人員是誰。這就是我們所說的混亂局面。隨著團隊的成熟，你會從混亂變為定義; 也就是說，你開始說“這是我們做的標準事情，并且它們也有記錄，以便團隊中的任何人都能做到?！?您不再依賴于碰巧在那里的個人的隨機選擇。從那里，您可以進行優化，實際測量它們。既然你已經說過，“這就是應該發生的事情”，你看看實際發生了什么，并將它與應該發生的事情進行比較。然后，您可以更改說明或更改人們的行為方式或兩者，并永久重復或直到完成。

因此，任何隨著服務規模線性擴展人數的事情都將失敗。

我們在季度服務評論（前面討論過）中衡量的一個因素是SRE的環境是什么樣的。無論他們說什么，他們有多開心，他們是否喜歡他們的開發對手等等，關鍵是要實際衡量他們的時間。這有兩個重要原因。一，因為你想盡快發現團隊已經把他們的大部分時間花在了運營工作上。您必須在此時停止并更正它，因為每個Google服務都在增長，而且通常，它們的增長速度都超過了人數的增長速度。因此，任何隨著服務規模線性擴展人數的事情都將失敗。如果您將大部分時間花在操作上，那么這種情況就無法自我糾正！你最終會遇到危機，你現在把所有的時間都用在了運營上，但仍然不夠，然后服務要么停機或者出現另一個重大問題。

第二個是，這是一個工程團隊。如果你看一下團隊??中的人，他們的職業生涯和他們的目標不會通過繞過關票或配置資源來進一步發展。他們擁有他們和經理想要發展的工程技能和專業知識。這是開發的，因為他們是軟件工程師，通過編寫軟件并與更高級，經驗豐富，能力強的人合作，并學習。所以你必須確保他們真的在做那些事情。

讓我們討論監督，一個核心的SRE責任。你能談談SRE和監控背后的哲學嗎？

一種經典的監控方式是，你有一些看到價值或條件或其他東西的東西，當它看到有趣的東西時，會吐出一封電子郵件。這是我所知道的最常見的監控。但是電子郵件不是正確的方法; 如果你要求人閱讀電子郵件并決定是否需要做某事，那你就犯了一個錯誤。答案應該是，人類永遠不會在警報領域解釋任何東西。解釋由我們編寫的軟件完成。我們只是在需要采取行動時得到通知。

因此，在我看來，只有三種有效的監控輸出。有警報，說人類現在必須采取行動。正在發生或即將發生的事情，人類需要立即采取行動來改善這種狀況。

第二類是門票。人類需要采取行動，但不是立即采取行動。您可能有幾個小時，通常是幾天，但需要一些人為操作。

第三類是記錄。沒有人需要查看此信息，但它可用于診斷或法醫目的。期望是沒有人讀它。

我從未見過監測輸出不屬于這三類之一。我經?？吹饺藗冊趯嵤┍O控時會犯錯，這樣他們就會生成日志，但會將其視為票證。這是一個很大的錯誤。你通常發現它的一個地方是：“哦，是的，我們不得不花費大量時間來審查我們的監控系統吐出的所有這些東西。” 好吧，不要那樣做。這不會擴展，因為你有更多的用戶和更多的實例，這些東西的數量將增加，質量將下降。您需要開發一個系統，無論是監視配置還是解析器或其他什么，您需要編寫一個系統，將該輸出轉換為三個類別之一。

因此，監控可以幫助您注意事情何時失敗，還可以幫助您更快地解決問題？

是的。更一般地說，當我們談論整體系統可用性時，它有兩個基本組件。失敗之間有平均時間 - 事情停止工作的頻率。然后有平均時間進行修復 - 一旦它停止工作，需要多長時間才能修復它？

這兩個功能的一些功能是您的可用性。從中脫穎而出，有兩種方法可以建立一個高度可用的系統。（當然，如果數字堆積起來，這些極端之間的任何地方也都可以。）你可以很少失敗，或者當它失敗時你能夠很快地修復它。Google因其極高的可用性而享有當之無愧的聲譽。而SRE得到的方式就是兩者兼而有之。

在第一級 - 這是我們花費大部分時間的地方 - 我們構建了能夠容忍失敗的系統。我們在優雅退化以及深度防御方面談論這一點。它們是同一事物的兩種不同變體。事情會失敗。重要的是，當事情發生故障時，用戶體驗不會有意義地降級，讓您有足夠的時間來修復它們，而不會出現用戶可見的問題。因此，對于大多數故障，MTTR是毫秒，因為它是自動化的。通常，沒有人會在不到兩分鐘的時間內對出錯的事情作出反應。因此，如果您想要在沒有用戶影響的情況下失敗的事情，獲得??它們的最佳方法是自動修復它們。我們通過深度防御來做到這一點。

系統的所有不同層都設計為容忍點故障，甚至是數據中心大小的點故障，而不會影響用戶體驗。一切都是自動發生的。沒有人抬起手指，沒有人經常需要知道它。它剛剛發生。這是深度防守。

優雅降級是指在不完全崩潰的情況下容忍失敗的能力。例如，如果用戶的網絡運行緩慢，環聊視頻系統將降低視頻分辨率并保留音頻。對于Gmail，速度較慢的網絡可能意味著無法加載大型附件，但用戶仍可以閱讀其電子郵件。所有這些都是自動回復，無需人工執行任何操作即可為您提供高可用性。

人類必須做某事的情況怎么樣？

一旦人類實際上必須做某事，那么MTTR很重要。特別是，“R”部分并不意味著人類已經獲得了頁面或者人類已經對頁面進行了分類，或者甚至是人類已經使用鍵盤來做某事。這是人類正確評估情況并采取適當的糾正措施，而不是診斷錯誤或采取無效措施。

在其他行業，您有操作手冊; 我們有運營就緒演習，這就是我們如何確保人們知道如何正確應對各種緊急情況。然而，如果你讓一群軟件工程師在一起并說“我們將要進行操作準備演練”，那么指令膜將會滑落到他們的眼睛上，無論你是否知道，這將有效地成為談話的終點是不是。解決這個問題的一種可能方法是從角色扮演游戲中獲取靈感。軟件中有很多人在某個時刻玩過角色扮演游戲，其余人一般都至少聽過這些游戲。

因此，雖然沒有人愿意進行戰斗準備演習，但每個人都想參加“不幸之輪”游戲。在這種背景下，不幸之輪只不過是一個統計調整的選擇機制，用于挑選災難，其次是角色扮演，其中一個人扮演地下城主人的角色 - 在這種情況下，“系統” - 和另一個人扮演待命工程師的角色。文檔人員會收聽，我們會記錄場景中發生的事情，隨叫隨到的工程師說要做什么，然后我們將這與他們實際應該做的事情進行比較。然后，我們將調整我們的劇本 - 我們的操作手冊術語 - 為理想的答案提供額外的信息或背景。

使SRE在運營領域發揮作用的部分原因是，您可以在緊急情況下對人們進行正確的響應，直到他們不必考慮它為止。我們以一種文化兼容的方式做到這一點：如果你看過SRE團隊這樣做，人們真的很期待這些練習，因為這是一個展示你所知道的東西的機會，而且很有趣。

我們談到了SRE的一些責任，但不是全部。容量規劃怎么樣？

可以將需求預測和容量規劃視為確保您對預測的未來需求有足夠的防御深度。沒有什么特別之處，除了大多數公司似乎沒有這樣做。

谷歌SRE和其他工作地點之間的另一個區別問題是，你在N + M運行你的服務是什么？一個常見的答案是“我不知道，因為我們從未評估過我們的服務能力是什么”。

他們可能不會這么說。但是，如果他們不能告訴你他們如何對他們的服務進行基準測試，以及他們如何衡量其對100％或130％的負載的響應，以及他們在高峰需求時有多少備用容量，那么他們就不知道了。在沒有需求預測或容量規劃的情況下，您可以預期頻繁停機和大量緊急情況。

在傳統模型中，IT是成本中心。它們基本上是關于防止損失，并且因為它們被視為成本中心，所以沒有特別的動機去改變。在SRE模型中，我們有能力提高效率，擴展容量，并有助于提高產品的運行效率。在這個模型中，高級決策者的動機是什么？

因此，有兩層激勵措施可以提高效率。一個是SRE人數不是免費的。產品區域獲得一定數量的人數。他們可以將它們花在開發者身上，也可以將它們花在SRE上。理論上，他們將在SRE上花費盡可能多的時間來獲得最佳特征速度，同時滿足他們的服務SLO。事實上，這實際上是我們希望他們在SRE上花多少錢 - 不多也不少。因此，這是他們對自己的SRE節儉的一種激勵，同時也要小心他們的團隊編寫的代碼，這樣就不會產生很多SRE團隊需要處理的工作。另外，如果您構建了錯誤的代碼，那么所有優秀的SRE都會離開，您最終要么自己運行它，要么最好還有一個愿意冒險的初級團隊。

第二點是，一旦您意識到容量對可用性至關重要，那么您就會意識到SRE團隊必須負責容量規劃，這意味著他們還必須負責配置和變更管理。因此，您可以根據服務的工作方式以及配置的方式獲得利用率。因此，根據定義，SRE必須參與任何有關利用的工作，因為它們最終會控制供應。因此，通過密切關注您的配置策略，您可以獲得非常大的總成本杠桿。

由于競爭環境的加劇，Google SRE是否遭受了損失？其他組織使用“SRE”一詞怎么樣？

一般來說，我們發現當人們離開其他組織時，他們通常會回來。目前，谷歌SRE與其他公司如何做的事情有所不同，我希望這些公司能夠采用這些公司。這只是運行事物的好方法。

它當然需要大量的管理支持和依賴數據來做出決策。當問題進入高級管理層時，已經發生了幾次; 在這種情況下，技術基礎設施副總裁，最終，首席執行官。他們總是支持SRE團隊，因此人們甚至不再費心去嘗試了。您可能無法在所有公司獲得這種管理支持。

關于差異化的話題，您是否熟悉術語“DevOps”？

我很熟悉。幾年前我開始遇到它。它似乎描述了那些正在做與SRE類似的事情的人，并且確實讓我們認為讓開發人員加入我們的運營團隊，我認為這非常好。

該術語不具有統一的定義。讓開發人員與運營人員密切合作是個好主意。問題是它會影響運營，如果你購買SRE的方式，那就是錯誤的愿景。

是的，“DevOps”在實踐中的意義似乎存在很多差異。在過去的15年中，我們已經迭代到當前的SRE定義，關鍵部分包括狀態平價，自由轉移，稀缺性，運營負載上限，錯誤預算等。我已經看到這個定義在谷歌的實踐中非常有效，我希望我們會繼續發展它，使這個角色對開發人員更具吸引力，同時使其更有效地運行高效，高可用性，大型系統。

在過去的15年中，我們已經迭代到當前的SRE定義。

我希望我們將繼續發展它，使這個角色對開發人員更具吸引力，同時使其更有效地運行高效，高可用性，大規模的系統。