靠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環境間存在的摩擦力」，而透過容器技術，可以提高各環境一致性，他笑著說，這樣才不會發生「程式碼可以在我電腦上執行」的窘境。
![]()
（攝影／洪政偉）
想要快速讓服務上線，就要提高環境一致性，減少各IT環境間存在的摩擦力。── 17 Media資深產品科技副總裁 李昀樵
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的競爭力。」
● 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月：提供用戶以比特幣及以太幣支付即時互動內容
%E6%9D%8E%E6%98%80%E6%A8%B5_6_%E6%B4%AA%E6%94%BF%E5%81%89%E6%94%9D.jpg)
