【臺灣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臺灣先推行每個服務做到具可擴充性，今年進一步針對服務建立最佳化的自動擴充能力，預計明年可以完成。