[好文翻譯] 你在找的是SRE 還是DevOps？ - Medium

Site Reliability Engineering (SRE)和DevOps 是目前相當熱門的開發與維運文化，有著很高的相似程度。

然而，早期有些人會把SRE 視為和DevOps 不同的 ... GetunlimitedaccessOpeninappHomeNotificationsListsStoriesWritePublishedinKKStream[好文翻譯]你在找的是SRE還是DevOps？Source:https://www.youtube.com/watch?v=uTEL8Ff1Zvk&feature=youtu.be敝社這半年來開始大舉徵才，其中不乏DevOps和SRE的職缺，然而HR(或其他部門的同事)對於兩者的相異之處並不瞭解，甚至認為SRE和傳統維運單位一樣，只是換個名字，從管機房到管雲端而已，究竟兩者到底有什麼差別呢？這對前來的面試的應徵者會有負面的影響，好像連我們自己要找什麼樣的人都不清楚似的。

於是，花了點時間跟HR介紹兩者的差異，也在支援了SRE團隊四個月後留下這篇翻譯文加一點點心得。

請先記得…SREisaDevOps(香蕉是一種水果)DevOpsisNOTaSRE(水果不是香蕉)DevOps並不是一個"工作職稱"，SRE才是《本文已取得原作者之一SethVargo同意翻譯刊登》原文網址：https://cloudplatform.googleblog.com/2018/05/SRE-vs-DevOps-competing-standards-or-close-friends.html?m=1正文開始SiteReliabilityEngineering(SRE)和DevOps是目前相當熱門的開發與維運文化，有著很高的相似程度。

然而，早期有些人會把SRE視為和DevOps不同的實踐方式，認為兩者不一樣，必需選擇其一來執行，但是現在大家更傾向兩者其實其實很相似。

究竟SRE和DevOps有什麼相同點呢？在年初，Google的工程師(LizFong-Jones與SethVargo)準備了一系列的影片去解答這些問題以及嘗試跳出來去減少社群間的意見分歧，本篇文章總結了影片中所涵蓋到的主題，以及如何實際去建置一個更加可靠的系統。

1.SRE和DevOps的差異在開始之前，先瞭解一下SRE和DevOps有什麼相同之處？又有什麼相異之處？Source:https://www.youtube.com/watch?v=uTEL8Ff1Zvk&feature=youtu.beDevOps文化的興起是因為在早期(約十年前)，有許多開發者對於自己的程式是怎麼跑在真實世界，其實所知有限。

開發者要做的事情就是將程式打包好，然後扔給維運部門後，自己的工作週期就結束了，而維運部門會負責將程式安裝與部署到所有生產環境的機器上，同時也要想盡各種辨法與善用各種工具，確保這些程式持續正常地執行，即使維運部門完全不瞭解這些程式的實作細節。

這樣的工作模式很容易造成兩個部門之間的對立，各自的部門都有自己的目標，而各自的目標和公司商業需求可能會不一致。

DevOps的出現是為了帶來一種新的軟體開發文化，用以降低開發與維運之間的鴻溝。

然而，DevOps的本質並不是教導大家怎麼做才會成功，而是訂定一些基本原則讓大家各自發揮，以程式設計的術語來說，DevOps比較像是一個抽象類別(abstractclass)，或是介面(interface)，定義了這種文化該有什麼樣的行為，實作則是靠各個部門成員一起決定，只要符合這個「介面」，就可以說是DevOps文化的實踐。

SRE一詞由Google提出，是Google在這十多年間為了解決內部日漸龐大的系統而制定出一連串的規範和實作，和DevOps不同的是，它實作了DevOps的所定義的抽象方法，而且規範了更多關於如何用軟體工程的方法與從維運的角度出發，以達成讓系統穩定的目的。

簡單來說，SRE實作了DevOps這個介面(interface)，以下列出五點DevOps定義的介面以及SRE如何實作：DevOps：減少組織之間的穀倉效應SRE：在整個開發週期中，和開發團隊使用相同的工具以及一起分享與所有權。

(註：Infraascode,configurationascode)DevOps：接受失效，視失效為開發週期中的一個元素SRE：對於新的版本，建立一套可以量化的指標去衡量"意外"和"失效"DevOps：逐漸改變SRE：鼓勵團隊透過降低排除故障的成本來達成速交付的目的(就是不需要一次做到最好，而是逐漸改變)DevOps：善用工具和自動化SRE：鼓勵團隊把自己今年的工作自動化，最小化”工人智慧”要做的事，把精力放在中長期的系統改善。

