作者：By Niall Richard Murphy,Liz Fong-Jones, and Betsy Beyer,with Todd Underwood, Laura Nolan,and Dave Rensin

運維是一門很難的學科。 不但沒有解決如何很好地執行系統，即便那些已經在使用的最佳實踐也是高度依賴環境且未被廣泛採納的。 並且最重要的，沒有解決如何良好地管理運維團隊這一問題。人們普遍認為，對這些問題的詳細分析源於二戰期間致力於改善盟軍軍事程序和產出的作戰研究，但事實上，長期以來我們一直都在思考如何更好地實踐。

儘管有這麼多的努力和想法，可靠的生產運維仍然是難以保障的,特別是在資訊科技和軟體可操作性領域， 例如:

企業通常將運維視為成本中心， 這使得對結果進行有意義的改進變得困難甚至不可能。 這種短視的方法還沒有被廣泛理解， 但對它的不滿卻已經引發了IT領域對如何組織工作方面的一場革命。

這場革命源於試圖解決一系列普遍問題， 並誕生了兩個不同的解決方案: DevOps 和 SRE(Site Reli‐ability Engineering)。 儘管單從描述上看，他們是企業完全不同的兩個方面，需要單獨討論，但事實上，它們的相似之處，要遠比我們想象的多。

但首先，我們需要來了解一下每種原則的背景。

 

 

DevOps產生的背景

DevOps是一套鬆散的實踐，指南和文化，旨在打破IT開發，運維，網路和安全方面的孤立。 是由John Willis，Damon Edwards和Jez Humble提出，使用CA(L)MS表示：文化（Culture），自動化（Automation），精益（Lean， 如精益管理;也包含持續交付），測量（Measurement,）和分享（Sharing） -- 這是一個記住DevOps哲學要點很有用的縮寫。 而分享和合作是這一運動的重中之重。 在DevOps方法中，您可以改進某些內容（通常通過自動化實現）、測量結果，並與同事分享這些結果，以便整個組織得到改進。 所有CALMS原則都是由支援文化促進的。

DevOps，Agile以及各種其他業務和軟體工程技術，都是關於如何在現代世界中進行最佳實踐的示例。DevOps哲學中的任何元素彼此都不能輕易分離，這是由基本設計來決定的。 但是，有一些關鍵的想法可以相對分開地討論。

 

不再孤立

第一個關鍵點是：不再孤立。 有兩種觀點能夠體現:

• 曾經流行將運維和開發團隊分別獨立，但現在卻越來越過時。

• 在許多情況下，極端的知識孤立化、純粹的對內部優化的激勵以及缺乏協作對商業是十分不利的。

 

事故是正常的

第二個關鍵點是：事故不僅僅是由個人的孤立行動造成的，更是當問題不可避免地發生時，缺乏防範措施的結果。例如，一個糟糕的介面在不經意間助長了壓力下的錯誤行為；如果出現（未知的）錯誤，系統缺陷將不可避免地導致失敗；監控失效使得人們不可能知道是否出了問題，更不用說出了什麼問題。一些傳統觀念更強的企業，擁有開除犯錯者並懲罰他們的文化。但這樣做有其自身的惡果： 他會誘使人們混淆問題、掩蓋真相和指責他人， 而所有這些最終沒有任何價值，專注於恢復服務比阻止事故發生要更有價值。

 

變更應該是循序漸進的

第三個關鍵點是， 小而頻繁的變更是最佳的。 一個比較激進的示例，是變更委員會每月開會討論徹底修改大型機配置的計劃，然而這種做法並不鮮見，所有變更必須由經驗豐富的人員進行有效的規劃，結果或多或少與最佳實踐相悖。變更是有風險的，沒錯，但是正確的做法是將變更儘可能拆分成更小的元件或單元。然後，根據產品、設計和基礎架構的變更，構建穩定的低風險變更管道。（Then you build a steady pipeline of low-risk change out of regular output from product, design, and infrastructure changes）這種策略，增加對小變更的自動化測試和異常變更的可靠回滾，就形成了管理變更的方法：持續整合(CI)和持續交付或部署(CD)。

 

工具和文化是相互關聯的

工具是DevOps的一個重要組成部分，特別是強調正確管理變更的今天，變更管理依賴於高度定製化的工具。 但總的來說，DevOps的支持者十分強調組織文化 - 而不是工具 - 這是成功採用新工作方式的關鍵。 一個好的文化可以解決破碎的工具，但相反的情況很少適用。 俗話說， 文化能把戰略當早餐吃(意味著文化的影響力遠勝過策略)。 與運維一樣，變更本身也很難。

 

