以製造GPS聞名的Garmin，今（2021）年3月，在人力銀行網站發布了SRE（Site Reliability Engineering，服務可靠性工程師）招募資訊，要來負責維運在K8s環境上運作的製造管理系統，希望能確保系統的服務可靠性。

但他們不是唯一一家要招募SRE的臺灣大型企業。根據Google臺灣的調查，去年，臺灣傳統大型企業，特別是製造業和金融業，開始接觸SRE維運理念，甚至開始嘗試導入SRE方法論。

盛行國外多時的SRE作法，如今，在臺灣，不僅可在數位原生企業裡找到蹤影，這波SRE風潮也開始吹進傳統大型企業。根據iThome今年度的CIO大調查，有2.3%企業今年有意導入SRE。

臺灣也有不少數位原生企業，早就開始實踐SRE，例如，17Live集團、91App、MaiCoin、生活市集等，都已採用SRE作法多時，或像Line臺灣也在去年，建立了本地的SRE團隊。

從104人力銀行的SRE職缺數來看，今年4月，隨時都有逾70筆招募資訊，且發布職缺的企業橫跨各產業，從對SRE接受度較高的網路服務業，到銀行業、零售流通業、高科技製造業等產業，都可見對SRE人才的高度需求。像是中國信託、玉山、國泰世華等銀行業者，最近都在人力銀行上招募SRE人才。

SRE是一種維運心態，以及確保系統可靠性的一系列實作、指標和慣例方法，但它不是最近出現的維運工程新作法，早在國外盛行了五、六年。

2003年時，全球第一個SRE團隊誕生於Google，當時負責Google搜尋服務全天候維運工作的現任Google工程副總裁Ben Treynor Sloss，也就是SRE名稱的發明者，提出SRE理念，他宣稱，「可靠性應是任何產品設計的最基本概念。」

SRE專注不斷最佳化其負責的系統之架構設計、維運流程，確保系統運作得更可靠，且具更高的擴充性，以有效的利用資源。Ben Treynor Sloss表示，「一套系統倘若無法讓人能穩定使用，就沒有存在的意義。」

Google有多重視和倚賴SRE一職，可從SRE在Google握有多大的權力，一窺究竟。時任Google儲存服務SRE部門總監Melissa Binde在一場演講中曾說，Google SRE維運人員「有做任何決定的權力，甚至，可關閉Google搜尋、Gmail等，都會獲公司高層的支持。」

起初，SRE的出現是為了維持Google.com正常運作，隨著時間演進，Google SRE逐漸接管了Google內部絕大部分的正式系統，包含Gmail、GCP服務等，到了2014年後，Google開始對外揭露這個強而有力的維運工程職務，還有SRE作法，引起外界關注，並陸續有知名企業導入SRE，像是LinkedIn、Netflix等。

其中，又以Netflix實踐SRE的經驗最具代表性，他們與Google一樣不吝出書或通過演講來分享自身作法，許多初接觸SRE的企業，更視Netflix為學習典範。

觀察企業導入SRE的態勢，可從兩個企業屬性一探，分別是數位原生企業和傳統大型企業，而SRE導入過程則可大略分為三階段，第一，認識SRE方法論；第二，讓組織接受SRE文化；第三，在生產環節採用SRE作法。

Google Cloud客戶解決方案經理林書平觀察，整體來看，臺灣數位原生企業導入SRE步調較快，包含了新創、媒體、遊戲等。林書平表示，數位原生企業多已跨過了，組織接受SRE文化的第二階段，開始開發符合SRE方法論的工具和服務，甚至，有些領先者已經在生產環境採用SRE作法。

相較之下，臺灣傳統大型企業的採用腳步較慢，去年開始，才慢慢形成採用SRE的具體想法，多為製造業和金融業企業，其中又以高科技製造企業和銀行業的採用態度最為積極。

從進程來看，傳統企業SRE先行者已經認識了SRE方法論，並具備SRE知識，現開始嘗試導入SRE文化進組織，但，導入過程中，多會面臨轉變既有組織文化的壓力。林書平說明，傳統企業多已有數十年的發展歷史，承載了許多不符SRE文化的老舊系統和技術，且無法馬上打掉重練，是傳統企業導入SRE的一大挑戰。

導入SRE前，企業需先丟掉舊包袱

傳統企業受舊技術和既有組織文化的束縛，導入SRE的過程中，相較數位原生企業，會面臨更多的挑戰，林書平點出Google臺灣觀察到的三大挑戰。第一個是流程面的挑戰，SRE須參與服務開發流程，與開發和IT維運團隊緊密合作，所以，面臨平衡開發和IT維運團隊間衝突的挑戰。

傳統上，軟體開發團隊和IT維運團隊各自持有的目標，相互衝突，開發團隊求的是持續創新，會不斷推出新功能，但，連帶影響了服務的穩定性，因此，與IT維運團隊求服務穩定的目標衝突。林書平表示，SRE會參與開發周期來掌握開發團隊設計功能的方式，還有整合自動化維運機制進原有IT維運程序，因此，企業需從流程角度切入，來平衡兩團隊目標上的衝突。

其次是人員組織上的挑戰，傳統企業的各部門不旦龐大且各自為政，所以，部門間缺乏緊密的溝通，是推行SRE作法的阻力。林書平表示，傳統企業開發新功能時，各部門需利用工單溝通，過程冗長、耗時，違背SRE推行開發、維運和營運三方敏捷溝通的作法。