DevOps：任何事都是可以被量測的SRE：相信維運是軟體工程的範籌，規範關於可用性，運行時間(uptime)，停機時間(outages)，哪些是苦工等量測值。

如果你已經認同DevOps是一個"介面(interface)"，那麼以程式語言的角度來說就是：classSREimplementsDevOps雖然實際上兩者之間仍有需多獨立的原則，SRE並非完全1:1實作了DevOps的所有的概念，但最終他們兩個的結論是相同的，也和程式語言相同，類別在繼承介面之後，可以做更多的延伸，也可以實作更多不同的介面，SRE包含了更多細節是DevOps原本所沒有定義的。

在軟體開發和維運的領域中，DevOps和SRE並非互相競爭誰才是業界標準，相反地，兩者都是為了減少組職之間的隔閡與更快更好的軟體所設計出來的方法，如果你想看更多細節的話，HowSRErelatestoDevOps(BetsyBeyer,NiallRichardMurphy,LizFong-Jones)這本書值得一看。

2.SLIs,SLOs,andSLAsSRE的原則之一是針對不同的職務，給出不同的量測值。

對於工程師，PM，和客戶來說，整個系統的可用程度是多少，以及該如何測量，都有不同的呈現方式。

Source:https://youtu.be/tEylFyxbDLE如果無法衡量一個系統的運行時間與可用程度的話，是非常難以維運已經上線的系統，常常會造成維運團隊持續處在一個救火隊的狀態，而最終找到問題的根源時，可能會是開發團隊寫的code出了問題。

如果無法定出運行時間與可用程度的量測方法的話，開發團隊往往不會將「穩定度」視為一個潛在的問題，這個問題已經困擾了Google好多年，這也是為什麼要發展出SRE原則的動機之一。

SRE確保每一個人都知道怎麼去衡量可靠度以及當服務失效時該做什麼事。

這會細到當問題發生時，從VP或是CxO，至最組織內部的每一個相關員工，都有做己該做的事。

每一個「人」，該做什麼「事」都被規範清楚，SRE會和所有的相關人員溝通，去決定出ServiceLevelIndicators(SLIs)與ServiceLevelObjectives(SLOs)。

SLIs定義了和系統「回應時間」相關的指標，例如回應時間，每秒的吞吐量，請求量，等等，常常會將這個指標轉化為比率或平均值。

SLOs則是和相關人員討論後，得出的一個時間區間，期望SLIs所能維持一定水準的數字，例如「每個月SLIs要有如何的水準」，比較偏內部的指標。

該影片也討論到了ServiceLevelAgreements(SLAs)，即使這不是SRE每天所關心的數字。

作為一個線上服務的提供者，SLA是對客戶的承諾，確保服務持續運行的百分比，通常是和客戶「談」出來的，每年(或每月)的停機時間不得低於幾分鐘。

SLI,SLO,SLA的概念和DevOps所提的「任何事都可以被量測」非常相似，這也就是為什麼會說classSREimplementsDevOps的原因之一了。

3.風險和犯錯預算對於風險，我們會用犯錯預算來評估，犯錯預算是一個量化的值，用來描述服務每天(或每月)可以失效的時間，若服務的SLAs是99.9%，那麼開發團隊就等於有0.1％的犯錯預算通可以用。

這個值是一個和ProductOwner和開發團隊談過之後取得平衡的值，以下的影片也講到了為什麼0犯錯預算並不是一個適合的值。

Source:https://youtu.be/y2ILKr8kCJU致力於將一個系統的可用程度維持在100%是一件會累死你又無意義的事情，不切實際的目標會限制了開發團隊推出新功能到使用者手上速度，而且使用者多半也不會注意到這件事(例如可靠度是99.999999%)，因為他們的ISP業者，3G/4G網路，或是家裡的WiFi可能都小於這個數字。

致力維持一個100%不間斷的服務會嚴重限制開發團隊將新功能交付出去的時間。

為了要達成這個嚴酷的限制，開發人員往往會選擇不要修bug，不要增加功能，不要改進系統，反之，應該要保留一些彈性讓開發團隊可以自由發揮。

SRE的原則之一就是計算出可以容忍的「犯錯預算」，一旦這個預算耗盡，才應該開始將重點放在可靠性的改善而非持續開發新功能。

