DevOps 是什麼？ Google 實做DevOps 的SRE 方法介紹

2003年成立SRE Team (Site Reliability Engineering) ，組成如下：. 50%~60%純軟體工程師。

40%~50%接近軟體工程師，兼有SRE 技能(系統和網路專家) ... SkiptocontentPostauthor:AaronLeePostpublished:2021-02-04Postcategory:DevOpsPostcomments:0Comments文章段落定義：DevOps是什麼？為什麼要DevOps？什麼時候要導入DevOps？如何導入DevOps？SRE導入方法DevOps這個概念已行之有年，但在業界的實施程度落差很大，在台灣走在前面的公司，可能已經玩DevOps玩超深，有些還不知道什麼是DevOps，只知道這是Development和Opeartion部門間的戰爭合作。

定義：DevOps是什麼？根據維基百科「上一版」的定義是這樣子寫的：DevOps是過程、方法和系統的統稱，促進Development、Opeartion和QA部門間的溝通、協作與整合。

有沒有很籠統的感覺？XD看一下圖好了DevOps示意圖來源：維基百科這圖到底是什麼意思呢？難道我們沒有DevOps就沒有溝通、沒有協作、沒有整合嗎？這個我也會畫啊！我再畫一圈然後寫HR，然後說導入DevOps可以更有效使用人力，再畫一圈Finance，然後說導入DevOps可以節省人力成本，乾脆再畫一圈，然後直接寫Money好了，代表導入DevOps可以發大財，你開心，我開心，大家都開心！感覺好像都沒錯耶！？其實它這樣畫是有原因的，而且非常具體的原因。

我們先來看一下這張圖：影響開發速度的系統圖示來源：ruddyblog為什麼要DevOps？隨著公司持續成長，系統的規模、功能、複雜度、事件和更新次數變多，有很多額外的工作，必須要手動處理回應各項事件。

而公司通常在應用程式的發展，通常分開發和維運，有些會再有測試部門，而開發和維運部門由於不同的背景、技能、目標和激勵措施不同，容易產生衝突。

開發：「我做了一個超炫的功能，什麼時候可以上線？」維運：「不要停機、不要更新、不要掛掉。

」如果今天突然程式發生重大錯誤事件，就會變這樣：開發：「都是你沒上新版，我在新版已經解決這個Bug」維運：「你還敢說，上個月那一版，一部署網站就全部掛掉，害我去開檢討會議罰站一整天」開發：「可是……在我電腦上是好的！」……(經典名句啊XD)這種情況不會只發生在Google，也不只發生在開發和維運兩個部門之間，在世界上各個角落都會發生，也就是所謂的「穀倉效應」。

(還有人專門寫成一本書)書：穀倉效應簡單說就是各部門之間變成孤島，發生衝突之後，部門之間互不信任，使用各種措施阻礙對方：維運：根據以前發生過的錯誤，準備一連串的Checklist。

開發：強調這不是改版，是微調，可以直接上。

部門間從合作變成互相角力，拖慢了整個系統開發流程。

同樣的事情發生在Google，而Google又怎麼解決這樣的問題呢？2003年成立SRETeam(SiteReliabilityEngineering)，組成如下：50%~60%純軟體工程師。

40%~50%接近軟體工程師，兼有SRE技能(系統和網路專家)。

SRE軟體工程師必須要維運產品建一個系統來執行「維運」的人工操作Google規定，SRE只能花50%的時間解ticket、oncall、人工操作。

超過50%的部分，指派給開發團隊負責。

所以開發團隊則是要：開發產品如果SRE太忙，要幫忙分擔工作所以SRE除了做維運，也要寫「維運」的程式，而開發團隊除了寫「產品」的程式，也要做維運。

==>>產生交叉培訓。

也帶來了其他好處：系統變大變複雜，卻沒有僱用更多人。

軟體更新速度保持不變。

軟體不用停機就可以直接進行修改。

