最新消息

Elastic 7.13 強化對開源主機檢測框架 Osquery 的支援

【臺灣SRE實例:Line臺灣】如何確保Line服務天天不中斷,專責SRE扮演開發與維運的橋樑

Line在臺灣每天傳遞的訊息量,多達10億則,臺灣人的生活可說是離不開Line。為了服務超過2,100萬名的臺灣活躍用戶,3年前,Line臺灣工程團隊就擁抱Kubernetes(簡稱K8s),來提升開發速度,以及因應瞬間流量的挑戰,去年,他們更成立一支專責的SRE維運團隊,就是要為各服務的專案團隊找到開發和維運的最佳作法。


為何Line決定擁抱SRE?得從2018年K8s導入的故事說起。

為了管理大量雲端原生應用,Line臺灣展開K8s導入,要透過微服務、容器和DevOps,更即時調度基礎設施資源的需求。

當時負責開發新服務Line Now、Line Spot應用的Line臺灣資深工程師蔡智強,率先嘗試K8s,發現擴充彈性確實可以更自由,促使Line臺灣技術長陳鴻嘉決定擴大導入。

起初,Line臺灣採取單一叢集的部署策略,各服務共用同一個K8s叢集。然而,陳鴻嘉回顧,這個部署方式,沒有建立一套通用的維運實作範例,導致不同團隊各自調校自身的應用程式時,就可能會影響其他團隊應用程式的運作。後來,各團隊改採自建專用叢集的方式,來避免相互影響,但,專案團隊自建的叢集缺乏穩定度,仍非最佳作法。

2019年年底,Line總部在自家IaaS雲端基礎設施服務Verda平臺上,開發了一套K8s平臺提供容器服務Verda K8s Services(簡稱VKS),而VKS平臺穩定性越趨成熟。在2020年第二季時,陳鴻嘉決定把Line臺灣本地容器化開發專案,全部轉移到VKS上,就不需再自行維護底層K8s叢集,且各團隊可在VKS上使用自己專用的叢集。

為了降低容器化專案轉移到VKS的門檻,陳鴻嘉成立了DevOps任務小組,找來蔡智強擔任組長,教導各專案團隊派出的種子成員,如何轉移專案上VKS,以及如何使用VKS,並幫助專案團隊解決搬遷過程遭遇的問題,所以,小組還扮演著與總部溝通的統一窗口,收集各種VKS使用問題反饋給總部。

然而,考驗緊接而來,越來越多應用搬上容器環境後,不同專案在軟體架構上開始遇到類似的問題,而且都是棘手維運問題。DevOps任務小組開始討論,需要打造哪些工具和維運作法,但小組成員仍各自有專案開發工作,遲遲無法抽身來投入維運工具的開發。

陳鴻嘉表示,那時發現,必須有專職維運團隊,才能滿足各專案共同的維運需求。

所以,2020年第三季,Line臺灣正式成立了SRE團隊,由蔡智強領導這個專職團隊,來打造共用工具,建立一套維運管理作法,來減少各團隊部署容器化應用的時間,加快開發和交付服務的速度,另一方面,也負責彙整VKS平臺使用狀況,回報總部。


為求更即時調度基礎設施資源的彈性,Line臺灣從2018年開始,採用容器來取代VM,先自行建置一套K8叢集,而待總部在基礎設施平臺Verda上,建置了容器服務VKS,去年第二季,更把全部容器化開發專案,搬上VKS,來省去維護K8s叢集的工作,未來,還要進一步轉移所有專案到VKS。(圖片來源/Line臺灣)


Line臺灣SRE團隊3大責任

進一步來看,Line臺灣SRE團隊身負3大責任,第一項是負責開發跨服務共用工具,是現階段主要工作,占了SRE逾一半的工作時間。目前正聚焦觀測(Observability)平臺的開發,再陸續開發追蹤方面的共用工具。

第二項責任是支援開發工作。例如在新服務架構設計階段,協助解決架構問題。或是協助評估新開發項目所需的資源,協助規畫未來的容量需求,或幫忙審視新服務中是否有老舊技術債。特別的是,SRE還會與開發團隊討論新服務的開發作法。

蔡智強解釋,SRE會提出一些與日後維運有關的開發建議,開發團隊若採用,一旦有狀況發生,SRE才可以快速地介入,觀測服務的運作狀況,找出問題,他強調,統一相同開發需求的作法,才可以用最少的資源,並提供最多的支援。