度量是至關重要的

最後，度量在整個業務環境中尤為重要，例如，打破孤立和故障處理。 在上述的每種場景中，你可以通過客觀的度量來確定正在發生事情的真實性，驗證改變是否符合預期，併為不同職能部門達成一致的對話建立客觀基礎。 （這適用於商業和其他環境，例如On-call。）

 

SRE產生的背景

SRE是由Google的工程副總裁Ben Treynor Sloss提出的術語（和相關的工作角色）。正如我們在上一節中所看到的，DevOps是運維和產品開發之間在整個生命週期互相協作的一系列廣泛原則。SRE是一個工作角色，也是我們發現的一組實踐（稍後介紹），以及一些激勵這些實踐的信念。如果您將DevOps看作一種哲學和工作方法，則可以認為SRE實現了DevOps描述的一些哲學，並且比“DevOps工程師”更接近於這個工作或角色的具體定義。因此，在某種程度上，SRE類實現了DevOps介面。

與DevOps運動不同，DevOps運動起源於多家公司的領導者和從業者之間的合作，而SRE在整個行業廣泛普及之前，則是由Google的SRE繼承周圍公司的大部分文化。 考慮到這一軌跡，整個SRE學科目前並沒有像DevOps那樣在文化上突然增長。 （當然，這並不能說明文化變革對在任意組織中進行SRE是否是必要的）

SRE由以下具體原則定義。

 

運維是一個軟體問題

SRE的基本原則是：做好運維是一個軟體問題。 因此，SRE應使用軟體工程來解決這一問題。 這涉及廣泛的領域，涵蓋了從流程和業務變更到同樣複雜但更傳統的軟體問題的所有內容，例如重寫堆疊以消除業務邏輯中的單點故障。

 

通過SLOs進行管理

SRE不會嘗試提供100％的可用性。 正如我們的第一本書 《Site Reliability Engineering》中所討論的，這是錯誤的目標， 原因有很多。 相反，產品團隊和SRE團隊為服務及其使用者群選擇適當的可用性目標，並管理服務達到該目標，選定這樣的目標需要業務部門的強大協作。 SLOs也具有文化內涵：作為利益相關者之間的協作決策，SLO違規行為將團隊無可厚非地帶回到原點。

 

減少瑣事

對於SRE來說，任何手動的， 重複性的的運維任務都是令人憎惡的。 （這並不意味著我們沒有任何此類任務：我們有很多這樣的操作。我們只是不喜歡它們。）我們相信，如果機器可以執行所需的操作，那麼通常應該讓機器來執行。 這是一種區別(也是一種價值)，在其他組織中並不常見。在那裡，瑣事就是工作，而這就是你付錢讓一個人去做的事情。而對於在谷歌環境下的SRE來說，瑣事不是工作——它不可能是。任何在操作任務上花費的時間都意味著無法再投入到專案工作上——專案工作才能使我們的服務可靠和可擴充套件。

然而，通過“the wisdom of production”，執行運維任務確實為決策提供了重要的參考。這項工作通過提供來自給定系統的實時反饋資訊來保持穩定。（This work keeps us grounded by providing real-time feedback from a given system.）瑣事的來源需要明確，這樣可以最小化或消除它們。然而，如果你發現自己處於操作不足的狀態，那麼你可能需要更頻繁地推動新特性和更改，以便工程師依舊熟悉你所支援的服務的工作方式。

The Wisdom of Production

A note on “the wisdom of production”: by this phrase, we mean the wisdom you get from something running in production—the messy details of how it actually behaves, and how software should actually be designed, rather than a whiteboarded view of a service isolated from the facts on the ground. All of the pages you get, the tickets the team gets, and so on, are a direct connection with reality that should inform better system design and behavior.

 

把今年的工作自動化

在這個領域真正要做是，確定哪些工作基於什麼樣的條件，以什麼樣的方式要完成自動化。（The real work in this area is determining what to automate, under what conditions, and how to automate it.）

在Google，經驗豐富的SRE嚴格限制團隊成員花費在瑣事上的時間，與之相反的是他們會在產生持續價值的工程類工作中花費50%的時間。許多人認為這個限制是一個上限。 事實上，將它視為一種保證更為有用，一種明確的宣告和啟用機制，採用基於工程的方法來解決問題，而不是一遍又一遍地辛勞的解決問題。

