原名為17Media的17Live,於2017年將DevOps團隊轉型為SRE團隊,4年多來,SRE團隊已經歷4大挑戰,包含公有雲環境轉移、應用程式語言轉換,還有雲端服務大故障應變,以及資料庫切分,未來,團隊還會逐漸轉型為GRE(Group Reliability Engineering),負責全集團不同服務的SRE維運工作。(圖片來源/17Live)

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實作的唯一重點是,不能有怕事的態度,要勇於跟其他部門溝通,如果害怕踩到其他部門的界線,就無法成就任何事。


熱門新聞

Advertisement