網站可靠性工程（SRE）和DevOps是兩個具有相當多重疊的熱門學科。在過去，一些人認為SRE是與DevOps相競爭的一組實踐。但我們不認為他們有那麼大差別。
SRE是什麼？它與DevOps有什麼關係？ 今年早些時候，我們（Liz Fong-Jones[1]和 Seth Vargo[2]）釋出了一組影片試圖來回答這些問題並減少社群間的摩擦。在這篇博文裡面我們將對這個系列中的每個影片做個主題和課程總結，以提供要實現更好更可靠系統的可行步驟。
我們以理解SRE與DevOps之間的異同點來作為開始，為接下來來的討論奠定基礎。
DevOps運動的緣起是因為很早之前開發者編寫程式碼但對程式碼如何在生產環境執行知之甚少。他們會把寫好的程式碼隔“牆”扔給運維團隊，由後者來負責程式的部署和持續執行。這很容易導致兩個團隊的關係緊張，而且每個團隊的優先順序與實際的業務需要並不一致。這樣DevOps作為一種文化和一組實踐出現了，致力於彌合軟體開發與軟體運維之間的鴻溝。但是，DevOps並沒有明確定義應該如何做才能在這些方面獲得成功[3]。DevOps就好比是程式開發中的抽象類或者介面, 它定義了整個系統的總體的行為，但是具體的實現細節就留給作者。
21世紀初SRE在Google內部獨立於DevOps運動發展起來，最初只是為了滿足內部的需要。它碰巧將DevOps的哲學具體化了，但它本身包括一種更標準規範的方式透過工程和運維來測量和獲得穩定性。換句話說，SRE針對如何在不同的DevOps領域獲得成功給出了藥方。例如，下麵這張表描述了DevOps五大支柱和相對應的SRE實踐：
| DevOps |
SRE |
| 減少組織內的孤立 |
透過在整個技術棧使用同樣的工具和技術來與開發者一同承擔 |
| 接受失效是常態 |
使用一個公式在新版本釋出和事故/失效之間做平衡 |
| 實現漸進式變更 |
實現漸進式變更 |
| 使用工具和自動化 |
鼓勵“將今年的工作自動化掉”，最少化人工操作，以此將精力集中到能給系統帶來長期價值的工作上 |
| 測量一切 |
堅信運維是一個軟體問題。定義標準化的方法來測量可用性，執行時間，中斷和苦力 |
*苦力： toil，關於何為toil下文還有論述。
你可以將DevOps想象為一種程式語言裡面的一個介面，而SRE類實現了這個介面。雖然SRE程式最初並沒有顯式表達要滿足DevOps介面，但是兩種理論最後都得到了相似的一組結論。但是就像程式語言，類裡面常常會包含比它們的介面定義中的多得多的行為，它們甚至可能實現多個介面。SRE包括了DevOps之外的其他的實踐和推薦。
DevOps與SRE對於軟體開發和運維來說並不是競爭的關係，而是親密的戰友，致力於交付更快更好的軟體而將組織的藩籬推垮。如果你想找書來看，那麼可以看看Betsy Beyer、Niall Richard Murphy、Liz Fong-Jones等人合著的How SRE relates to DevOps[4]，裡面有十分詳盡的解釋。
SRE這門學科透過工程師，PO（product owner）和客戶的輸入協作定義出一個系統的可用性標的和測量可用性。
如果沒有一個一致認可的方式來描述系統的線上時間和可用性，那麼對於軟體開發而言要想獲得有成效的溝通會十分困難。運維團隊不停的救火，有些最後發現是開發人員的程式碼bug造成的。但是沒有一個對線上時間的清楚衡量標準，沒有一個對於可用性的清楚優先順序串列，那麼產品團隊不會同意可靠性是一個問題。在這個世紀初這個挑戰就開始影響Google，它也是發展SRE學科的動因之一。
SRE保證：每個人都認可如何測量可用性，並且認可當可用性降低到期盼以下應該採取的措施。這個流程涵蓋了每個級別的每個參與者，上到VP，高管，好處是它創造了在整個組織內要對可用性共同承擔的一個責任。SRE與幹係人決定服務級別指標（SLI）和服務級別標的（SLO）。
這個影片也談到了SLA服務級別協議。雖然在SRE的日常工作中不會特別關註SRE，SLA是服務提供者對服務消費者關於服務可用性和無法達到所要求的服務級別的後果的承諾。SLA由代表客戶的管理人員協商定義，提供的可用性會比SLO高。畢竟我們希望在掉出客戶的SLA之前先掉出我們自己內部的SLO。
SLI，SLO和SLA緊密地與DevOps中“測量一切“的理念相結合。我們之所以說SRE實現了DevOps，這也是原因之一。
這裡我們關註透過錯誤預算來衡量風險，這是SRE和PO（product owner）一起協同工作時採取的量化方法，用來在保證可用性和新特性開發之前做取捨平衡。這個影片也討論了為什麼100%不是一個可行的可用性標的。
最大化一個系統的穩定性是違反生產規律且毫無意義的。不切實際的可用性標的會限制新特性交付給使用者的速度。而且使用者本身也不會註意到超高可用性（比如99.999999%)，因為他們的實際感受到的質量與ISP，蜂窩網路，WiFi等等這些極不可靠的服務都有很大關係。定一個100%可用性的需求會嚴重的限制一個團隊或者開發人員交付更新和最佳化的能力。Service Owner如果要交付許多的新功能，那麼他們只能選擇沒那麼苛刻的SLO，這樣即使在有bug發生時他們也能繼續交付。關註於可用性的service owner可以選擇一個更高的SLO，但是那樣的SLO會導致功能釋出延後。SRE學科將這種可接受的風險量化為“錯誤預算”。當錯誤預算耗盡時，關註點就要從功能開發轉向提高穩定性。
在第二個影片中我們提到，領導層的支援是SRE落地的關鍵因素之一。沒有這個，那麼沒什麼能限制團隊破壞已經達成一致的SLO，強迫SRE加班或者賣苦力浪費超多時間去保持系統正常執行。如果SRE團隊沒有能力去實施錯誤預算（或者說，錯誤預算沒有被人認真嚴肅的對待），那麼這套系統最終也會失效。
風險和錯誤預算量化的接受“錯誤是正常的”，讓devops團隊去實現漸進式的更新。非漸進式更新的風險比錯誤預算要大的多。
SRE學科裡一個重要的部分是苦力，苦力預算和減少苦力的方法。當每次一個運維人員在正常的運維過程中需要手工接觸一個系統的時候，苦力就產生了——但是“正常”的定義不是固定不變的。
影片，https://v.qq.com/x/page/s0678gpc8i1.html
苦力不是簡單的“我不喜歡乾的事情”。舉例來說，下麵的工作是開銷，但是明顯不能歸於苦力：提交消費清單，參加會議，回郵件，通勤等。這裡苦力是與執行一個生產上的服務緊密連線的。這種工作有如下特點：手工的，重覆性的，可以自動化的，偏戰術型，缺乏長期價值。而且苦力會隨著服務的規模增長而線性增加。每當運維人員需要接觸一個系統，比如響應一個頁面，處理一個工單或者剝離一個行程的時候，苦力就會發生。
SRE的標的是透過關註SRE中的“工程化（engineering）”元件來減少苦力。當SRE發現任務能夠被自動化時，他們會開發一個解決方案，以避免未來再花苦力。雖然最小化苦力很重要，但是要完全消滅苦力是不現實的。Google致力於保證每個SRE至少50%的時間是花在專案工程上，這些SRE每個人會在季度性的苦力調查中報告他們的苦力以此來識別運維工作過載的團隊。換句話說，苦力並不總是壞的。可預測的重覆行工作是招收新員工的非常好的途徑，而且常常會在低風險低壓力的情況下提供一種直接的成就感和滿足感。但是如果是長期的苦力，很快就會蓋過這些優勢，從而導致職業倦怠。
苦力和苦力預算與DevOps中的“測量一切”和“減少組織內壁壘”緊密相關。
最後，客戶可靠性工程這一項就將完整SRE給補齊了（還有影片中一位未來的朋友的幫忙）。CRE的標的是向客戶傳授SRE實踐並最終服務於客戶。
影片，https://v.qq.com/x/page/x0678g01vde.html
在過去一段時間，Google並沒有在公開場合談論SRE。我們認為它是我們的一個競爭優勢所以我們選擇對外部世界保密。但是每當一個客戶報了一個問題，而問題的原因是因為他們使用我們系統的方式不正確的時候，我們必須停下手頭的創新性工作而幫他們去解決問題。這雖然是很小的摩擦，但是當影響的範圍是數以十億計的使用者的時候，就會快速疊加。所以有一項工作變得明確了：我們需要開始公開的談論SRE，並且我們需要教導我們的使用者這些SRE實踐，以便他們能在自己的組織內複製。
這樣，在2016年，我們啟動了CRE[5]專案：一方面幫助我們GCP的使用者提高他們的可靠性；另一方面將客戶所面臨的挑戰直接暴露給Google SRE團隊。CRE專案的標的是透過教導客戶SRE原則和幫助他們採取SRE實踐來減少他們的焦慮。
透過在組織內強制跨部門協作，CRE與DevOps的“減少組織內藩籬”相契合。同時以所有幹係人共享的SLO的形式建立了一個共擔的責任感，從而落實了“接受失敗是一種常態”和“測量一切”的概念。
-
https://twitter.com/lizthegrey
-
https://twitter.com/sethvargo
-
https://www.sethvargo.com/the-ten-myths-of-devops/
-
https://www.safaribooksonline.com/library/view/how-sre-relates/9781492030645/
-
https://cloudplatform.googleblog.com/2016/10/introducing-a-new-era-of-customer-support-Google-Customer-Reliability-Engineering.html
原文連結：https://cloudplatform.googleblog.com/2018/05/SRE-vs-DevOps-competing-standards-or-close-friends.html
本次培訓內容包括：Docker基礎、容器技術、Docker映象、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心元件原理分析、Kubernetes服務質量保證、排程詳解與應用場景、網路、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球