同時來看看其他的例子，LineEngineering的部落格寫得很好：IBM和微軟「2家公司發現當他們還在以每季度在更新軟件時，Google卻是每天都能更版甚至使用A/BTesting的方法在快速反應使用者的回饋。

結果是MSOffice轉型後且上了雲端似乎帶來更好的結果，但IBM卻退出了企業協作軟件的市場。

」以及Nokia的例子：「2010年當其董事會主席RistoSiilasmaa視察公司時發現，Symbian作業系統建製一次需要48小時，對於當時的他猶如當頭棒喝，而內部雖然一直有淘汰Symbian的建議，卻一直沒被管理層所採納。

」這告訴了我們，速度真的是非常重要的因素，即使別人很晚才進入巿場，只要他開發速度比你快得多，你總有一天會被他超車。

什麼時候要導入DevOps？那什麼時候要導入DevOps呢？只要有以下症狀，都可以考慮看看(引用自KK-Stream你在找的是SRE還是DevOps)：開發部門無法在開發早期偵測軟體缺陷無法確定問題出現在哪一個部門人為錯誤經常發生只要部署出去，Dev就認為工作完成問題發生，相互指責如何導入DevOps？SRE導入方法那要如何導入DevOps呢？五大原則如下：接受失效(Failure)，視失效為開發週期中的一個元素減少組織之間的穀倉效應持續改善善用工具和自動化任何事都是可以被量測的DevOps畢竟是大原則，而Google在這部分使用SRE做為具體的實做方式，分述如下：1.失效是一種常態 –錯誤預算ErrorBudget預算指的不是錢，而是時間(雖然時間可以折算成錢)。

這裡要先提一下SLI(ServiceLevelIndicators)、SLO(ServiceLevelObjects)和SLA(ServiceLevelAgreements)的簡單定義：SLI：和系統效能有關的指標，例如Latency或Throughput等等。

SLO：表示我們希望SLI有多少，但這個不會公佈出來，是公司內部自訂的。

SLA：是對客戶保證，每年或每月的停機時間不能超過多少時間，如果是公開的應用程式，是會宣告出來的，如果是開發給某客戶使用，就是和客戶談出來的，會寫在合約上。

如果停機超過SLA所訂的時間可能是要賠錢的！Google在SREBook有直接換算在不同的SLA和單位時間底下，最長的中斷時間各為多少：SLA換算表來源:SREBookAvailabilityTable但這不是給你拿來跟客戶說：「你知道嗎？我們家的系統最多可以斷三天喔！」這樣你可能會被踢出去。

你可能會問，為什麼不做到100%呢？為什麼SLA不做到100%呢？就像我們去考試一樣，從90分進步到99分比較容易，還是從99分進步到100分比較容易？Google的解釋是這樣的，為了達到SLA100%，中間有太多不可抗力因素，例如從你的應用程式傳訊息要先到電信商的基地台，中間可能已經是99.9%的SLA，再從基地台傳到你的手機可能又是99.9的SLA，這裡都還沒算到你開發的應用程式可用性，SLA就已經是98.9%了，那你要怎麼做到100%？先買下電信商，再買下那支手機的製造商，然後請超厲害的工程師把APP寫到100分？然後呢？你做到SLA100%了，客戶感受到你0.1%的進步嗎？客戶願意為了你0.1%的進步而多付100萬嗎？我們回過頭來講錯誤預算，直白一點的意思是「在沒有超過約定好的中斷時間之下，我們有多少時間可以拿來做一些創新的嘗試」。

所以錯誤預算可以：培養不究責的文化Blamelessness=>以利事後調查允許犯錯=>鼓勵創新用來承擔Launch的風險=>做到快速Launch 這看起來有沒有像我們學生時代，老師對我們的教誨，不要怕犯錯，TryandError？現在呢？多做多錯，少做少錯，不做不錯。

歡迎來到大人的世界。

