17直播SRE團隊的關鍵武器，靠容器標準化IT架構搶速度

結束一整天勞累的工作，回家打開手機、平板瀏覽各類直播節目，已成當代大眾的舒壓管道。成立未滿3年的直播平臺17 Media，累積了2,700萬個使用者，以超過50％的市占率坐穩臺灣直播龍頭，近年開始將業務版圖拓展至鄰近的香港、日本，今年還要以自家IT技術為基礎，加強即時互動性，往影音3.0發展。然而直播產業相當競爭，大型社群平臺如臉書、YouTube、Instagram、Line也相繼推出直播服務。強敵環伺之下，如何讓服務快速上線，也是17 Media資深產品科技副總裁李昀樵所面對的重大挑戰，而他構思的IT布局，「都是為了縮短上線時程。」
草創初期，17 Media的IT架構就碰上相當考驗，除了系統擴充性不佳，系統容錯系也不高，只要觀看人數增加，服務就容易當機。不僅如此，李昀樵表示，最初17 Media選擇使用客製化的通訊協定（Protocol），亦導致直播品質不佳。因此，17 Media展開一場IT架構大改革，「我們的故事很像《矽谷群瞎傳》的劇情」，在這場變革之旅中碰上許多戲劇性發展。

從2016年開始，首先通盤捨棄自家開發的通訊協定，改用標準RTMP協定外，也幾乎重新開發整套API，「就是要維持IT競爭力」，李昀樵認為，IT最關鍵的兩大要素，「就是快跟穩定」，必須讓工程師所有的專注力集中於開發新功能，而非花費精力維運基礎架構。

靠SRE團隊把關部署工作

李昀樵表示，目前17 Media的IT分工中，除了後端團隊負責開發、測試新功能，每天也會開發新版本容器映像檔，將程式碼提交至版本控制系統Git。為達到開發維運一體化的目標，現在17 Media亦有SRE（Site Reliability Engineer，網站可靠性工程師）團隊。而SRE團隊的職責，得要管理17 Media的基礎架構、資料庫、公有雲容器部署，以及建置開發環境。

如果要縮短開發者推出新功能的周期，「就必須讓開發環境非常接近正式環境」，因此，李昀樵表示，SRE團隊也會利用容器，替每位工程師建立一個獨立開發環境。而容器占用的資源不多，不需要花費過多成本外，該員所開發的程式碼上傳至正式環境時，幾乎不會產生相容性問題，「所有的IT策略，都是為了能加快上線時間。」

而SRE團隊每天最重要的例行工作就是部署程式碼，相比傳統大型公司以周計算的部署頻率，「17 Media每天都必須執行部署工作」，李昀樵表示，當程式碼部署至半正式環境，通過End-to-End測試後，便上傳至正式環境。而如此工作方法，也符合最新的DevOps工作觀念：「少量多次」，減少每次上傳至正式環境的程式碼數量，拉高部署頻率，藉以降低每次更新的風險。現在國外也相當流行自助IT服務的概念，「不過我們不會做到如此徹底」，他解釋，如果要打造徹底的自助式IT服務，必須建立完整的測試、監控流程，而一旦花費多時間進行測試工作，便會嚴重拖累開發進度。不過李昀樵也清楚，求快便會拉高風險，「必須搭配各項機制降低風險」， 因此，現階段程式碼部署至正式環境的流程，仍要靠SRE把關。

同時，IT團隊的開發流程也有導入持續整合（CI）的工作方法，除了使用Jenkins外，17 Media也有導入CI服務CircleCI。李昀樵表示，該服務與GitHub整合相當完整，可以自動整合GitHub上每個版本所提交的程式碼。此外，每一個更新檔都必須撰寫測試，並通過建置流程，才可以合併至主幹。

同時，結合容器技術，開發者也可以在本地環境建立一個迷你叢集，在上傳程式碼前，可以先在規模非常小的正式環境下先行執行服務，「從本地端就開始把關程式碼品質。」

建立監控機制，把關系統運作狀況

