【臺灣SRE實例：17Live集團】多功能型SRE化身內部信心來源，天天成為開發團隊後盾

17Live集團旗下服務的使用者超過5千萬人，遍及全球，如何持續地提供穩定的直播服務，靠的是背後一支強而有力的團隊，隨時洞察系統狀況，發生異常時，第一時間查找問題，並即時回報各單位，快速採取應變措施，他們就是SRE團隊。

2017年時，17Live關注到Google大力推行的SRE維運方法，切中他們想強化服務可靠度的目標，希望維運人員可以跳脫維運工作上的傳統框架，不再只是負責管理機器，而是更密切地與不同單位的人員接觸，提供他們需要的基礎架構支援，因而決定將DevOps團隊轉型為SRE團隊。

過去曾有維運工作經驗的17Live集團工程總監林毅民，現負責率領這個SRE團隊。他指出，傳統維運團隊多是負責一些例行工作，例如，主機監控。他指出，這樣的工作內容讓維運團隊像是一個後勤單位，不容易彰顯價值。但是，「導入SRE作法，可讓維運工作變得有價值、有意義，不可被取代。」林毅民強調。

尤其他想要以研發角度開發內部軟體，來取代高度重複的例行維運工作項目。像是監控工作，SRE工程師可以建立自動化監控機制，只有當流量超過設定門檻，維運人員收到緊急警報後，再展開行動，不需像過去得時時待在機房監控狀況。

不僅改變維運工作的執行方式，林毅民更要塑造SRE團隊成為，「17Live內部的信心來源、可信任的對象」，來支援開發團隊在每個上班日發布部署服務新版本。

他解釋，SRE團隊要帶給工程團隊的，不單是做事方法、做事原則，而是，一份可靠度、信任感，讓開發團隊感受到，有SRE在，他們可以放心地交付功能、服務。

5大角色組成SRE團隊

17Live所打造的SRE團隊是多功能團隊，可以分為5個組別，第一個是資料庫團隊，負責管理各類資料庫，包含了RDB、NoSQL、Redis等，負責建立機制來監控資料庫的各種指標，並與開發工程師討論如何優化查詢；第二組是基礎架構團隊，負責支援兩種雲端環境：GCP和AWS，以及配置公有雲環境裡的容器，並打造完整的監控系統，來確保叢集的穩定性；另外，還有自動化團隊，利用軟體開發概念來改善基礎架構的開發工作，像是自製各種Slackbot。

再來，還有一組資安團隊，負責從系統、應用程式和容器不同面向，強化資訊安全，確保有效阻擋潛在風險或外來攻擊，如DDoS、SQL Injection等，還有培養全體企業人員正確的資安觀念，無論工程人員或非工程人員，都須落實資安防護作為；最後一組人馬是技術服務團隊，相當於一般企業服務內部員工的IT部門，負責提供全球17Live人員的資訊服務，目標提升全體人員的個人生產力，及提高內部溝通效率，並協助各部門盤點系統採購的需求。

這種多工型的技術服務團隊出現在SRE編制中，相當特別，林毅民解釋，他們扮演的是各部門的IT諮詢顧問，要賦予內部人員使用的資訊產品信賴感，他提到，以往IT都是用傳統、簡單的方式驅動內部資訊化建設，他以監控工具使用狀況的工作為例，IT人員多僅確認各單位人員有沒有使用生產力工具。

在17Live，SRE團隊要利用自身維運經驗，向內部各單位不管是業務、人資，還是財務部門，提供更敏捷的工作方法，來提高工作生產力，進而營造SRE是一個可信賴的單位，除了確保服務可靠性，還可增進人員的工作效率。

從4階層訂定SLI，監控服務穩定性

隨著17Live決策團隊開始採用目標與關鍵結果（Objectives and Key Results，OKR）的管理方法，訂定全公司的共同目標，而各事業單位也需要量測指標作為基準，來衡量不同時間點的服務狀態，與預期目標上的差距。