最後一項責任就是,支援維運工作,協助專案團隊處理維運問題,像是調整參數。陳鴻嘉表示,排除問題是SRE的重要工作之一,因為大部分應用程式開發者不熟悉軟體堆疊中,應用層以下每一層的狀況,像是網路層、OS層、容器層等,需要SRE團隊幫忙,在軟體堆疊每一層中找尋問題,再反映給該層的負責人。

Line臺灣向來特別重視工程師文化推廣,因此,陳鴻嘉還找來目前領導DevOps任務小組的Line臺灣首席工程師劉栢峰,協助SRE團隊推廣他們建置的共用工具。劉栢峰過去是QA架構師,也熟悉DevOps、CI/CD、自動化測試等,他以長久累積的經驗,把SRE建立的工具和維運作法,串連成一套流程,讓這一套作法更有效率,方便推廣到每一個專案團隊。

現階段,Line臺灣SRE團隊已經從DevOps任務小組中獨立出來,但與任務小組間的關係仍密不可分,成員會參加彼此的周會。蔡智強表示,SRE需要知道各專案推行上遇到那些問題,才可以找尋解決方式,或是建立工具、機制來幫助他們,相反地,SRE建立了新工具,也需要DevOps任務小組協助推廣。


SE、SRE和DevOps大不同

其實一開始,Line並不是要設立一個專責SRE團隊,而是要設立服務工程師(SE)的角色。但後來陳鴻嘉發現,SE角色同樣也沒有餘力開發新工具。因為SE不只要管理底層基礎架構資源,還要處理許多日常維運工作,或是應用程式工程師的需求,像是準備雲端資源,甚至,服務發生故障時,需第一時間查找問題,所以需隨時待命。

陳鴻嘉指出,建立DevOps文化,也涵蓋開發和維運的流程、機制,但這對Line臺灣來說,還不夠,因為應用程式的需求和變化非常複雜,還需要一套標準化、自動化作法。「要達到自動化,就需要最佳實作的範例。」

因此,Line臺灣決定在開發者和基礎架構團隊中間,設立專責團隊,也就是SRE,來從開發者角度找出基礎設施資源的運用模式,建立標準程序。陳鴻嘉表示,SRE做的不是服務工程師的工作,不會為服務準備機器,在他的規畫中,SRE應是應用程式工程師與服務工程師之間的橋樑,要建立雙邊共通的作法,並以實現自動化作法為目標。

陳鴻嘉形容SRE與DevOps的關係,「如果DevOps是一個架設精緻的時鐘,每一個環節緊密相扣,那麼SRE就是提供源源不絕的動力的軸心,讓每個環節能夠完美結合。」

而和SE(服務工程師)相比,蔡智強解釋,SRE聚焦的是,如何訂定服務的可靠性指標,以持續觀測,再進一步來提升每個服務的效能,SRE(服務可靠性工程師)多了R(可靠性),就是將R可靠性放進組織定位中,他強調,可靠性是Line臺灣SRE工作的主軸。

特別的是,Line這個SRE團隊的成員,全端工程師比例很高。陳鴻嘉解釋,他期望臺灣工程團隊,要有能力鑽研軟體堆疊底層,也從整體堆疊架構角度來思考所開發的服務,才更容易發覺問題,因此,他從先SRE團隊開始,提高Line臺灣工程團隊的全端工程師比例。

另外,DevOps任務小組裡來自各團隊的成員,也肩負了推廣SRE作法的任務,將這些SRE的知識帶回各自的專案團隊,再由擅長全端能力的SRE團隊,從旁協助專案團隊排除問題。

陳鴻嘉表示,SRE沒有交付服務功能的時間壓力,可投入更多精神處理專案團隊的問題,他提到,這也是為什麼他沒有交予SRE服務維運待命(On-call)的輪班工作,他不想將SRE變成了SE。


Line臺灣工程團隊有三大組織策略,其中,新建立的SRE團隊扮演著與總部溝通的統一窗口,反饋各專案使用容器服務VKS平臺的狀況給總部,並進一步建立一套各專案共用的維運管理作法,來加快開發和交付服務的速度。(圖片來源/Line臺灣)


先打造服務觀測平臺,再統一量測標準