不僅如此，SRE團隊也有24小時的On-Call制度，負責監控系統運作。為了加深數據應用，17 Media也建立一套完整Log監控制度，李昀樵表示，該團隊監控的資料顆粒度非常細緻，「細至追蹤每個函式的呼叫時間」。而SRE團隊也將各項系統的效能表現，制定量化指標，做為系統發布警報的標準，並且透過Slack自動發布警報。他表示，透過布建許多監控工具，SRE團隊可以快速了解基礎架構當前的大致運作狀況，「我們追蹤至少100至200項系統數據。」

例如，如果開發者上傳新版本的程式碼，將會導致資料庫的QPS上升兩倍，SRE團隊就得繼續深入追蹤，「雖然不會導致當前服務當機，但會對資料庫產生相當壓力。」除QPS外，SRE也會追蹤資料庫的延遲時間，一旦延遲時間從1ms飆升至5ms，「這就是非常嚴重的問題」，當下就一定要排除。

而根據事件緊急性，17 Media也將警報分成兩類。最緊急的事件分級為P0，次嚴重的則為P1。當碰上P0等級事件，SRE團隊會緊急將維修工作分派給相關負責人，而當事人必須當下放下手邊的任何工作，立即排除問題，「而P1則是隔天上班日再進行修復。」

手動部署工作拖累開發速度

起初，17 Media的IT架構並沒有導入容器技術，當程式碼開發完成後，工程師得要自行手動打包、上傳。李昀樵表示，如此工作流程有許多痛點。首先，部署工作自動化程度不高，導致出錯機率高。再者，過程非常耗費時間，碰上這些問題，也讓17 Media萌生使用Docker容器技術的想法。

一開始17 Media選用AWS Elastic Beanstalk作為切入點，「其底層就是容器技術」，不過礙於PaaS的僵固性，使用至一定程度時，17 Media開始轉用AWS容器服務ECS。

李昀樵表示，使用Docker容器技術並不會對開發者造成困擾，「由於我們有劃分開發團隊及維運團隊」，即使基礎架構有所異動，程式碼依舊是打包成Docker容器。而使用容器技術的好處，就是可以快速建置多種環境，如半正式、正式環境，「使用容器映像檔，可以快速建立標準化的IT環境。」

同時Docker的可攜性非常高，李昀樵解釋，17 Media的正式環境是使用Linux作業系統，但是開發者在本機的Mac環境，也能建立同樣的環境，讓開發者擁有更多自由，「想要快速讓服務上線，就要減少各IT環境間存在的摩擦力」，而透過容器技術，可以提高各環境一致性，他笑著說，這樣才不會發生「程式碼可以在我電腦上執行」的窘境。

Kubernetes可以加強部署彈性

雖然該公司從2016年就開始使用容器調度工具，不過李昀樵表示，當時是使用AWS ECS的內建調度服務，現在17 Media已準備要導入Kubernetes，「目前非正式環境已經開始使用Kubernetes，因為此技術可以讓IT變得更有彈性」，而李昀樵追求彈性的原因，就是在求快的同時，也能降低風險。他舉例，採用金絲雀部署（Canary Deployment），即使程式碼存在系統臭蟲，部署過程中馬上就可以發現問題，藉以提高開發速度。同時，Kubernetes也讓開發者可以更簡單在本地環境中，複製一個正式環境的鏡像，讓開發環境、正式環境的組態設定更趨於一致。

用Terraform加速基礎架構建置

由於17 Media的IT架構高度仰賴公有雲，IT團隊也必須思考如何更快複製出另外一套半正式、正式環境，「也因此我們也引入了基礎架構即程式碼（Infrastructure as Code）的概念」，李昀樵表示，目前IT團隊使用的工具是由HashiCorp推出的基礎架構工具Terraform，每個雲端環境的組態設定，都有一套專屬的Terraform模板。

Terraform定義了一套標準格式，「而此規範可以描述雲端環境的長相」，李昀樵舉例，假設開發者所需的雲端環境，是由10種相異服務組成，便可透過Terraform定義的語法，撰寫出完整模板。而系統也會自動比對當前基礎架構與新版組態設定的差異，一旦有異動，Terraform也會補齊相關服務。