因此，SRE團隊在去年制定了服務穩定性指標（Service Level Indicator，SLI），從4個層級：叢集、系統、應用程式和原始碼邏輯，來監控服務的穩定性。除了偵測CPU、記憶體或磁碟容量等常見資源的指標外，還會偵測網路I/O、磁碟I/O等。另外，目前在監控系統運作上，17Live使用的是監控服務Datadog，也透過VividCortex更細微地監控MySQL 指標。

林毅民表示，任何細節對17Live來說，都至關重要，SRE會與開發人員一同建置這些監控指標。這些SLI指標除了是各單位衡量OKR的參考標準，更是SRE團隊在服務發生異常時，找出影響服務穩定性肇因的主要依據。

以應用程式自身發生異常的狀況為例，SRE團隊有時無法從系統上直接看到異常的流量情況，必須透過監控機制的指標才能判斷，究竟是服務的哪個層級發生問題。

甚至，過去17Live曾遇到雲端供應商服務出現問題，但警報系統沒有發現流量下滑的異常，直到用戶抱怨無法登入，他們才意識到問題。林毅民提到，後來，一旦發現了異常警報機制無法掌握的情況，SRE團隊就會盡快增加更多監控指標和警急通報，希望能在用戶反饋前即發現問題。

除了針對系統運作狀態制定監控指標，17Live SRE團隊還建立了另一套，從營運端角度來觀測服務穩定性的燈號儀表板。該機制羅列服務會發生的各錯誤，再依錯誤的嚴重程度分級為P0、P1、P2、P3，而每一個分級都有自己的加權分數。

這個燈號監控機制背後有一支程式，每天會計算，當日往前推30天內，服務發生了多少次的錯誤，再從100分往下扣除所有錯誤加權分數的總和，來代表整體服務狀態的總分數。這個分數不只用來觀察服務狀態，也會影響17Live工程團隊的開發優先順序。

這個總分數若大於80分，儀表板會顯示綠燈，代表17Live現在可以開發一些風險比較高的新功能；黃燈是介於60到80分，代表SRE團隊以及後端工程師必須投入在維持系統穩定性；紅燈則是低於60分，代表工程團隊全體成員都必須花更多時間優化穩定性，並且，調整部分工作排程，盡可能避免高風險的新功能上線。

待命機制每15分鐘更新一次當前問題處理狀況

有了完善的SLI，一旦SRE團隊監控指標的數值，超過設定的水位，就會觸發待命（On-call）機制，通知當日值班待命的SRE人員，或是後端工程師。林毅民表示，後端工程師也須待命輪班，來了解SRE如何排除問題。

有時待命機制發送了錯誤警報，為了避免「狼來了效應」發生，每一次都會找來後端工程師比對，確認和修正警報的正確性，他強調，每次警報觸發都需待命人員，扎扎實實的排查問題。

為了有效啟動待命機制，17Live SRE團隊還整合了警報和待命管理工具Opsgenie，以撥打電話或是發送簡訊的方式，自動通知輪值的待命人員。

待命者收到警報後，5分鐘內必須立即上線，開始調查當前問題發生的狀況，排除問題。若判斷疑似是當日服務發布的新版本造成問題，為了快速修復，值班人員甚至有權限直接退版，還原到前一版功能，不需先向主管報備。

如果不是服務上新版的問題時，值班人員需監控其他資源的指標，例如資料庫、基礎設施等，通知指定相關人員上線排解。一旦，經10分鐘仍然無法解決問題，17Live要求，必須即刻通報SRE主管及工程團隊技術副總，向上拉高事故處理的層級。

接著，SRE主管會隨即成立緊急應變小組，以15分鐘為單位，持續向17Live全球人員更新問題的最新狀況，讓所有人員同步了解當前狀態、處理狀況，以及預期服務可回復的時間。

林毅民表示，每15分鐘發布一次問題狀況，可以讓全體人員安心，了解當前處境，知道應如何安撫自身面對的用戶，像是VIP觀眾、直播主等都需要了解狀況。

等到問題都順利排解後，SRE團隊還需知會此問題的相關人員，來撰寫檢討報告（Postmortem，又稱驗屍報告）。林毅民表示，這是取經自Google的SRE作法，應用到17Live整個工程團隊上。