有了專責團隊,就可以展開SRE共用工具的開發。Line臺灣SRE團隊首先打造的工具就是,可掌握各服務運作狀況的觀測(Observability)平臺,更進一步再來訂定服務統一的監控量測指標,包含可用性、延遲時間等,來持續觀測服務的可靠度,還有收集服務的量測數值。Line也將觀測平臺打包成容器映像檔,讓開發團隊建立新服務時,直接使用,嵌入服務底層中,不需重新開發,還可加快新服務開發速度,減少了自建追蹤機制的開發工作。

蔡智強解釋,上了雲端,再加上採用容器取代VM,環境變得非常複雜,一個服務可能有30至50個容器,必須深入服務內,觀察每個容器的運作情況,才能掌握整體服務的健康狀況。陳鴻嘉補充,觀測平臺不是單純的console.log追蹤機制,而是日誌和報表系統間的一種觀測工具。

Line臺灣過去缺乏統一的服務觀測方式,導致各專案團隊各自從不同的角度觀測服務,缺少了一致的觀測標準。陳鴻嘉坦言,在管理面上,這個不一致帶來了兩大挑戰,第一,和利害關係人、業務團隊主管溝通系統運作狀況時,缺乏可描述系統穩定性的依據,也缺乏一套比較系統間穩定性差距的統一標準。第二個挑戰是,無法評斷哪個專案團隊的開發效能較好,也缺少最佳實作範例供團隊間相互學習。

蔡智強表示,SRE團隊要通過觀測平臺,來量化服務的可靠度。除了從各方面觀測系統數據的變化之外,還要從同一個角度來觀測服務,像是服務可用程度、回應正確率、回應時間都有一致標準時,就可以供專案團隊對內提升可靠度,或是讓團隊間對外比較可靠度。

但是,要統一各種服務的觀測標準,不是一件容易的事,每個服務面對的狀況不相同。Line SRE團隊會與業務團隊討論,先找出最有價值產品(MVP),再找出單一服務中最重要的功能,然後,從使用者的角度觀測這些功能,來確認這些服務是不是活著。

以觀測網路服務的可用性為例,監控程式會啟動實地測試,掌握連線速度,確認能不能載入服務,再統計單日總測試數中失敗的比例,來了解服務的可用性。目前Line臺灣設定的可用性標準為,至少需達99.95%以上,也就是單日1萬次測試,最多只能有5次失敗。

從使用者角度下手,建立業務有感的量測值


不只是建立觀測標準,陳鴻嘉還期待,SRE要進一步做到,從使用者角度,來量化服務效能或體驗的指標,讓業務團隊也能掌握這些觀測數值所代表的服務實際運作狀況。他解釋,以往與業務團隊溝通服務的可靠度時,像是提出服務延遲時間為0.8秒,然而,業務團隊往往難以了解,這個0.8秒延遲對用戶體驗的影響。為此,Line臺灣工程師早在去年就開始研究Google Web Vitals指標,要來找出如何用指標描述使用者的使用體驗,再進一步連結這些數值和使用體驗間的關連。

不過,去年設計觀測標準時,Line臺灣手上缺少了,以相同標準觀測各服務運作狀況的數值,這也是SRE團隊選擇優先打造觀測平臺的原因,就是為了先蒐集足夠的服務運作狀況數據,才能與業務團隊討論,如何訂定從使用者角度出發的量測指標,來媒合使用者體驗與量化數值。

目前,Line SRE團隊仍在持續擴充觀測平臺的功能,平臺儀表板功能除了可以顯示服務可靠性的各種觀測指標外,還可以呈現所用機器的記憶體用量、CPU數量等資訊,且因這些容器化服務都部署在VKS平臺,也嵌入了VKS相關指標,包含了節點數量、Pod數量、執行效能等。Line臺灣的目標是,將總部基礎設施和網路的相關數據,全部都整合進這個自建的觀測平臺,方便追蹤更多細節。

除了建置觀測工具,SRE團隊還利用開源軟體開發了多種工具,其中,為因應各團隊部署K8s的需求,使用了持續派送工具ArgoCD,結合Git儲存庫,可以做到GitOps。K8s搭配GitOps作法可帶來許多的好處,蔡智強舉例,可以將直接操作K8s叢集的行為最小化,進而降低手動操作造成的叢集不確定因素,還可以追蹤所有叢集的變動及變動的時間點,並可以在同一處管理配置。為了避免發生人工操作的錯誤,來開發更自動化的工具,也是Line SRE確保服務可靠性的一種作法。


