17Live集團技術副總經理徐永吉 (攝影/洪政偉)

「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在保護系統上的責任。


熱門新聞

Advertisement