不過，17Live沒有照單全收，而是將Google原始的檢討報告作法精簡濃縮。撰寫時主要聚焦4大要點，包含整起事件的時間軸，從故障何時發生，到修復過程各時間點做了哪些事情；再來是背景資訊，說明問題的根本原因，故障造成了哪些狀況；

還需要撰寫改善事項（action item），需採取哪些動作來防範類似問題再次發生；最後一項是從這次經驗中學習到的事（lesson we learned），未來若遇到相同情況應如何解決。

林毅民表示，撰寫檢討報告可帶來許多好處，讓工程團隊知道如何解決問題，以及改善，避免問題再次發生，甚至可以幫助提早預知問題，提前做相應的對策。

不過，他強調，故障發生當下，SRE團隊不會馬上花力氣找根本原因，而是先降低故障機率，或是減輕影響範圍。等到故障都排除之後，再回頭查找根本原因，撰寫檢討報告，而公告檢討報告後，還會召開檢討報告結案會議，來確保已確切執行各改善事項，並持續提升系統的穩定度。

17Live集團工程總監，同時也是SRE團隊主管的林毅民表示，傳統維運團隊做的多是例行工作，無法彰顯工作價值，導入SRE作法後，以軟體工程角度來解決基礎架構面臨的問題，「可讓維運工作變得有意義，不可取代。」（攝影／洪政偉）

SRE團隊已經歷4階段挑戰，首先，面對公有雲環境轉移工程

17Live SRE團隊成立4年多來，已經歷了4大階段性的挑戰。首先，隨著業務規模持續擴大，開發需求越來越多樣化，為了使用GKE來獲得更好的Docker支援，讓容器化開發環境更具彈性，整合每日處理資料量多達1TB的GCP資料分析工具，如BigQuery，17Live在2018年5月時，用3天時間，將服務從AWS遷移到GCP。

能夠3天完成這項搬遷工程的背後推手正是SRE團隊，這也是SRE團隊頭一次面對如此大型的搬遷工程，因此，團隊早從前一年就開始著手準備，討論如何做才能減少中斷時間，降低兩大使用者：直播主和觀眾，在使用服務上面臨的影響，足足耗時約半年才完成了縝密的搬遷工程計畫。

SRE團隊先在雲端測試環境中，藉由不斷測試不同的搬遷方式，來計算中斷時間，也一步一步抽絲剝繭，尋找潛在的風險。

為了避免一次性搬遷後，單一服務在新環境中，被湧入的正式流量衝爆，導致整個伺服器當機，最後，決定分3天進行搬遷工程，依序搬遷MongDB、MySQL，還有最後一天遷移了應用程式和Redis。

確立搬遷方式後，SRE團隊還進行了約10次的演練，模擬整體服務的搬遷過程，就是要確保所有流程順利。最後，17Live不但順利將服務搬家，且歷時3天的搬遷工程，每天中斷時間都介於5到10分鐘。

藉由這次的雲端遷移經驗，SRE團隊建立起執行大型搬遷、升級任務的能力，知道每個環節從事前規畫、測試到執行，需要思考、準備哪些細節，再加上如何執行數次扎實的演練，才能最大的減少中斷時間，以及排除最多的可預期狀況。

除了通過自我不斷演練來確保搬遷工程順利，SRE團隊還建立了與各事業單位溝通工程內容的能力。林毅民表示，工程團隊過去因公司初創立組織規模較小，執行技術轉換工程時，不需考慮太多面向，可以直接切換，然而，隨著組織擴編，產品和使用者數量大幅增加，執行任何工程需考量的風險和溝通對象也增加。

進一步看，SRE團隊與各個事業單位事先宣布了工程技術轉換的時間點，確認服務用量在該時間是不是最低，並溝通轉換工程期間會發生哪些狀況，還有說明回溯計畫。林毅民解釋，不斷演練，還有溝通回溯計畫，就是為了讓內部有信心，讓大家知道，若不小心發生問題，甚至是失敗，還是可以回復。

挑戰2：轉換應用程式語言，減少重複性維運工作

相隔一個月，同年6月，為了落實SRE的另一項維運理念，也就是「減少做重複性工作項目」，17Live把所有應用程式從Node.js，統一改為後端常用語言Go語言。SRE團隊與後端工程師一起前後花了一年的時間，轉換程式語言，一邊更換既有應用程式語言的同時，一邊用Go語言寫新功能。

