【CTO看SRE：17Live集團技術副總經理徐永吉】SRE如何成為營運和工程單位的橋樑就靠2關鍵

「SRE團隊是營運和工程單位間的橋梁，」17Live集團技術副總經理徐永吉如此形容，在這個服務數千萬直播觀眾的企業裡，有一個專門負責維持服務穩定性的技術特別團隊。

平日，這支SRE團隊不斷蒐集營運單位需求，轉化為系統建置的工程指標，也須根據營運需求，事先訂定對應的標準操作程序。一旦服務發生中斷或是事故，SRE團隊還得從保證企業營運穩定性的角度來排除緊急狀況。

徐永吉指出，有別於傳統工程師作法，先找問題再想辦法回復系統，SRE團隊要優先思考如何阻斷問題擴散，讓系統盡快恢復運作。

17Live每一季回顧會議上，SRE團隊除了得掌握系統所有問題造成的情況，以及問題復原時間和速度外，還需了解服務延遲、中斷等狀況對營運表現造成的影響，徐永吉指出，SRE也要知道突發事件實際對企業造成的營運損失。

關鍵做法1：定義服務關鍵路徑

為了確保突發事件發生時，直播主仍可以開播，而觀眾也可以順利地進入直播間，來最大地降低影響，去年，SRE團隊定義出了17Live的服務關鍵路徑（Critical Path）。這份資料列出了觀眾和直播主在流量尖峰期間最常使用的功能，以及進入直播間的各種方式。

以觀眾為例，SRE團隊先從流量分析資料找出，尖峰期間，觀眾進入直播間後會看播、追蹤、送禮、留言等，而進入直播間的方式主要則有兩種，一是通過首頁點選，二是接到追蹤者開播通知後，點選進入直播間。接著，再與營運團隊討論，確認這些路徑和進入方式是否可納入服務關鍵路徑，另外，也會列出非關鍵路徑（Non-critical Path）的功能，例如動態頁面、貼文分享等。

一旦遇到突發事件時，SRE團隊首要工作是盡可能降低問題對關鍵路徑的衝擊，徐永吉表示，SRE不只是保證服務品質，而是確保突發事件對服務造成的影響能最小化，甚至有時SRE不得不關閉部分功能，「事先定義的關鍵路徑就是優先修復的依據。」

過去遇到突發事件時，沒有特別考慮受影響功能的修復順序，掌握關鍵路徑涵蓋的功能後，徐永吉表示，SRE可以明確判定問題的嚴重程度，來決定是否需要公告，並以恢復關鍵路徑為第一優先，若多項功能都屬關鍵路徑，則可進一步根據流量多寡，來確立修復順序，甚至，能藉此決定可先行犧牲的功能。在服務恢復正常的過程中，大量流量會持續湧入，也需仰賴SRE團隊設計斷路器，來阻斷流量湧入，讓服務有足夠時間擴充執行實例。

為實現以SRE為導向的開發需求，去年底，17Live將SRE審閱（review）納入軟體開發生命週期（SDLC），在每個Sprint中，加入基礎設施強健審閱（Infra Robust Review）和資料庫審閱（Database Review）兩個環節，由SRE工程師參與設計審閱（Design Review），來確保新功能在開發初期就加入營運穩定性的設計考量，讓開發端和SRE有一致的設計思維。

SRE團隊若發現新功能會影響關鍵路徑的順暢性，會建議工程師調整，並在有風險疑慮的系統環節上，及早放入追蹤器，或設定日誌紀錄機制，還有，在新規畫的SDLC管理上，SRE和工程師需一起計算每一個程序查詢量（QPS）的預估值，來掌握系統穩定度的警界線，作為待命（On-call）機制緊急警報的依據。徐永吉表示，通過新規畫的SDLC，工程師會更清楚開發時如何加入流量因應的設計，SRE則會更清楚工程師如何設計新功能，來加強自身在系統設計上的經驗。

關鍵做法2：以營運損失呈現意外事件造成的服務衝擊

去年底開始，17Live對於意外事件嚴重程度的衡量，採取了新的衡量方式，改以企業營運損失來呈現問題造成的影響。徐永吉表示，過去，SRE設定服務級別目標（SLO），是以時間來描述服務的期望狀態，也就是以時間為單位，來描述系統的中斷容忍度，各部門團隊多半可以接受。後來，改以實際營運損失來呈現中斷延遲時間造成的影響，各團隊更加能體認到，每一個問題的嚴重性，也更願意配合SRE團隊所推廣的因應措施。

然而，量測意外事件造成的營運損失不容易，需衡量每單位時間轉換營收後代表的價值，還有每項問題改善行為的價值，讓時間與營收損失對應後，再對應SRE團隊採取的行為，最後，才能得出一起意外事件造成的企業營收損失。

除了讓各單位更具體掌握故障造成的影響外，徐永吉提到另一個以營運損失衡量意外事件衝擊的好處，那就是，有時工程師為系統新增了保護措施，SLO不會有任何改變，但，現可從營運損失的變化，來代表新增保護機制的效益。

不只用營運術語，取代工程術語來描述事件的衝擊，17Live SRE團隊也加強了工程與營運部門間的互動，今年，建立了工程與營運部門共用的儀表板，轉換工程部門檢視的重要指標，包含查詢量、SLO、延遲時間等，成為營運部門易懂的指標，供營運部門檢視，建立工程及營運部門間的互信與合作。

利用服務觀測資料打造AIOps系統，預先偵測異常狀況