當我們考慮自動化和瑣事時，基線和其如何發揮作用並不直觀。（There is an unintuitive and interesting interaction between this benchmark and how it plays out when we think about automation and toil.） 隨著時間的推移，一個SRE團隊最終會將服務的大部分操作自動化，只留下無法自動化的（Murphy-Beyer效應）。 在其他條件相同的情況下，除非採取其他行動，否則SRE團隊所做的事情就會受到影響。 在google你更傾向於通過不斷新增服務來達到填滿50%的工程設計時間的限制，或者你在自動化方向做的非常成功，以至於你可以去做一些完全不同的事情。

 

通過降低故障成本來快速行動

日益提高的可靠性只是SRE帶來的眾多收益中的一種，事實的確如此，它實際上提高了開發的產出。為什麼呢？對於常見故障，減少故障平均修復時間（ Mean Time To Repair）會提高產品開發人員的速度，因為工程師不必在這些故障問題之後耗費時間和精力進行處理。這源於一個眾所周知的事實，在一個產品的生命週期裡，問題發現的越晚，修復它所付出的代價越高。SREs專門負責改善異常問題的過晚發現，為公司整體帶來收益。

 

與開發分享許可權

“應用程式開發”和“生產”（有時被稱為Dev和Ops）之間的嚴格界限會適得其反。 如果專案事務處的職責劃分和作為成本中心的分類，導致權力不平衡、尊重或薪酬方面的差異，則尤其如此。

SREs往往傾向於關注生產而不是業務邏輯問題，但隨著問題被他們用軟體工程工具所解決，他們與產品開發團隊分享技術棧。 通常，SREs在他們正在關注的服務的可用性，延遲，效能，效率，變更管理，監控，應急響應和容量規劃方面具有特殊的專業知識。 那些特定的（通常定義明確的）能力是SRE對產品和產品的開發團隊所做的貢獻。理想情況下，產品開發和SRE團隊應該對技術棧有一個整體的看法 - 前端，後端，庫，儲存，核心和物理機器 - 沒有團隊應該令人嫉妒的擁有著單個元件。事實證明，如果你“模糊線條”並使用SREs共苦JavaScript，或者產品開發人員對核心進行限定，你可以做得更多：知識如何進行更改，許可權更加廣泛，而激勵小心翼翼地保護任何特定的功能這一想法都應摒棄。

在《Site Reliability Engineering》這本書裡,，我們沒有明確表明Google中的產品開發團隊預設擁有自己的服務。 SRE既不可用也不保證大部分服務，儘管如此，SRE原則仍然可以告知整個Google如何管理服務。 SRE團隊與產品開發團隊合作時的所有權模式最終也是一個共享模型。

 

使用相同的工具，無論功能或職位

工具是一個非常重要的行為決定因素， 在Google的環境中，SRE如果沒有統一的程式碼庫、軟體和系統的各種工具、高度優化和專有的生產堆疊等是非常天真的。我們與DevOps分享這個絕對的假設：團隊服務應該使用相同的工具，無論他們在組織中的角色如何。 沒有好的方法來管理一個服務，當該服務具有一個用於SRE的工具，一個用於產品開發人員的工具，在不同情況下表現不同（並且可能具有災難性）。 當擁有的分歧越多，公司從改進每個工具努力中的獲益就越少。

 

比較和對比

從上面聊到的原則中，我們可以立即看到他們之間有很多共性：

• DevOps和SRE都接受一種理念，即為了改進，變更是必要的（都接受對於提高而言，變更是必要的）。否則，就沒有多少可操作的空間。

• 協作是DevOps工作的前沿和中心。 有效的分享所有權模式和合作夥伴關係是SRE發揮作用所必需的。 與DevOps一樣， SRE也具有跨組織分享的強大價值，這樣更容易打破團隊之間的孤立。

• 變更的最佳實踐是: 持續小而頻繁的變更，大多數操作理想情況下應該是：自動化測試和部署。變更和可靠性之間的關鍵互動使得這對於SRE尤為重要。

• 正確的工具至關重要，工具在一定程度上決定了你的行為範圍。然而，我們決不能過於關注是否使用某些特定工具實現某種操作；歸根結底，面向系統管理的API是更為重要的哲學，它將比任何特定的實現都持久。