而Terraform帶來的價值，就是讓開發者可以快速複製一套公有雲環境。他表示，雖然建置AWS ECS環境不會花費過多時間，但加上周邊配置如MySQL、AWS RDS、負載平衡器、CDN的建置，至少會花上一至兩周，不僅如此，手動點選公有雲組態設定，往往會發生許多錯誤，「在導入Terraform後，開發者只要開啟所需要的模板，系統便可自動建置基礎架構環境。」

支付高額公有雲成本保障服務品質

而17 Media大量使用者帶來的流量，對基礎架構也是一大考驗。不過李昀樵表示，導入容器技術的助益有限，「流量仍得靠擴大基礎架構規模解決」，雖然容器可以更精細地劃分運算資源，提高使用效率，但它仍仰賴VM作為容器主機，只要VM數量不變，就無法有效排解流量。目前，17 Media基礎架構的CPU使用率維持在30至50％，「寧願讓運算資源閒置，也不要提高風險」，由於17 Media面對觀看直播的一線使用者，「我們要不計代價提供穩定服務」，李昀樵表示，只為維持基礎架構穩定運作，光是1個月的公雲基礎架構費用，就得支出高達數萬美元的成本。不過即便如此，在降低費用與維持服務品質的抉擇，李昀樵也會毫不猶豫地選擇後者。

他笑說，比起廣告費用，其實投資基礎架構較為便宜，而且更直接影響使用者滿意度。他表示，以工程師角度出發，多數人的技術決策，多半選擇當系統負載率飆高至一定程度後，才進行水平擴充，「但以商業角度考量，無疑都是增加營運風險」，只要知名直播主上線，就會對系統帶來非常大的壓力，即使緊急水平擴充也無法分散流量壓力。

導入敏捷開發，新功能兩周就上線

不只引入新技術、新工具，在2015年時，17 Media內部就已經導入敏捷團隊，以兩周為單一循環進行開發，目前該公司已經有3至4個敏捷團隊同步運作。首先，產品經理規畫工作目標後，開發者再根據其計畫，估算兩周內可以完成的進度。而一個敏捷團隊的除了產品負責人、敏捷教練外，同時，Android、iOS開發者也會一同介入。李昀樵表示，當中17 Media也嘗試過1周、2周、3周的周期，最後才挑選至2周作為一個循環。他解釋，如果敏捷開發周期拉得越長，就會趨近於傳統瀑布式開發，開發工作可能更有效率，但是上市速度就慢。由於直播產業相當競爭，一旦觀察到任何使用者需求改變，新功能就必須馬上上線。

大膽擁抱新技術維持競爭力

成立不滿3年的17 Media，其擁有最大優勢就是「沒有老舊包袱」，現今各項IT新技術蓬勃發展下，也可直接擁抱最新觀念，「不過我們也耗費多時，才找到屬於自己的模式。」李昀樵表示，未來17 Media也會朝多媒體平臺發展，除了直播主自行產製內容的UGC模式外，該公司亦開始著手開發自製內容，「但回歸源頭，這些決策都是要維持17 Media的競爭力。」

 CTO小檔案 

李昀樵

17 Media資深產品科技副總裁

學歷：臺灣大學電信工程學研究所

經歷：在2012年至2014年建立新創公司SMD Lab.，在進入17 Media後先任職後端團隊，而現在則為17 Media資深產品科技副總裁，帶領近百人團隊規畫技術決策及開發新產品，現在17 Media的IT架構也全面使用公有雲容器服務

17 Media

● 成立時間：2015年

● 主要業務：開發直播App，讓領域名人、網路紅人與素人進行直播或錄製節目

● 總部：臺北

● 員工數：350人

● 資本額：3億5,450萬元

● 創辦人：黃立成

● 執行長：潘杰賢

● 2015年7月：17 Media成立

● 2015年7月：17 Media App正式上架

● 2015年9月：App在中國、美國App Store熱門排行榜上排名第一

● 2015年10月：成立SkyEye團隊專職監控直播，避免出現不當內容

● 2016年12月：新加坡交友平臺Paktor入資17 Media

● 2017年5月：M17 Entertainment集團正式成立

● 2017年7月：17 Media香港分公司成立

● 2017年9月：17 Media日本分公司成立

● 2017年12月：提供用戶以比特幣及以太幣支付即時互動內容