大人講的都是對的嗎？官越大，越正確，你不知道嗎？(怨念好深……)是的，現在是團隊合作的社會，為了不造成別人麻煩，或怕被懲罰，或是怕犯錯變成別人攻擊的對象，我們總是避免犯錯。

為了避免犯錯，我們就不再創新了。

槍打出頭鳥啊～DevOps第一條原則就把我們的臉打得好腫。

貴公司是究責還是不究責呢？2.減少穀倉效應–Infrastructureasacode就是盡可能讓環境，用統一規管的格式或設定檔(例如yaml檔)來部署，而不是人為去設定網路和伺服器等：讓開發/測試/生產環境長得幾乎一模一樣，提早發現錯誤可以被版本控制工具所管理(如git)，這代表任何的改變都有跡可尋減少人工所產生的錯誤達成自動化減少穀倉效應–Infrastructureasacode這樣如果一套程式在開發環境run不起來，在測試或生產環境一樣run不起來，要發現錯誤容易的多，大家一起來看yaml檔就好了。

而且誰做錯全部的人都知道，不用推責任給別人，也不用故意放大檢視他人，大家心裡知道就好，犯錯的人也會默默檢討，毋需指責。

3.持續改善–使用CI/CD什麼意思？誰不會持續改善，每個人都會不是嗎？聽起來好像廢話。

這裡講的持續可以用「漸進」來解釋，以前系統要改進，可能是收集完使用者回饋的100項缺點，一口氣全部改完再給使用者，就跟瀑布模式的系統開發流程一樣，常常要交付給使用者時才發現跟原始的需求不一樣。

所以這裡強調的是，只要修正一個點，就交付給用戶測試看看，測試OK再改下一個。

這裡用到的具體做法就是CI/CD，注意CD有兩種：持續整合ContinuousIntegration持續驗證開發結果，小部分小部分地儘早確認，期望產出符合需求，或依據產出進行快速修正。

建置(build)測試(test) 程式碼分析(sourcecodeanalysis)持續交付ContinuousDelivery 發行到測試環境，確保軟體持續保持在隨時可以釋出的狀況。

持續部署ContinuousDeployment自動部署到生產環境。

CD？持續交付還是持續部署？要做到以上哪一種，就要看公司內部的流程和分工的情況而定。

4.自動化–減少手工(Toil，又稱工人智慧)什麼是手工呢？手工的特徵如下：手動執行script、開關機、上新版程式對每個新客戶進行的重複性工作沒有永久的價值(長期的改善)因為這些工作是不斷重複的，因為重複就會感到單調，因為單調做起來就覺得很沒勁，甚至厭煩，久了甚至會忽視，不專心地做這些事情，這樣出錯的機率反而就會提高。

我曾經在以前的某個公司，也做過某件明明對公司就非常重要，卻沒有人重視也沒有人關心的「手工」，剛好有一次工作太忙，又覺得自己做很多次自以為熟悉，就忽略了一兩個檢查步驟，然後好死不死就剛好系統有問題沒檢查到，造成最後一條龍的流程全部受到影響，並且要全部重來，最後在檢討會議上給別人盯，這就是究責的文化啊～別讓昨天在你傷口狂忘的撒鹽，一碰就痛，一想就悲。

(明明就我自己撒的)所以自動化說有多重要就有多重要，並且搭配漸進式部署(ProgressiveRollout)一次發布一點點變動，並且針對少量使用者發布，每次的變動都可以密切地監控效能是否有什麼影響。

快速準確地發現問題。

出現問題時安全地回滾更改。

 只要錯誤減少，產品交付就會加快。

而自動化的工具很多，非常多，還有公司直接弄成元素周期表自動化–DevOps工具元素週期表https://devops.phodal.com/home之後我們會再分享在GCP實做的相關工具。

5.任何事都是可以被量測的這一點是跟CI/CD最大的差異之處，它強調的重點如下：監控是追蹤系統健康和可用性最好的方法如果必須要有人閱讀電子郵件,並判斷是否需要採取行動的系統,從根本上是有缺陷的。

