Aug 3, 2018
[好文翻譯] 你在找的是 SRE 還是 DevOps？
敝社這半年來開始大舉徵才，其中不乏 DevOps 和 SRE 的職缺，然而 HR (或其他部門的同事)對於兩者的相異之處並不瞭解，甚至認為 SRE 和傳統維運單位一樣，只是換個名字，從管機房到管雲端而已，究竟兩者到底有什麼差別呢？
這對前來的面試的應徵者會有負面的影響，好像連我們自己要找什麼樣的人都不清楚似的。於是，花了點時間跟 HR 介紹兩者的差異，也在支援了 SRE 團隊四個月後留下這篇翻譯文加一點點心得。
請先記得…
SRE is a DevOps (香蕉是一種水果)
DevOps is NOT a SRE (水果不是香蕉)
DevOps 並不是一個 "工作職稱"，SRE 才是
《本文已取得原作者之一 Seth Vargo 同意翻譯刊登》
正文開始
Site Reliability Engineering (SRE)和 DevOps 是目前相當熱門的開發與維運文化，有著很高的相似程度。然而，早期有些人會把 SRE 視為和 DevOps 不同的實踐方式，認為兩者不一樣，必需選擇其一來執行，但是現在大家更傾向兩者其實其實很相似。
究竟 SRE 和 DevOps 有什麼相同點呢？在年初，Google 的工程師 (Liz Fong-Jones 與 Seth Vargo) 準備了一系列的影片去解答這些問題以及嘗試跳出來去減少社群間的意見分歧，本篇文章總結了影片中所涵蓋到的主題，以及如何實際去建置一個更加可靠的系統。
1. SRE 和 DevOps 的差異
在開始之前，先瞭解一下 SRE 和 DevOps 有什麼相同之處？又有什麼相異之處？
DevOps 文化的興起是因為在早期(約十年前)，有許多開發者對於自己的程式是怎麼跑在真實世界，其實所知有限。開發者要做的事情就是將程式打包好，然後扔給維運部門後，自己的工作週期就結束了，而維運部門會負責將程式安裝與部署到所有生產環境的機器上，同時也要想盡各種辨法與善用各種工具，確保這些程式持續正常地執行，即使維運部門完全不瞭解這些程式的實作細節。
這樣的工作模式很容易造成兩個部門之間的對立，各自的部門都有自己的目標，而各自的目標和公司商業需求可能會不一致。DevOps 的出現是為了帶來一種新的軟體開發文化，用以降低開發與維運之間的鴻溝。
然而，DevOps 的本質並不是教導大家怎麼做才會成功，而是訂定一些基本原則讓大家各自發揮，以程式設計的術語來說，DevOps 比較像是一個抽象類別(abstract class)，或是介面(interface)，定義了這種文化該有什麼樣的行為，實作則是靠各個部門成員一起決定，只要符合這個「介面」，就可以說是 DevOps 文化的實踐。
SRE 一詞由 Google 提出，是 Google 在這十多年間為了解決內部日漸龐大的系統而制定出一連串的規範和實作，和 DevOps 不同的是，它實作了 DevOps 的所定義的抽象方法，而且規範了更多關於如何用軟體工程的方法與從維運的角度出發，以達成讓系統穩定的目的。簡單來說，SRE 實作了 DevOps 這個介面(interface)，以下列出五點 DevOps 定義的介面以及 SRE 如何實作：
DevOps：減少組織之間的穀倉效應
SRE：在整個開發週期中，和開發團隊使用相同的工具以及一起分享與所有權。(註：Infra as code, configuration as code)
DevOps：接受失效，視失效為開發週期中的一個元素
SRE： 對於新的版本，建立一套可以量化的指標去衡量"意外"和"失效"
DevOps： 逐漸改變
SRE：鼓勵團隊透過降低排除故障的成本來達成速交付的目的 (就是不需要一次做到最好，而是逐漸改變)
DevOps：善用工具和自動化
SRE：鼓勵團隊把自己今年的工作自動化，最小化”工人智慧”要做的事，把精力放在中長期的系統改善。
DevOps：任何事都是可以被量測的
SRE：相信維運是軟體工程的範籌，規範關於可用性，運行時間(uptime)，停機時間(outages)，哪些是苦工等量測值。
如果你已經認同 DevOps 是一個 "介面(interface)"，那麼以程式語言的角度來說就是：
class SRE implements DevOps
雖然實際上兩者之間仍有需多獨立的原則，SRE 並非完全 1:1 實作了 DevOps 的所有的概念，但最終他們兩個的結論是相同的，也和程式語言相同，類別在繼承介面之後，可以做更多的延伸，也可以實作更多不同的介面，SRE 包含了更多細節是 DevOps 原本所沒有定義的。
在軟體開發和維運的領域中，DevOps 和 SRE 並非互相競爭誰才是業界標準，相反地，兩者都是為了減少組職之間的隔閡與更快更好的軟體所設計出來的方法，如果你想看更多細節的話，How SRE relates to DevOps (Betsy Beyer, Niall Richard Murphy, Liz Fong-Jones) 這本書值得一看。
2. SLIs, SLOs, and SLAs
SRE 的原則之一是針對不同的職務，給出不同的量測值。對於工程師，PM，和客戶來說，整個系統的可用程度是多少，以及該如何測量，都有不同的呈現方式。
如果無法衡量一個系統的運行時間與可用程度的話，是非常難以維運已經上線的系統，常常會造成維運團隊持續處在一個救火隊的狀態，而最終找到問題的根源時，可能會是開發團隊寫的 code 出了問題。
如果無法定出運行時間與可用程度的量測方法的話，開發團隊往往不會將「穩定度」視為一個潛在的問題，這個問題已經困擾了 Google 好多年，這也是為什麼要發展出 SRE 原則的動機之一。
SRE 確保每一個人都知道怎麼去衡量可靠度以及當服務失效時該做什麼事。這會細到當問題發生時，從 VP 或是 CxO，至最組織內部的每一個相關員工，都有做己該做的事。每一個「人」，該做什麼「事」都被規範清楚，SRE 會和所有的相關人員溝通，去決定出 Service Level Indicators(SLIs) 與 Service Level Objectives (SLOs)。
SLIs 定義了和系統「回應時間」相關的指標，例如回應時間，每秒的吞吐量，請求量，等等，常常會將這個指標轉化為比率或平均值。
SLOs 則是和相關人員討論後，得出的一個時間區間，期望 SLIs 所能維持一定水準的數字，例如「每個月 SLIs 要有如何的水準」，比較偏內部的指標。
該影片也討論到了 Service Level Agreements (SLAs)，即使這不是 SRE 每天所關心的數字。作為一個線上服務的提供者，SLA 是對客戶的承諾，確保服務持續運行的百分比，通常是和客戶「談」出來的，每年(或每月)的停機時間不得低於幾分鐘。
SLI, SLO, SLA 的概念和 DevOps 所提的「任何事都可以被量測」非常相似，這也就是為什麼會說 class SRE implements DevOps 的原因之一了。
3. 風險和犯錯預算
對於風險，我們會用犯錯預算來評估，犯錯預算是一個量化的值，用來描述服務每天(或每月)可以失效的時間，若服務的 SLAs 是99.9%，那麼開發團隊就等於有0.1％的犯錯預算通可以用。這個值是一個和 Product Owner 和開發團隊談過之後取得平衡的值，以下的影片也講到了為什麼 0 犯錯預算並不是一個適合的值。
致力於將一個系統的可用程度維持在 100% 是一件會累死你又無意義的事情，不切實際的目標會限制了開發團隊推出新功能到使用者手上速度，而且使用者多半也不會注意到這件事(例如可靠度是 99.999999%)，因為他們的 ISP 業者，3G/4G 網路，或是家裡的 WiFi 可能都小於這個數字。致力維持一個 100% 不間斷的服務會嚴重限制開發團隊將新功能交付出去的時間。為了要達成這個嚴酷的限制，開發人員往往會選擇不要修 bug，不要增加功能，不要改進系統，反之，應該要保留一些彈性讓開發團隊可以自由發揮。
SRE 的原則之一就是計算出可以容忍的「犯錯預算」，一旦這個預算耗盡，才應該開始將重點放在可靠性的改善而非持續開發新功能。
如第二個影片提到的，這個文化能讓管理階層買單是最重要的事，因為 SLIs 是大家一起訂出來的，如果不照遊戲規則走的話，SRE 又會淪為持續為了讓系統維持一定的穩定度了而一直做苦力的事，但是沒人知道(因為沒有訂標準)，最終這個服務一定會失敗。風險和犯錯預算會將犯錯視為正常的事，而改善的方式之一是讓新功能持續且小規模的發佈，這也和 DevOps 的原則相符合。
4. 瑣事和瑣事預算
另一個 SRE 的原則是瑣事的控管，如何減少瑣事？何謂瑣事？
維運中需要手動性操作的、重覆的，可以被自動化的
或是一次性，没有持久價值的工作，都是瑣事。
然而瑣事並不是「我不想做的事」，舉例來說，公司會有許多經常性的事務，一再的發生，例如開會，溝通，回 email，這些都不是瑣事。
反之，像是每天手動登入某台機器，取得某個檔案後做後續的處理，然後做成報告寄出來，這種就是瑣事，因為他是手動，重覆，可以被自動化的。
SRE 的原則是嘗試使用軟體工程的方法消除這些事情，當 SRE 發現事情可以被自動化後，便會著手執行自動化流程的開發，避免之後再做一樣的事情，雖然使瑣事最小化很重要，但實際上，這是不可能完全消除的，Google 致力於將 SRE 的日常瑣事縮小到 50% 以下，使得 SRE 成員可以將時間發費在更有意義的事情上，每季的回顧也都會檢視成果。
然而瑣事也並非完全是壞事，對於新進成員來說，先參與這事例行事務有助於瞭解這個服務該做些什麼事情，這是相對低風險與低壓力的，但是長遠來看，任何一個工程師都不該一直在做瑣事。
瑣事管理也和 DevOps 的原則 — 任何事都是可被測量與減少組織之間的穀倉效應相符。
5. 客戶可靠性工程 (Customer Reliability Engineering, CRE)
個人覺得這個主題對目前而言稍微走遠了，就不逐句翻譯。
大意如何將 SRE 的概念傳達出去，讓 GCP 的客戶知道該怎麼正確的使用 GCP 的各項服務以及推廣 SRE 的風氣。
個人後記
其實目前敝社漸漸轉型中，的確處在一個從傳統開發與維運轉互相獨立，到目前漸漸實做 DevOps 文化的路上，在支援了 SRE 部門4個月後，參與了很多現實面會碰到的挑戰，也和大家一起制定自動化流程與改善目前現有的瑣事，也漸漸朝 DevOps 的文化前進中，希望讓大家可以知道：
SRE 是軟體工程，不該只是維運人員或是系統管理員。
DevOps 並不是一個職稱，SRE 才是，就像你不會到市場菜攤跟老闆說我要買 "青菜"，而且會說要買高麗菜還是小白菜吧！
不過理想總是完美的，還是要面對現實，我們的公司不叫 Google，大部份的人也進不去 Google，Google 的 SRE 可能比大多數公司的軟體開發工程師還要會寫 code，比網路工程師還要懂網路，比維運工程師還要懂維運，在我們週圍的環境所開的 SRE 職缺，其實很多都不是想象中的這樣美好，瑣事/手動的事可能還是佔大多數，部門間還是存在隔閡，不會寫 code 的 SRE 可能也很多，維運還是佔日常工作的多數等現況。
傳統維運人員或 IT 網管人員若想往 SRE 發展的話，也必需改變一下思維，跳脫舒適圈，在這個什麼都 as code，什麼都 as a service 的年代，不寫 code 就等著等淘汰了。
改變是緩慢而且需要慢慢培養的，就讓我們…咦…P0 事件發生了！先這樣啦！
延伸閱讀：
