SRE 是什麼？ 維運管理與SRE 的關係 - Cloud Ace 技術部落格

SRE 是什麼呢？SRE 全稱Site Reliability Engineering，根據提出SRE 概念的Benjamin Treynor Sloss 的說法，SRE 詢問一個軟體工程師如何設計一套維運 ... SkiptocontentPostauthor:AaronLeePostpublished:2020-09-03Postcategory:DevOpsPostcomments:0Comments文章段落Operations ManagementDevvs.OpsproblemTrueReliabilityErrorbudget SREmissions 總結這篇文章旨在探討何謂維運管理以及如何進行維運管理，並透過SRE的觀點去強化維運管理的方式。

Operations Management談到維運管理，首先我們需要從WWH–WhatWhyHow的角度知道來探討。

維運的WWH-WhatWhyHow1.What–了解什麼是維運管理？從Business的角度來看維運管理的話，通常指的會是企業的經營或公司的策略，但從IT管理的角度，我們要談的是針對ITService或ITSystem系統方面的管理。

2.Why–為什麼談維運管理呢？想像一下我們有一個很厲害的線上服務或是IT產品，結果因為某些原因導致系統不能用或是不能正常使用，結論是這仍然是一個沒用處或是沒法提供服務的產品。

所以一個死掉的服務或是掛掉的系統是無用的，沒辦法做任何事情。

這也是為什麼維運管理相對來說是重要的。

3.How–那我們怎麼去做維運管理呢？難道是買了一套十萬or百萬的數台Servers，然後就放在那邊不理他？並假裝相信這套設備永遠不會壞掉嗎？其實各種系統都是一樣的，單單只是希望它不會壞掉放著不管，並不是一個好的策略。

SRE可能是一個解決的答案。

既然提到了SRE，到底什麼是SRE呢？SRE其實是Google早在十年前就提出並且應用的一個實現。

SRE全稱SiteReliabilityEngineering，根據Google當時提出SRE概念的BenjaminTreynorSloss(VicePresident,Engineering,Google)，他提到：“SREiswhathappenswhenyouaskasoftwareengineertodesignanoperationsfunction.“（中譯：SRE就是當你去問一個軟體工程師如何設計一套維運方法的表現。

）SiteReliabilityEngineering–HowGoogleRunsProductionSystems,BetsyBeyer,ChrisJones,JenniferPetoffandNiallRichardMurphy一般來說資訊單位在規劃維運團隊的時候，傳統上常見的公司或企業(特別是地端)，會將開發及維運分成兩組單位，開發人員多半是由軟體工程師組成的RDTeam，而維運人員多半是由所謂的系統工程師(SystemAdmin)組成的，這便是我們講的由系統管理員的方式去做為維運Team。

這些由系統工程師所組成的維運Team在維運的時候可能基於手冊式的方式，較多為手動的去執行一些相關的任務，例如說開關機、備份、清理資料…等。

而根據SiteReliabilityEngineering這本書所提，Google的做法，則是使用的是SRE(網站可靠性工程)的方式，透過由軟體工程師組合成的SREteam做維運上的設計和操作。

那麼，系統管理員(SystemAdmin)跟SRE網站可靠性工程師SiteReliabilityEngineer)相同嗎？其實有一點點不同。

系統管理員(SystemAdmin)跟 SRE網站可靠性工程師SiteReliabilityEngineer)相同嗎？開發、系統管理的這種結構，慢慢的已經演變出所謂DevOps的概念，也就是說將開發跟運維綁在一起的概念，如果說DevOps是一個原則，那麼SRE則是基於這個概念的實現，以程式的語言來表現就會類似像：classSREimpementsDevOps。

 當然DevOps這個議題已經被提出很久，他有一些基本大方向的原則：AcceptfailureasnormalReduceorganisationalsilosImplementgradualchangeLeveragetoolingandautomationMeasureeverything例如像是：  接受失敗是常態：SRE就是透過SLO或是檢討的方式來實現這個概念 人及文化方面 心理上的安全感 跟不責罵的文化 也是很重要的一環降低組織隔閡：SRE的實踐就是把ownership在維運跟productteam共同來分擔，人及文化上 包含了整體的視野,協作,以及溝通跟知識的分享等等漸進式更動：SRE的實踐就是降低錯誤的cost，或是說提出所謂canaries(alpha,beta版本這種模式)進而導入CI持續整合/CD持續部署 人及文化上則是透過設計思考啊，Prototyping雛形/原形化。

利用工具及自動化：SRE則是降低所謂的Toil勞務（一直重複做的事情）方面的自動化 人和文化上則是要去思考改變所帶來的阻力。

測量所有東西：SRE則是衡量出Toil勞務和可靠性 利用一些SLA的指標或數值來達成，人和文化上則是設定正確的目標，透明化，然後是基於數據所做的決定這所有的目標主要就是想要表達：要建立出一個良好文化去幫助DevOps以及SRE的實踐。

當然這會有難度，尤其是在大型的組織可能會有很多的因素，政治,商業考量….等等 所以這會需要整個公司的人來一起完成才有可能。

Devvs.Opsproblem我們知道，常見地端機房的淺規則就是：千萬不要去機房碰穩定在跑的機器，連重開機都是大忌。

不碰就沒事！但這其實就會造成開發團隊及維運團隊的方向或是動機不一致。

開發團隊：想要新功能，增加核心價值，修正bug，改進產品維運團隊：希望穩定就好，最好都不要改動及變化，希望這樣可以達到100%可用性。