專責SRE團隊創造三大價值

Line臺灣SRE團隊成立不到一年,蔡智強表示,但已經帶來了三大價值。首先,專案團隊使用VKS遭遇問題,SRE團隊會收集這些問題與總部討論,找出解決方法。尤其,去年,Line臺灣將所有容器化專案轉移到VKS的初期,遇到了很多除錯需求,許多問題出現在軟體堆疊的底層和中層,都是靠SRE團隊直接向總部反映。

陳鴻嘉表示,專案團隊忙於開發應用,沒有時間查找問題,過去沒有SRE作為中介,每次解法就是重新啟動,所以,現集中透過SRE與總部討論問題,不僅可加快問題查找的速度,各團隊也可更快獲得新作法,大大提升效率。

VKS平臺上線後,過去一年來持續在擴充,有許多異動,經驗豐富的Line臺灣SRE團隊,除協助自家專案團隊排除VKS的使用問題,反過來也協助了不少總部VKS平臺的優化工作。蔡智強道,總部常開玩笑說,我們是他們的SRE。

Line總部建置VKS平臺所用的技術,與Line臺灣早期建立K8s共用叢集的技術類似,兩個團隊經常交流,臺灣SRE團隊也加入了總部VKS維運問題的討論,每周都會討論和交流技術。陳鴻嘉笑言,總部很喜歡我們,因我們不僅常回報問題,且會與他們一起討論、解決。

在技術類似的基礎上,Line臺灣SRE團隊有時可直接向總部提供,平臺建置方式的建議,協助提升平臺的效能,有時會提出應用程式開發端在採用K8s上的需求。蔡智強解釋,因總部從建置基礎架構的角度出發,聚焦提升平臺的效能,缺少與專案團隊直接接觸的機會,而會忽略應用程式端的需求。

VKS平臺穩定性如今大幅提升,起初,臺灣SRE團隊每周需審視兩到三個VKS事故,如今已下降為,每一兩個月審視一到兩個事故。

SRE帶給Line臺灣的第二個價值是,提升工程團隊與利害關係人及使用者的溝通順暢度。工程團隊與利害關係人描述服務的可靠度時,可利用觀測平臺收集的數值,作為依據,不過,SRE仍在持續優化觀測平臺,還有統一量測標準。陳鴻嘉表示,目前還未能完全實現溝通上的價值。

第三個價值是,Line臺灣SRE團隊會逐步打造一套容器化服務的統一自動擴充機制,平時就不需再準備眾多的待命機器,進而節省了基礎設施的花費。但是,Line臺灣目前各專案團隊大多採用自己的擴充作法,還沒有完全統一,也常用手動方式來啟動擴充功能,導致擴充速度還不夠快。

未來,Line臺灣SRE計畫要整合各服務的共通需求,來訂定出可以自動判斷需擴充容量的一套規則,進一步打造最佳化自動擴充機制,以節省各服務的成本。陳鴻嘉表示,流量峰值瞬間可達平時的20倍,甚至100倍,需隨時準備較平時使用量多10倍的機器待命,有了自動擴充機制後,最少可以省下一半待命機器的數量。


解決問題是SRE須具備的核心能力

問及SRE須具備什麼樣的能力?陳鴻嘉不假思索的回答,「很簡單,那就是解決問題的能力。」他表示,SRE需永遠清楚怎麼找到問題,接著,還需知道如何找解決方案,並思考什麼方案才是問題的最佳解,而不是採權宜措施(workaround),把問題留著,服務能繼續運作就好,「這很危險,問題留到最後,會累積大量技術債,反而隨時會出問題。」他強調,找出問題的根本原因,才能長治久安。

成立還未滿一年的Line臺灣SRE團隊,未來將持續開發更多的共用工具,還有建立更多的最佳實作範例。對於SRE下一階段的發展,陳鴻嘉設定了兩大目標,要借助SRE團隊建立的共用工具和作法,新工程師入職當天,如應用程式出現問題,需救服務,新人5分鐘就可進入開發環境,協助排除問題,不像過去得花半天裝環境。如果,需處理新專案,新人也只需半天就可建立模型。

第二個目標是,為了因應流量高峰,每一個容器化的服務都要具備自動擴充功能。去年,Line臺灣先推行每個服務做到具可擴充性,今年進一步針對服務建立最佳化的自動擴充能力,預計明年可以完成。


文章來源:iThome