轉換期間，不同語言開發的新舊版API同時混雜，為了讓新服務可以更順暢在Go語言的環境上運作，SRE團隊特別開發了一層類似API閘道的監控工具，確保新版服務API能循著正確的程式語言途徑來執行。林毅民解釋，有時改變應用程式語言，不一定能提升應用程式效能，所以，必須監控。

挑戰3：雲端服務故障逾10小時，促展開多雲架構布局

搬遷服務至GCP後，17Live以GKE執行容器來負擔各種線上服務，然而，強調高可用性的雲端服務，不會百分百正常運作，SRE團隊需要隨時監控系統狀況，因應突發事件。

林毅民印象最深刻的一次，2019年11月萬聖節隔天，GCP發生大規模故障長達12小時，導致17Live無法新增機器，來滿足當日直播服務尖峰時段的使用需求，這是SRE團隊成立以來遭遇的第三大挑戰。

SRE團隊雖在GCP發生故障之初，即發現問題，然而，此次事件卻大大衝擊17Live服務。因為，故障事發當下為午間時段，17Live系統正處於離峰狀態，無法正常擴充容量，晚上就是高峰期，現有的系統資源肯定支撐不住流量。

再加上，17Live主要功能都集中在少數服務上，所以，一旦服務內部分功能耗盡了運算資源，例如CPU，也會連帶影響到該服務的其他功能，造成全面性的災難。

SRE團隊雖很快採取多項應變措施，像是限制用戶數、關閉次要功能，或是移除運算需求低的容器，挪出更多運算資源，來接手執行關鍵容器，林毅民坦言，但是仍舊缺乏可以積極、主動排除問題的方式，現在回想起來，他苦笑的說：「面對GCP故障，他們只能雙手一攤，無盡的等待Google修復服務。」

這次災難應變經驗促使SRE團隊意識到，如果只採用單一雲服務環境，當雲端業者發生問題，他們能做的事其實不多。林毅民表示，那次的故障事件，讓17Live正視只用單一雲端環境的風險，開始布局多雲架構的策略。

於是，SRE團隊重回AWS環境，建立災難備援機制，來因應雲端服務的突發狀況。現在，17Live只需要一個腳本程式，就能在20分鐘內，建置好AWS EKS環境，30分鐘內可以將大部分的服務完全重建。

挑戰4：資料庫達吞吐量逼近上限，切分資料庫

由於用戶及功能數量不斷的增加，17Live資料庫資料量和吞吐量也越來越大，逼著SRE團隊在去年11月，面臨拆分資料庫的壓力。林毅民表示，如今資料庫用量為2018年的3倍，已經達到單一叢集的吞吐能力上限，而且當單一叢集發生問題，整個API服務會無法正常運作。

SRE團隊規畫了服務降級的解決方案，與後端工程師一同以功能面來切割資料庫，將資料庫一分為五，其中最大的難題是，如何有效以功能面切割資料庫，因此，也請測試工程師加入，一起將功能切成不同種類的測試案例，來不斷測試，確認功能是否達預期表現。

SRE須勇於分享、發問，從不同角度切入問題

林毅民強調，SRE人員必須要具有勇於分享、勇於發問的態度。

他表示，17Live SRE團隊由不同背景的人員組成，有些人過去是銷售工程師、機房維運人員或是資料庫管理人員，每個人有不同的領域知識。因此，成員會用不同的思維切入問題，不管是從資料庫、維運端或是用戶的角度思考，所以，林毅民尤為注重勇於發問和勇於分享的態度，他表示，只要人員敢問，別人也分享給你，如此，就可以塑造正向分享、發問的循環。

對於想導入SRE工作方法的企業，林毅民建議，參考Google SRE作法，但，他強調，不應完全套用所有作法，因各企業不管是組織規模、協同方式、產品都與Google不同，因此，企業須將SRE作法轉換為自己的東西。他點出SRE實作的唯一重點是，不能有怕事的態度，要勇於跟其他部門溝通，如果害怕踩到其他部門的界線，就無法成就任何事。