如第二個影片提到的，這個文化能讓管理階層買單是最重要的事，因為SLIs是大家一起訂出來的，如果不照遊戲規則走的話，SRE又會淪為持續為了讓系統維持一定的穩定度了而一直做苦力的事，但是沒人知道(因為沒有訂標準)，最終這個服務一定會失敗。

風險和犯錯預算會將犯錯視為正常的事，而改善的方式之一是讓新功能持續且小規模的發佈，這也和DevOps的原則相符合。

4.瑣事和瑣事預算另一個SRE的原則是瑣事的控管，如何減少瑣事？何謂瑣事？維運中需要手動性操作的、重覆的，可以被自動化的或是一次性，没有持久價值的工作，都是瑣事。

Source:https://youtu.be/IvQ-15-yE_c然而瑣事並不是「我不想做的事」，舉例來說，公司會有許多經常性的事務，一再的發生，例如開會，溝通，回email，這些都不是瑣事。

反之，像是每天手動登入某台機器，取得某個檔案後做後續的處理，然後做成報告寄出來，這種就是瑣事，因為他是手動，重覆，可以被自動化的。

SRE的原則是嘗試使用軟體工程的方法消除這些事情，當SRE發現事情可以被自動化後，便會著手執行自動化流程的開發，避免之後再做一樣的事情，雖然使瑣事最小化很重要，但實際上，這是不可能完全消除的，Google致力於將SRE的日常瑣事縮小到50%以下，使得SRE成員可以將時間發費在更有意義的事情上，每季的回顧也都會檢視成果。

然而瑣事也並非完全是壞事，對於新進成員來說，先參與這事例行事務有助於瞭解這個服務該做些什麼事情，這是相對低風險與低壓力的，但是長遠來看，任何一個工程師都不該一直在做瑣事。

瑣事管理也和DevOps的原則—任何事都是可被測量與減少組織之間的穀倉效應相符。

5.客戶可靠性工程(CustomerReliabilityEngineering,CRE)個人覺得這個主題對目前而言稍微走遠了，就不逐句翻譯。

大意如何將SRE的概念傳達出去，讓GCP的客戶知道該怎麼正確的使用GCP的各項服務以及推廣SRE的風氣。

個人後記其實目前敝社漸漸轉型中，的確處在一個從傳統開發與維運轉互相獨立，到目前漸漸實做DevOps文化的路上，在支援了SRE部門4個月後，參與了很多現實面會碰到的挑戰，也和大家一起制定自動化流程與改善目前現有的瑣事，也漸漸朝DevOps的文化前進中，希望讓大家可以知道：SRE是軟體工程，不該只是維運人員或是系統管理員。

DevOps並不是一個職稱，SRE才是，就像你不會到市場菜攤跟老闆說我要買"青菜"，而且會說要買高麗菜還是小白菜吧！不過理想總是完美的，還是要面對現實，我們的公司不叫Google，大部份的人也進不去Google，Google的SRE可能比大多數公司的軟體開發工程師還要會寫code，比網路工程師還要懂網路，比維運工程師還要懂維運，在我們週圍的環境所開的SRE職缺，其實很多都不是想象中的這樣美好，瑣事/手動的事可能還是佔大多數，部門間還是存在隔閡，不會寫code的SRE可能也很多，維運還是佔日常工作的多數等現況。

傳統維運人員或IT網管人員若想往SRE發展的話，也必需改變一下思維，跳脫舒適圈，在這個什麼都ascode，什麼都asaservice的年代，不寫code就等著等淘汰了。

改變是緩慢而且需要慢慢培養的，就讓我們…咦…P0事件發生了！先這樣啦！延伸閱讀：Google儲存SRE團隊負責人第一手經驗大公開https://rickhw.github.io/categories/DevOps/SRE/一篇文章彻底读懂DevOps与SRE来龙去脉(译)?--4MorefromKKStreamAllaboutwhatwehavedoneinKKStreamReadmorefromKKStreamAboutHelpTermsPrivacyGettheMediumappGetstartedNeilWei444FollowersBackend/DevOps@UbiquitiInc.FollowMorefromMediumRaghobaGautamBorkarKafkaSecurityBhanuPrathapReddyHowdidwesetupthestagingenvironmentinMediBuddy ?ShivamAgarwalinEngineering@ChargebeeSavecostbyrunningGitHubActionsonSpotInstancesinsideanEKSClusterGouravSinghRajputPlaywithhelm-part2HelpStatusWritersBlogCareersPrivacyTermsAboutKnowable