第三點為文化面的挑戰，多數傳統企業面對意外事件時，會找出應承擔責任的團隊或人員，這與SRE推行的不究責文化（Blameless Culture）背離。SRE在意外事件發生後，會進行問題根源分析（Root Cause Analysis，RCA），講求對事不對人檢討，因為，在SRE概念裡，發生問題是正常的，而找出問題的改善方式是讓系統持續演進的動力來源。

林書平表示，如果團隊因擔心究責，而相互卸責，並找方法掩蓋問題，便很難找出問題的真正原因，所以，企業想實踐SRE，需建立不究責文化，才能落實問題根源分析。不過，要形塑新的組織文化，單靠學習文化概念行不通。

因此，林書平建議企業導入一些SRE實作，來開始慢慢建立SRE程序，逐步改變組織的文化思維。比如說，導入問題根源分析作法，回溯問題時，把焦點從討論問題的原因，轉為討論應採取哪些改善措施，來避免問題再度發生。

用SRE建立自動化維運機制

傳統維運工作多需仰賴人工手動操作，非常耗時，且工作項目高度重複，因此，SRE聚焦從軟體工程角度出發，開發自動化維運機制，來降低手動操作需求，提高維運效率。林書平表示，SRE方法論所設目標為，手動作業占5成以下SRE整體工作時間。

SRE通過監控系統的運作狀況來維運整體服務，確保服務的可靠度，雖具有維運責任，但林書平表示，SRE團隊不會取代傳統IT維運團隊。SRE是從軟體工程角度思考，如何提升服務的可用性和可靠度，與傳統IT維運非常不一樣，且不會實際維運基礎設施的硬體，無法取代傳統IT維運團隊。

相反的，SRE需與傳統IT維運團隊合作，了解傳統IT維運團隊如何維運硬體，來進一步將自動化維運機制與原有IT程序整合，還有與開發團隊合作，了解服務的設計方式，以知道如何維運、監控服務。

不過，有些企業整體基礎設施都採雲端服務，特別是數位原生企業，有的全部服務都是採雲原生技術，不需自行維運基礎設施，由雲端業者代勞，這樣的基礎架構環境下，企業沒有設立傳統IT維運團隊的需求，僅需要SRE團隊。若是企業採混合雲架構，保有本地端機房，則還是需要傳統IT維運團隊負責維運機器。

上手SRE，Google建議先做這4件事

如何上手SRE是不少有意採用企業苦惱的事，林書平建議，需先確立導入SRE的目標和目的，再行動。他提出4項SRE上手建議。首先，設定服務級別目標（Service-level Objective，SLO）。企業可從定義SLO開始，串聯SRE、營運、開發和IT維運單位一起討論，全體共同的服務預期狀態目標，再延伸定義服務水準指標（Service Level Indicator，SLI），決定監控機制需收集系統的哪些運作指標，來確立需觀測系統的哪些運作數據。

其次，建立SRE強大的軟體工程開發能力。因SRE從軟體工程角度出發，開發維運工具，還有設計自動化維運機制，所以，組織內需有堅強的軟體開發工程人才。林書平提醒，SRE工程師不是單純的系統工程師或系統管理員，他們聚焦以軟體工程方式開發SRE工具。

第三，企業管理高層應扮演強力後盾，全力支援SRE實踐。當SRE掌握的錯誤預算（Error Budget）已瀕臨臨界點時，需判斷如何調整系統運作狀況，或是新功能發布步調，來確保服務的穩定性。林書平表示，企業高層需賦予SRE相關決定權限，像是新功能發布權限，才可確保系統的穩定性，不然，SRE團隊就會淪為一般的維運團隊。

第四點建議是，建立完善的反饋迴圈（Feedback Loop）。若發生意外事件，完成問題根源分析後，SRE需把改善行動反饋給所屬的職責團隊，像是向軟體開發部門提出軟體品質需改善的反饋，來避免相同事件再發生。

而對於已導入SRE多時的企業，則可以關注SRE與AI貼近的兩個特點，第一，兩者都是資料導向（Data-Driven），靠收集資料來做判斷；其次，都以實現自動化為目標。林書平表示，因特質相近，SRE借助AI有很好的空間可發揮，有機會透過機器學習來解決維運問題，像是異常偵測、容量管理等。企業若想利用AI來自動偵測系統的異常狀況，累積一定程度的異常事件資料量後，可以利用資料訓練模型，來偵測異常。

比如此次專題採訪到的17Live，已累績逾3年SRE經驗，近期開始規畫運用AIOps概念，建立具推論能力的災害預警及復原系統，自動偵測異常流量狀況，來協助SRE及早排除問題。

為了呈現企業實踐SRE的經驗、方法和影響，iThome專訪了兩家臺灣企業分別是17Live和Line臺灣，請他們現身分享在地的SRE導入經驗，另外，還跨海視訊全球金融業界中，導入SRE的銀行先驅新加坡星展集團，向讀者揭露他們擁抱SRE的8大準則。儘管因企業屬性、系統運作狀況等各有不同，造就3家企業實踐SRE的做法不一樣，但，可以肯定的是，在這個需快速交付新功能的數位化時代，SRE已成為他們確保系統可靠性和可用性的靈魂人物。

文章來源：iThome