• 度量絕對是DevOps和SRE如何工作的關鍵。對於SRE, SLOs (服務質量目標) 決定著是否改善和優化服務。當然，如果沒有度量( 以及在產品、基礎設施/SRE和業務之間的跨團隊合作)，就不可能有SLOs。對於DevOps，度量行為通常用於理解流程的輸出是什麼，反饋週期的持續時間是什麼，等等。DevOps和SRE都是面向資料的東西， 無論是從專業角度還是從哲學角度。

• 管理生產服務的殘酷現實意味著故障時有發生，您必須說明原因。SRE和DevOps都進行了無可厚非的故障覆盤，以抵消爭議。

• 最終，實施DevOps或SRE是一種整體行為; 兩者都希望通過高度特定的方式共同合作，使整個團隊（或單位或組織）更好。 對於DevOps和SRE，更好的速度就是產出。

如你所見，DevOps和SRE之間有許多的共同點。

然而，也存在著顯著的差異。DevOps在某種意義上是一個更廣泛的哲學和文化。因為它影響的變化範圍比SRE更廣，所以DevOps對上下文更敏感。 DevOps對於如何在一個具體層面上執行操作沒有更詳細的說明。例如，它不是關於服務的精確管理的規定。相反，它選擇專注於在更廣泛的組織中打破壁壘。這就很有價值。

另一方面，SRE的職責定義相對狹窄，其職權範圍通常是面向服務（面向終端使用者）而非整體業務。 因此，它為如何有效執行系統的問題帶來了自以為是的知識框架（包括錯誤預算等概念）。 雖然作為一個職業，SRE非常清楚激勵措施及其影響，但它反過來卻對孤立化和資訊壁壘等主題保持沉默。 它將支援CI和CD，不一定是因為業務需要，而是因為所涉及的操作實踐得到了改進。 或者，換句話說，SRE相信和DevOps一樣的東西，但原因略有不同。

 

組織環境與成功採納的培養

DevOps和SRE在其執行方式上存在非常大的概念重疊。 正如您所料，他們也有一組類似的條件必須在組織內成立，以便他們 a)首先可以實現，並且 b)從該實現中獲得最大的好處。 正如托爾斯泰幾乎從未說過的：有效的操作方法都是相似的，而失敗的方法都有各自的失敗之處。 激勵機制可以部分解釋這一點。

如果組織的文化重視DevOps方法的好處並且願意承擔這些成本 - 通常表現為招聘困難，維持團隊和責任，流動性所需的能量，以及用於補償必要技能所增加的財務資源，這更為罕見 。然後該組織還必須確保激勵措施是正確的，以實現這種方法的全部好處。

具體而言，以下內容應在DevOps和SRE的環境中都應成立。

教條，剛性的激勵措施限制了你的成功

許多公司無意中定義了破壞集體績效的激勵措施。為了避免這種錯誤，不要將激勵機制侷限於與釋出相關或可靠性相關的結果。正如任何一位經濟學家都能告訴你的那樣，如果有一個數字衡量標準，人們總會找到一種方法，讓它產生不好的效果，有時甚至是以一種完全出於善意的方式。相反，你應該允許其他人自由地找到正確的選擇。正如前面所討論的，DevOps或SRE通常可以作為產品團隊的催化劑，允許其他軟體組織以連續可靠的方式向客戶提供功能。這種動態機制還解決了傳統和分散的系統/軟體組方法的一個永續性問題：設計和生產之間缺乏迴圈反饋。具有早期SRE參與的系統（理想情況下，在設計時）通常在部署後的生產中工作得更好，而不用管是誰負責管理服務。 （沒有什麼比丟失使用者資料更能阻礙功能開發的進展。）

 

最好自己解決這個問題; 不要責怪別人

此外，要避免把生產事故或系統故障的責任推給其他組。在許多方面，推卸責任的動力是傳統工程操作模型的核心問題，因為運維和軟體團隊允許出現單獨的激勵機制。不管怎樣，考慮採用以下做法來反駁組織層面的指責:

• 不僅僅只是允許，而是積極鼓勵工程師在產品需要時改變程式碼和配置。還應允許這些團隊在其任務範圍內採取激進行動，從而消除採取緩慢行動的想法。

• 支援事後總結。這樣做排除了淡化或掩蓋問題的動機。這一步驟對於充分理解產品並實際優化其效能和功能至關重要，並且依賴於前面提到的生產經驗。