所以很常見到的情況是這樣的：開發團隊開發出一個新功能  然後發布新功能到prodcution環境結果因為改動就出事了然後維運團隊就改了一些規定 要更嚴格更謹慎最後導致更長的QA跟更長的測試總Cost，相對來說是無形的增加的。

當你的Business是成線性成長的時候(當然我知道很多公司也有可能是指數下降..XD)，以往系統管理員所進行手動勞務的部分可能是根據手冊或是list模式去做事。

當你的服務增加，你需要做的事情也會將對增加，以比例來講，相對的突然/出包的事件也會增加，結果就是系統管理員的人數要增加，維運的成本也隨著服務增加。

指數成長vs預算是有限的情況下，又要最大化系統或服務核心價值的時候，該怎麼辦呢？TrueReliability這邊就會談到真正的可靠性，什麼是可靠性，可靠性就是可用性嗎？Business的核心價值是基於100%可用性而已嗎？可靠性包含很多因素： 　-可用性 　-系統維護的時間跟週期 　-最新的安全性應用 　-期望提供什麼樣的服務給客戶當我們把可靠性是設定為100%其實是一個錯誤的目標，最簡單的原因：因為不實際。

第一、無法分辨不同，例如你家ISP網路只有99%的SLO，結果你提供99.99%的SLO，但使用者早就無法上網了 根本無法發現到你的99.99%有什麼好處。

第二、多一個9你可能要考量到更多HA的節點，成本相對來說多一個9是非常昂貴的。

第三、系統的剛性：為了維持並保持好100%，你需要更長的Lifecycle（例如更長的QA時間，更長的更縝密的系統或功能的規劃）去發展新功能或修復新bug，導致沒辦法敏捷的調整及擴展。

一個理想的SLO，應該是要在創新跟穩定中間取得平衡，這個平衡有很大的觀點來自於客戶的體驗。

Errorbudget SRE提出的概念是ErrorBudget，所謂的ErrorBudget，其實就是你的SLO 扣掉之後剩下的就是你可以出錯的空間。

100%–“SLO”=errorbudget例如SLO是99.9%，100%-99.9%=0.1%就是所謂的errorbudget了。

這個Budget空間非常的有用，因為在你的SLO不變的前提下，這就是允許你做調整及修正的空間，這個容錯空間會是shared，在SREteam跟開發團隊之間的一個共享的容錯空間。

這就是SRE觀點內，蠻重要的一個關鍵，去影響你的創新跟穩定之間的平衡點在此。

Errorbudget包含品質:新功能修正bug2.如果達到這個容錯空間SRE，可以選擇降低Lifecycle的速度抑或SRE也可以決定停止整個lifecycle。

3.如果有太多勞務要維護或是太多的服務停擺，SRE可以回報BUG4.開發團隊需要寫出更高質量的code跟測試去改善維運性跟服務品質。

所以，Errorbudget主要的功用便是在於減少產品開發週期之間各階段的摩擦。

-Business要開發很快速的解決某個需求-開發想要很快速的開發出新功能-維運想要保持穩定性透過Errorbudget，我們可以將其應用在創新與穩定之間的平衡之上。

SREmissions SRE的任務包含了：Availability(可用性)Latency(延遲)Performance(效能)Efficiency(效率)Changemanagement(變更管理)Monitoring(監控)Incidentresponse(事故應變)Capacityplanning(容量規劃)SRE工作中有一項很重要的原則稱為：50%原則50%原則：意思是只能有50%的時間再處理ticket、on-call、手動要做的事情上，剩下的應該去研究如何自動化以及高效率的完成。

如果超過50%，則需要：增加SRE工程師人數降低產品開發週期50%原則的好處：-預防teammember太累-促使團隊成員去自動化效率化 降低重複的勞務工作 以軟體工程師的角度-更少的手動操作更穩定的prodcuion系統同時也可以讓SRE有更深的知識去寫出更穩定的code，透過檢閱和建議的方式讓開發團隊去寫出production-ready的code。

那麼我們如何達到可靠性呢？自動化–透過自動化來提高效率，並考慮導入CI/CD等流程建置自動化流程經常檢討–其用意為提高可用性進而去分析及檢討RootCause。

事前演練–事故發生時透過類似消防演練、防災演練的概念，達到預防勝於治療的功效。

總結SRE的觀點中，同時也應用了所謂的不責罵原則，不去責罵任何一個個體，而是應該由記錄所有的事故、文件化，並從錯誤中學習。

記得：接受失敗是常態。

不要去罵任何一個團隊成員，人都會犯錯，應該以Team或整體的角度去看待每一次錯誤跟失敗，失敗沒什麼，如何修正他、預防他才是關鍵。

所有的檢討都是內部的，宗旨都是在不幸的事件發上到你身上的時候，都將會是一個經驗的累積和應用。

Tags:SREReadmorearticlesPreviousPost在GCPLoadBalancer上設定logging以及monitoring功能–TCPLoadBalancerdashboard&Email告警設定教學NextPost使用GCPVM的5大常見錯誤–有一種叫忘記關機！AaronLee超過7年的GoogleCloud經驗，服務過上百家GoogleWorkspace與GCP客戶，擔任多次研討會主講人與教育訓練講師，提供架構諮詢與技術支援，幫助各大企業上雲。

YouMightAlsoLikeDevOps是什麼？Google實做DevOps的SRE方法介紹2021-02-04發佈留言取消回覆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免費報名線上技術研討會聯繫我們