只有一定要採取行動的時候，系統才發出通知。

透過監控達成資訊透明資料來源：https://www2.slideshare.net/warfan/devops-68063058跟之前「減少穀倉效應」的概念類似，就是要讓所有事情都透明化，所以才需要「監控」這個關鍵步驟，這樣發生任何事，都能快速找到原因，而不是浪費時間在那邊跟別人吵架。

其實，以上提到的實施方法，就是Google提出的SRE(SiteReliabilityEngineering)概念：DevOps原則和SRE方法(引用自KK-Stream你在找的是SRE還是DevOps)各位有空真的可以去讀一下Google的SREBook，非常適合在睡前看持續成長的你。

或是參考《維運管理與SRE的關係》這篇文章，快速了解維運管理和SRE之間的關係最後Google還說，方法歸方法，「人與文化」還是推動DevOps最關鍵的因素，我們非常需要高階主管的支持，DevOps才動得起來。

Google為了推動DevOps文化，曾經在公司內辦了大大小小的說明會，就是為了打造一個具有「心理安全」(PsychologicalSafety)的環境，更何況是我們，有更多需要「人與文化」改善的地方啊！最後的最後，如果針對DevOps和SRE還有相關疑問，歡迎留言詢問或直接聯繫我們。

需要DevOps導入協助的話也可以參考我們的解決方案說明喔！▋延伸閱讀：・【K8s是什麼】比較Docker容器、K8s和GKE的架構與優勢・維運管理與SRE的關係・[GoogleK8s教學]第一次使用GoogleKubernetesEngine就上手・使用CloudRun部署一個APIServer・[DevOps實作]使用GoogleCloud全代管服務達成CI/CDTags:CI/CD,SREReadmorearticlesPreviousPost如何讓CloudLogging在gcloud指令下也能執行Tail?NextPost如何安裝CloudMonitoringAgent在GoogleComputeEngine上？AaronLee超過7年的GoogleCloud經驗，服務過上百家GoogleWorkspace與GCP客戶，擔任多次研討會主講人與教育訓練講師，提供架構諮詢與技術支援，幫助各大企業上雲。

YouMightAlsoLike淺談DevOpsSecurity2020-02-06[DevOps實作]使用GoogleCloud全代管服務達成CI/CD2021-04-15[DevOps實作]GitLab部署asp.NetCore到KubernetesEngine達成CI/CD2021-03-08發佈留言取消回覆CommentEnteryournameorusernametocommentEnteryouremailaddresstocommentEnteryourwebsiteURL(optional)CloudAce—免費研討會想快速瞭解GCP嗎？現在就報名研討會免費了解吧！每月固定舉辦，由專業講師親自講解，特設Q&A環節，現場回答您所有疑問。

每場研討會名額有限，快來一同進修吧！掌握最新研討會資訊近期文章GKEAutopilot教學―輕鬆管理K8s，加快軟體開發流程立即實踐大數據分析應用！步驟、工具、目標建議一次了解BigQuery教學―操作界面與分析、視覺化步驟完整圖解CDN是什麼？GoogleCloudCDN用途、優勢完整介紹【K8s是什麼】比較Docker容器、K8s和GKE的架構與優勢文章分類GCP基本資訊服務介紹費用計算其他雲端基礎架構（Infrastructure）虛擬機器（VM）主機資料備份雲端搬遷網路與網站CDN負載平衡（Loadbalancing）應用程式現代化DevOpsServerless資安與帳號管理大數據分析資料庫AI與機器學習遠距工作工具GoogleWorkspaceGSuite熱門標籤ComputeEngineBigQueryGoogleKubernetesEngineCloudLoadBalancingAccountmanagementCloudSQLVPCNetworkAnthosCloudIdentityInstanceGroupActiveDirectoryCloudIAPCI/CDDataStudioCloudStorage免費報名線上技術研討會聯繫我們