允許對“執行困難並且不可挽救的”產品不進行支援。 支援暫停這種產品，直到產品開發在支援準備階段和產品本身得到支援之後再修復該問題，從而節省每個人的時間。 根據您的背景，“執行困難並且不可挽救的”的含義可能會有所不同 - 這裡的動態應該是相互理解的責任之一。 對其他組織的推遲可能會更為溫和，“我們認為使用這種技能的人有更多的時間”，或者限制在“這些人員將會因為過多的操作工作而沒有機會使用他們的工程技能。“在Google，直接撤銷此類產品支援的做法已成為一種制度。

 

將可靠性工作視為一個專門的角色

在谷歌，SRE和產品開發是獨立的組織。每個小組都有自己的重點、優先順序和管理，而不需要對另一個小組發號施令。然而，當產品成功時，產品開發團隊將有效地資助新員工SRE的提升。這樣，產品開發與SRE團隊的成功息息相關，就像SREs與產品開發團隊的成功息息相關一樣。SRE也很幸運地得到了管理層的大力支援，這使得工程師團隊認可了“SRE”這一角色。儘管如此，你不需要有一個組織結構圖來做不同的事情，但是你需要一個不同的實踐社群。

不管你是使用組織結構圖還是使用非正式的機制，重要的是要認識到專業化會帶來挑戰。DevOps和SRE的實踐者可以從一個同伴社群中獲得支援和職業發展，以及一個用來獎勵他們獨特的技能和觀點的職業階梯。

值得注意的是，Google採用的組織結構以及上述一些激勵措施在某種程度上依賴於規模龐大的組織。 例如，如果您的20人創業公司只有一個（相對較小的）產品，那麼允許運維退出支援沒有多大意義。 仍然可以採用DevOps風格的方法，但是，如果您能做的僅僅只是幫助它成長，那麼改善操作性差的產品的能力就會受到損害。不過，對於如何滿足這些增長需求，與技術債務累積的速度相比，人們通常有比想象中更多的選擇。

 

何時可以替代

但是，當您的組織或產品增長超過一定規模時，您可以在支援哪些產品或如何確定支援優先順序方面行使更大的自由度。 如果很明顯，對系統X的支援將比支援系統Y更快地發生，那麼隱式條件可以發揮同樣的作用,選擇不支援服務的行為。

在谷歌，SRE與產品開發的強大合作關係已被證明至關重要：如果您的組織存在這種關係，那麼撤回（或提供）支援的決定可以基於有關的客觀資料來比較運營特徵，從而避免非生產性的交涉。

SRE與產品開發之間的富有成效的關係也有助於避免產品開發團隊在產品或功能準備就緒之前必須交付的組織反模式。相反，SRE可以與開發團隊合作，在維護負擔轉移到具有最多專業知識的人員之前改進產品。

 

爭取平等的尊重：職業與薪酬

最後，確保正確的職業激勵措施到位：我們希望我們的DevOps/SRE組織能夠像他們的產品開發夥伴一樣受到尊重。因此，每個團隊的成員應按大致相同的方法進行評級，並具有相同的薪酬激勵。

 

結論

在IT運維整體領域的許多方面，DevOps和SRE在實踐和理念上都非常接近。

DevOps和SRE都需要討論、管理支援、並從實際工作人員那裡來獲得重大進展。 實施其中任何一個都是一段旅程，而不是一個快速解決方案：rename-and-shame（重新命名和羞恥的）做法是空洞的，不太可能帶來收益。 鑑於它是對如何執行操作的更具見解性的實現，SRE對於如何在此過程中更早地更改您的工作實踐有更具體的建議，儘管需要進行特定的調整。DevOps關注的範圍更廣了，因此很難對其進行推理並將其轉化為具體的步驟，但恰恰是因為更廣泛的關注，可能會遇到較弱的初始阻力。

但是，每種方法的實踐者都使用許多相同的工具、相同的方法來改變管理，以及相同的基於資料的決策思維方式。最終，我們都面臨著同樣的問題:生產，讓它變得更好——不管我們被稱為什麼。

對於那些有興趣進一步閱讀的人，以下建議可以幫助您更廣泛地瞭解目前正在進行的運維革命的文化，業務和技術基礎：

• Site Reliability Engineering

• Effective DevOps

• The Phoenix Project

• The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2

• Accelerate: The Science of Lean Software and DevOps