收集了數年SRE監測的系統可靠性資料，下一步，17Live計畫彙整SRE現有知識和經驗，建立具推論能力的災害預警及復原系統。徐永吉表示，SRE很仰賴經驗累積，需不斷處理事件來訓練判斷力，容易有一種盲點，僅熟悉特定事件的標準操作程序來照做，遇到例外，因無法全面地掌握過去所有事件的因應作法，也就無法按照標準程序處理。

所以，17Live希望利用AIOps建立推論系統，自動偵測異常流量狀況，再主動向相關負責人員發送通知，提醒近日該進行的檢查作業，檢查時若發現可疑徵兆，AIOps系統還可依照過往類似問題的相關處理經驗，提供相對應的解決措施。徐永吉表示，許多問題其實早在系統異常前一周，就會出現微小的徵兆，透過系統及早發現就能嘗試修復。「許多狀況等到SRE上場時，已來不及有效及時處理。」

SRE團隊會先列出過往檢討報告（Postmortem）涵蓋的所有改善行為，像是修改程式碼、修改配置等，並將以文字描述的解方轉化為數字，再規畫推論系統需要哪些資料來訓練，以及系統應採取那些復原動作。

推論系統除了可輔助SRE及早掌握問題外，還可在問題尚未造成系統出現異常前，緊急通知有問題的程式碼或配置的擁有者，讓工程師知道所上傳的程式有潛在風險。特別的是，不同於利用規則訓練模型的方式，17Live採用增強式學習來訓練這個推論系統，再由SRE團隊持續向系統反饋其採取行為的正確性，讓這個AIOps系統不斷學習新經驗，再轉換為日常預測動作的一環。

徐永吉表示，每當SRE團隊掌握到問題的起始時間點，就能將當日查詢量資料匯入給模型，讓AI模型學習查詢量和改善行為的關連性，希望可以訓練這套系統，有能力知道應往前回溯多少時間，才可掌握問題造成的影響，讓它建立預測該類型問題的能力。

他坦言，系統建置工程相當困難，需多方確保模型可順暢地運作，但，他相信，17Live多年累積的追蹤、監測資料將是訓練模型的最佳基礎，再加上，他們有從不同維度監控異常影響範圍的機制，所以，他有信心能打造出，有能力細緻判斷問題的模型。如此一來，日後就可以不用再擔心SRE新人因缺乏經驗，而判斷不準確，讓新系統成為新人的最佳助力，協助判斷問題，找出相對應的對策，讓新人慢慢累積自身的判斷經驗。

目前，17Live正在規畫推論系統的建置工程，先由SRE團隊確立系統應採取的復原動作有哪些，從而確定需利用哪些資料來訓練模型，接著，再交給工程團隊協助開發。

17Live為了讓SRE團隊與工程團隊更緊密合作，讓SRE更清楚開發、設計的原理及方向，來採取相對應的維運、監控策略。為此，今年，17Live首度嘗試讓SRE工程師擔任Scrum專案領導者，參與開發，從SRE角度推行專案，確保系統或功能在設計上，能達到組織期望的穩定度。

徐永吉表示，過去，SRE很少參與開發，不清楚工程師的開發考量，同樣的，工程師也不清楚SRE推動維運的方式，常造成雙方有很多的誤解，他指出，透過新的專案領導方式，兩方可相互學習，打破孤島（Silo），一旦服務出現問題，各團隊可一起發想解決方案，讓每個人都有機會幫忙排除問題，而SRE審閱開發設計時，只需給予大方向的指導，有助於提升整體團隊的表現。

SRE人才難尋，從3大特質發掘潛力新人

找尋合適、能力強的SRE人才，不容易，徐永吉直言，「超難找，」一位好的SRE工程師需具備系統維運及開發的雙重經驗。17Live現找尋SRE團隊的新成員時，會專注於發掘可塑人才的潛力，從3個面向觀察應徵者是否具實踐SRE文化的特質，第一，關注應徵者面對利害關係人時，是否尊重對方；第二，是否會同時聚焦自身和團隊的目標；最後，面對問題時，是不是能主動發想新解方。

對於想要導入SRE作法的企業，徐永吉提出了兩點建議。第一，他建議企業了解清楚什麼是SRE，確定SRE的價值。他強調，SRE不是單純的維運團隊，而是可賦予系統可靠性的團隊，他指出，應建立測試、開發和維運三位一體的思維，因為，SRE唯有了解系統狀況，掌握功能放上系統發布的品質，才可以保護系統，所以，SRE需從開發端直接給予功能設計上的建議，參與功能品質的驗證，並與營運單位接觸，才能掌握服務的實際運作狀況。

去年，17Live合併品質保證（QA）和SRE兩個工程團隊，成立可靠性部門，就是為了結合測試、開發和維運，來重新定義系統可靠度為，「在完整的系統架構設計下，經完善的機制驗證，產生符合企業營運標準的系統。」徐永吉表示，17Live希望透過兩團隊的整合，有效地達成企業穩定營運的目標，同時，兼具系統及效能持續演進的優勢。

第二點建議是，賦予SRE正確的定位。他表示， SRE不只是負責維運工作，需連結開發和維運才能展現SRE的價值，他強調，SRE的價值不在替企業節省多少基礎設施成本，也不是訂出系統可用性，或故障後修復時間的目標，而是要讓SRE聚焦，如何強健系統來降低營運損失，才能活化SRE在保護系統上的責任。