[Life Note] - LINE TAIWAN TechPulse 2023

Introduction & 前言

LINE TAIWAN TechPulse 2023

因為疫情關係,繼上次 LINE TAIWAN TechPulse 2020 - LINE 開發者大會結束後,終於又迎來了實體的線下 2023 年的開發者大會,這次消息一出來就趕緊報名了,一起來瞧瞧今年都說了些什麼吧。

這次的開發者大會如果筆者沒記錯,是第八屆,場地這次移動到了 台北市復興南路一段39號微風廣場Breeze,相對之前的 臺北和平籃球館南港展覽館二館 又小了更多,之前 2020 因為疫情的關係場地縮小了,今年不確定是不是因為疫情關係又更小了,這次的大會也沒有會中餐點及會後紀念品,不過該有的技術攤位還是有。

嚴重提醒:本篇也是以筆記及心得為主的文章,如果內容有誤,敬請不吝社指出也請多多海涵,感謝各路大神!另外圖片會有模糊問題因為當天臨時靠手機拍攝,且會傾斜是因為位置為隨機入座,筆者在側邊,還請各位大神見諒。

另外每位講者筆者皆有做一些重點筆記,內容或許不完全正確,如果有誤還很歡迎在下方留言告知,感激不盡。


本次重點

今年報導方式從簡了

每年的開發者大會都會圍繞一些主題,而在會場都會看見相關應用,例如 2019 的 LINE貼文串推薦系統(Timeline Post Recommender System)、2020 的 AI 人臉辨識系統,但今年似乎就…一切從簡,往年都會用一些新技術來消化入場速度,甚至報名都是隨機抽籤,不一定能入場的,今年則是有報有獎,但沒有線上轉播。

我想 LINE 是不是發現搞來搞去傳統的方式最方便?!省時省力又快速

今年一樣分為 上半場下半場,下半場分為 A(在地化技術分享)B(創新技術分享) 兩廳分開進行。

  • LINE台灣公司總經理 - 陳立人(Roger Chen)
  • LINE台灣資深技術總監 - 陳鴻嘉(Marco Chen)
  • 高層主管及員工 介紹 公司目前近況碰到的問題及挑戰解決方式
  • 前端團隊的 Infra 開發介紹 - Colin Lin

-> 簡單給個重點:

  1. LINE這一年的進度及未來展望

  2. 我們碰到什麼問題以及我們如何解決應對的

  3. 介紹 AI 相關的 NLP 模型,以訊息查證為例介紹如何透過訓練模型來精簡文章摘要

  4. 實習生的心路歷程(B廳)

準備好就開始了


報到

今年改為馬上報名馬上有入場資格,入場時也是直接出示手機報名後系統給的序號就可以拿卡片入場。

報名方式

拿著卡片入場後就可以隨機著個位子坐下了,今年的會廳看起來小了不少。

入場卡

再次讚賞這次的人臉辨識入場,現在很多場所都開始類似的裝置了,可能有人會擔心安全問題,下面會在提及。

滿幸運的是活動當天天氣很好,沒有下雨。


上半場

第一位(LINE台灣總經理 - 陳立人(Roger Chen))

Key Note

*今年談論主要著重在 『開發治理』、『資料治理』及『文化養成』 三個面向優化管理系統,加上 標準化前端開發流程、導入 DevOps 思維、DORA 四大指標、優化內部可觀察性技術架構,讓團隊在研發上更敏捷且不失安全性。 - 資料來源可參考 LINE Today 文章*

今年一樣是由 Roger 開場,從 資安、開發、資料處理、27001 27701 資案保證(對外)、遠端開發、零信任架構、工程師提供代碼透過自動化(Smart Test)追蹤確保代碼品質、在資安即安全的保證下保持高效開發,一直到 APIM 、LINE Bank 作為整場會議的序章開幕。


第二位(LINE台灣資深技術總監 - 陳鴻嘉)

Key Note

過程重點提及 資料治理 的重要性,因為 LINE 是擁有廣大使用者的平台,所以資安團隊持續強化 『零信任架構』;實作的方面從 LINE Invoice、LINE Sticker、直播購物(LINE LIVE Commerce Assistant App),甚至這幾年開始火紅的 NFT 相關平台 DOSI,還有前端 Infra 團隊建立出的開發 Flow…等等,先提及了一遍上午會議的重點核心,讓聽眾先能抓到整場會議的脈絡。

DORA

為了應應更龐大的組織架構及使用者,LINE 開始注重在規劃治理的方面,較不同與往年技術為重,結合了 DepOvs 的技術能力,還有透過導入 DORA 四大指標去檢視內部技術主管與產品關係人的開發品質。

  1. Lead time for changes - 改版的前置時間:從原始碼交付到成功上線運行的間隔時間。

  2. Deployment frequency - 部署頻率:在指定時間之內,提交並部署正式上線的Production版本的多寡。

  3. Time to restore service - 服務恢復時間:從災後停機狀態恢復服務所花的平均時間(MTTR)。

  4. Change failure rate – 改版失敗率:藉由計算Production(產出版)部署的成敗比值,測量Production部署失敗發生的頻率並立刻採取補救措施(例如Rollback回溯)。

資料來源 -
DORA DevOps四大關鍵指標和成熟度等級之探討

Marco 上台開始後,與接下來的另為兩位講者 Bryan Lin(DevOps)John Lin(SRE) 穿插式的開始帶入每一項議題的內容。


第三位(DevOps - Bryan Lin)

Bryan

今年因為重點在資料治理的部分,所以由 BryanDevOps 的角度出發,點出開發團隊往往 開發通常會先陷入先開發的問題,程式碼品質相對落後,且依照紙本規範很難讓全體質量統一,所以開發團隊從 **Branch management 的 Flow 管理、Source Code Review、Security Check(使用者資料及安全性)及 Testing strategies…**等等,及導入 CI/CD 方式提升開發品質,確保某些可規範的條件再一致性內。

Difficulties

以往的一些紙本規範難以確保團隊品質一制性。

SonarQube

Bryan 提到他們使用了例如 SonarQube 這個工具,透過 CI/CD 去自動檢測每次的 PR 是否有影響 SEOCode Smell,這些都能統整出一個分數,再加上可視化的 DashBoard,讓分數來當一個準則評判這次的改動是否是 符合效益有淺在的危機

PR Check

CI/CD 的部分,透過工具輔助可以大大淺少人工審核的成本及失誤,也可以提昇整體團隊的開發一制性。

Coverage

最後 Bryan 也有提到,他們並非是一系之間導入所有的測試或者規範,在初期他們都是 先求有再求好,但此先求有非彼先求有,多數專案開發時,都會被 PM老闆 要求先有東西後面再來改,LINE 團隊的有則是先能覆蓋大範圍的測試目標,確保團隊在統一基準上,再慢慢補齊小範圍的測試,在 A/B Testing 的幫助下,團隊至少都能保持在一定的水準之上,畢竟人們常說的,數據數字會說話。

Bryan 也提到團隊文化很重要,好還要更好,才能使程式碼品質卓越。

筆者重點小筆記:可觀測性工程文化、八條依據 十五條準則、往往開發通常會先陷入先開發,但品質相對落後,依照紙本規範很難讓全體質量統一,所以需要依靠 CICD、準則舉例 Branch management 即 Source Code Review 要求你只需要符合規範 不在意你怎麼做、先要求有再求好、Security Check(使用者資料及安全性)、Testing strategies 儘量在 Pull request 自動跑完所有測試、Task for release AB Testing、做到卓越不比做到菁英困難


第四位(SRE - John Lin)

John

前部分 Bryan 著重在開發的流程部分,而 John 則著重在操作的部分,前面有提到 LINE 團隊將各種數據做成可視化的 DashBoard,方便開發者觀測,

Monitoring to Observability

透過可觀測性的平台,讓開發者直接一眼明瞭目前的各個專案狀況如何,也利於 Outage handling

Outage Process

透過有效的觀測平台搭配上錯誤的處理流程,可以快速的 Handle 意外的發生,使用者應該也不會想要在某天使用 LINE 的時候,發生意外錯誤,而且這個錯誤修復必須要大半天吧(對於每一個產品都是這樣的)?

Governance Flow

最後由 LINE台灣資深技術總監 - 陳鴻嘉 透過一張 LINE 目前 Data Governance 架構圖為 DevOps 的章節作為一個 Ending

筆者重點小筆記:Monitoring、應用指標實作進系統、必須清楚定義目標以得到告警、IMON2、remote-writing、Prometheus 改進、Outage Handling、開發人員必須要互有聯絡方式,發現問題能清楚定位問題點 MTTR、介紹故障的處理流程


第五位(Data Dev - Shawn Tsai)

AI

每年都不免俗的要談到關於 AI 的部分,在 技術總監 - 陳鴻嘉 的一張投影片結束之後由下一位講者 Shawn 開始相關介紹。

接下來兩位講者皆是前幾年也會出席的資料工程團隊成員

NLP

NLP 2

在 AI 方面工程團隊則以三大要素,Data(資料)、NLP Models(自然語言處理模型)、Service Integration(服務整合)建構出 NLP(自然語言處理 賦能的應用。每個服務皆有各自的 NLP Tasks(自然語言處理任務需求),而有些任務的需求共通,為了更有效率地使用 NLP Models,且可通用於 LINE 旗下不同的服務領域,工程團隊提出「自然語言處理即服務」(NLPaaS)的概念,將自然語言處理(NLP)賦能應用的建構流程標準化,快速建構出不同的NLP Models,加速自然語言的處理,因此研發出「SmartText自然語言處理平台」。 - 重點節錄至 LINE Today 文章 LINE TAIWAN TECHPULSE 2023 年度開發者大會重磅登場

LINE 研發的 SmartText 2.01.0 的進階版,初版 SmartText 自然語言處理平台可透過模型進行例如 文件分類(Classifier)、多標籤分類(Multi-label Classifier)、主題偵測(Topic Detection)…等等,經過 2.0 的優化,平台計畫可執行更多元的 NLP 任務,包括 文章摘要、換句話說、問答、客製化廣告文案生成…等等。

上面聽起來很複雜,舉個會議上的實際例子來說,圖隊他們必須在一些訊息上進行審核,從原本的需要一個一個人工審核,在 smartText 1.0 時可以利用模型的幫忙,進行 文章分類(Classifier),在對文章內容做 多標籤分類(Multi-label Classifier),最後給予文章相對應的 Hash 標籤(Topic Detection),接著在 SmartText 2.0 的優化之後加上視覺化平台 Smart Text NLPaas 的操作下,可以快速的對文章進行摘要分析,甚至在客服對話時,能夠在 NLP Tasks(自然語言處理任務需求)的目標上,快速回應對方他期待的答覆,協助處理各種文字自動化複雜需求。

How we build it

而團隊如何做到就是接下來第六位講者會帶到的部分

筆者重點小筆記:Text is everywhere、特定服務領域 與 NLP 模型、需要 資料 模型 獨特領域資料 包裝應用 整合應用 太麻煩了 所以中間三項改為 準備適當材料(node code)、適當分類有助於快速找到該領域的專家去審查是否描述適當、先讓標籤審核過濾,方便小編快速篩選文章、透過 Hash Tag 快速分類,作為使用者搜尋的推薦、長篇文章透過文章摘要來作為訓練模型,以 Api 形式提供給內部使用、透過換句話說讓 AI 機器人可以知道如何提供使用者多個相關選擇、透過問與答來訓練某個特定領域的知識


第六位(Data Dev - Penny Sun)

Penny Sun

Penny 也是在之前大會上出席過的講者,由她來介紹這整個過程是如何運作,以及該 NLP 未來的發展方向。

NLP Pipeline

透過這張圖 Penny 讓大家快速了解 NLP 是如何運作,在基本的三個步驟 Data Preparation(資料準備)、Modeling(Mode 準備) 及 Evaluation(資料分析),搭配自動化工具,完成一整個 NLP Tasks(自然語言處理任務需求)

Beyond NLP

NLP Evolution process

最後在 Beyond NLP 的投影片之後,Penny 請我們想像並且向我們講解接下來的 NLP 發展。

NLP Life

從起床透過文字需求請模型分析出今天的新聞文章摘要出來,到上班分享簡報時的文章重點分類,然後下午接到朋友傳來的訊息,透過應該回應的文字去搜尋圖片,透過圖片回應,最後回家請模型及語音播放,閱讀童書給小孩子聽。

筆者重點小筆記:介紹如何透過 NPL 查證訊息、舉例用 LINE 訊息查證為需求,透過使用分類器去訓練 NLP 模型,餵入資料,之後其他服務也可以使用 分類器 模型、之後把服務包成 API 也轉成 UI 介面,讓非工程師也能使用、避免 Garbage in garbage,打造 UI、Smart Text 1.0 -> Beyond NLP

Next 10 Year Reboot

最後一樣由 Marco(陳鴻嘉)來做一個結尾,這將是接下來 LINE 的 10 年展望。

AI & Web3

當然一定脫離不了 AI 的主題,不過還多了 Web3 的部分,筆者自己私心認為, Web3 的部分應該不會佔那麼重,甚至未來不會是重點也有可能,畢竟台灣這邊也是輔助開發 DOSI,在 Web3 的方面還是有許多需要克服的技術及現實層面問題(就舉最簡單的 中心化 及 去中心化 問題,詳細這邊不討論),不過總結還是讓人非常期待依 LINE 的技術 Web3 會搞出什麼火花。


第七位(LINE Bank 資訊長 - Leo Weng)

Leo Weng

Leo 主要介紹關於 LINE Bank 的生態系介紹,我們的生活食衣住行育樂,一定透脫離不了錢的部分,支付就是這一切的核心。

LINE Bank Ecosystem

在這部分 LINE 也是出了很多關於 LINE BankAPI,對於 B2BB2C 都是很好利用的一個功能。

LINE Bank APIM

這邊 Leo 也介紹了一些使用 LINE API 的業者,還有介紹如何輕鬆串接 LINE Bank 的功能。

筆者重點小筆記:LINE Bank、經融生態圈願景(中心為 LINE Bank 周圍為許多產品)、實現技術策略(Internal 及 External,分為 B2B 及 B2C)、API 管理系統(APIM、各種銀行的 API 管理)、LINE 開發及串接介紹(內外部使用者都可以透過 APIM)

Next 10 years

最後一樣有接下來 10 年的展望


第八位(LINE Infra Team - Colin Lin)

Colin

這位講者要講的主題一直是筆者很有興趣的,主要筆者專注於前端,但對於前端規範及統籌一直覺得資源來的不如後端多,所以一直很期待這個部分。

Single Repo Monolith

以前端的架構來說,前後端分離或許可以說是近幾年才開始流行的,所幸筆者剛加入前端行列的時候,業界已經開始吹起前後端分離的號角,但由於前端不管技術再怎麼玩,最終都還是需要回歸到 網頁三寶(HTML、JS、CSS),在大部分情況,我們都只需要將 HTML 放上機器,透過渲染到網頁的方式就可以看到內容,我們也不需要單獨去租一台伺服器放前端的專案,所以大部分公司都做法都還是前端有把畫面切出來就好,甚至有的不管你用什麼技術,反正最後丟上去,能顯示就好(這邊先不討論公司政策或者團隊文化),相對在開發規範上不如後端來的嚴謹。

在前端分離出來後,漸漸的大部分公司都開始使用需要會框架去作為新人的門檻,而框架專案的管理及檔案規模,又不如普通網頁三寶來得小,所以很快的大部分公司都是每個不同前端專案分開管理,好處是各自管理,互不相干,不會因為別人的修正改動而出錯,你只需要跟負責你專案的團隊一起處理問題就好。

但,專案一但龐大了呢?又或者,公司業務量暴增,越來越多專案了呢?

Monorepo

所以之後又有了 PolyrepoMonorepo,這個概念適用於前端也適用於後端,總的來署都是為了要解決維護困難的問題,最近漸漸的越來越多團隊開始改用 Monorepo 了,真的是合久必分分久必合呢。

Detecting Affected

由於專案自動化建置可以省下不少時間成本,所以 LINE Infra 團隊也定義出一連串的部署過程,包括中間的 Unit TestE2E TestSonarQube…等等。

Nx

Colin 也指出團隊利用 Nx,來作為分析工具使用。

不曉得 SonarQube 是什麼的朋友,推薦可以看一下筆者的另一篇文章 [Tool Note] - 讓 SonarQube 成為你的糞 Code 守門員

筆者重點小筆記: 如何有效管理管理眾多 API、有限人力獲得最大化開發、從單一 Repo 改到 Polyrepo,最後改為 Monorepo、NX 開發使用介紹


中場休息

Lunch

很快到了中午的休息時間,今年並沒有中場活動,所以筆者就出去晃晃順便醒醒腦,這邊推薦一下會場附近的一間拉麵店,博多幸龍拉麵

筆者重點小筆記:點餐後拉麵要等滿久的,位子及空間很小,但整體價位份量 Ok


下半場

2023

下半場筆者挑了 B廳,主要筆者對於實際應用比較有興趣。

Flex 開發者 - 戴均民

Flex Bot

第一位講者是戴均民,開發了一個幫助開發者的機器人,以往我們需要得知使用者傳送過來是什麼,可能需要實際在街上 webhook 後,在後端 logLINE 那邊的一些接收回應格式,透過這個機器人可以方便的得知一些資訊。

Flex Bot

透過這些預期會接收到的資訊格式,方便使用者可以更快速的開發,另外機器人也適用於群組內,講者說了一個非常方便的情境,將 androidipad 還有 Web 端的三方用戶拉近群組,透過預期會傳送的模板程式碼內容傳遞出去,可以馬上知道三個裝置接收到的展示差異。

關於講者 FLex 的簡報有興趣可以參考此處

筆者重點小筆記:Flex 開發人員工具,透過機器人回傳 Event 的 Json


As an Engineers, let’s build the CRM system via LINE Official Account 2.0 - Caesar Chi

Caesar Chi

第二位講者則是介紹關於 CRM 的一些串接實作內容、透過 LiffLINE OA 實作出 CRMRocket Chat 訊息傳輸還有轉拋功能、 n8n 及 **zendesk**。

訊息轉拋

內容並不是太創新的應用,但過程內容非常扎實,介紹如何透過 Rocket Chat 去做到轉拋客戶給另一位客服的功能,甚至不需要自己 Coding 就能創建出 CRM

Caesar Chi Profile

有興趣的讀者可以關注一下這個講者

筆者重點小筆記:ORM 系統打造介紹、LINE OA 介紹、Messaging API 及 Liff 整合、Rocket chat(ORM 讓非工程人員可以方便上手)、轉拋的問題(Middleware)N8N


Mini-app - Alan Peng

Alan

第三位講者主要提及關於 Mini-appLiff 的差異,還有說明一下目前 Mini-app 的申請模式為推薦制,所以也不是想使用就可以使用,不過未來如果開放使用,確實會像是加強版的 LIFF,其中可以透過 Service Message 回覆制定過的格式訊息給用戶,不過會有數量上限及格式必須先通過 LINE 審核就是了。

Mini App 才有的

這是 Mini-app 才有的功能。

Mini App 申請

申請必須經過層層審核,相關的 Reply Message 也是必須經過 LINE 審核,並無法像 LINE OA 後台制定好就可以。

Mini App 聯繫

雖然目前為申請制,不過如果有興趣還是可以透過掃描 QRCode 去聯繫相關的人員。

筆者重點小筆記:Mini-app、回顧,上線案例,常見問題、Mini-app 與 Liff 差異,都是基於 Liff 框架做出來的,mini-app 可以整合 LINE 內部服務(In-line Search, pin to home page, service message 不可客製化 推播有限制)、mini-app 需透過內部審核才能發佈、目前台灣為邀請制、message template 為下拉式、mini-app 可以不需要透過要求先加入官方帳號 快速與 Line Official Account 整合


Approach to New Year’s traffic of LINE Sticker - Koji Lin

Koji

這位講者主要透過過年大家會傳送大量貼圖碰到的問題,導出他們如何在活動開始事先防範,以及活動進行中的應對,還有發生緊急問題的處理方式,也是落實前面提到的 開發治理

成長率評判

在活動開始前透過之前的 API 使用情況,來推論某個時間點或者尖峰時段,會需要能接受多少的壓力,即使之前沒有相同的 API,也可以找類似相關的 API 來判斷。

正式環境測試

另外他們也會在上線前找來相關的人員(LINE 的各個功能由不同的團隊負責),主要找重要的 API 而非全部,例如發送貼圖的時候需要用到 LINE Message 團隊的 API,他們會把相關的人員找來模擬一次流程。

監控

活動開始後避免不了重要崗位的工程師 on call 之外,也使用 Monitor 來快速瀏覽目前重點機器狀況。

筆者重點小筆記:貼圖流量的控制與預防、新年的貼圖活動(日本新年抽籤舉例)會碰到流量問題,自己 Team 的流量與其他 Team API 流量控制、拆開馬上所需要知道改變的 API 請求 與 不需要馬上知道的 API 解決流量過高問題、貼圖有創作者使用與一般使用者使用、透過往年的流量去估出接下來可能的流量,如果沒有往年紀錄,就用類似的 Service 去預估、伺服器 CPU 抓 70%、On call team 處理突然的流量問題、模擬高峰關 API 會發生什麼事情,用一個 work shop 叫各 Team 人員來模擬。


LINE Today A/B Testing - Wilson Wang

Wilson

Wilson 則是講到了他們如何透過 A/B Testing 來自動推薦相關的內容給 LINE Today 的使用者,過程包含使用者常點擊的區域、查看內容的喜好…等等,於幾年前的會議 LINE 講者也有提到類似的內容,今年也算是看到功能更完善了。

Testing Cycle

How JS task-force improve the quality of projects in LINE Taiwan - Tom Wu

Tom Wu

Tom 介紹了他們為了 Test 打造的一系列功能,Integration TestUnit TestEnd-to-end test

JS Task Monitoring

當然也免不了監控,透過上線前的各種 Test,可以有效的評估出你的程式碼是否夠完善,有了這些數字的輔助,你可信心指數會更高,而且內容也提及,切勿重複 Test 你的 Code,需要重點測試。

LightHouse

透過分數能更明確知道自己的該次 PR 異動是對專案有所提升還是下降,也能比較優跟劣兩者差異是為什麼,另外這個過程也可以避免掉需要定義出一個硬邦邦又可能不準確的規範,例如我們的標準就是 60 分,透過每次分數不同高低的差異分析,才能更明確知道問題所在。

筆者重點小筆記:Test 打造統一的 Test guild line、最少的 Code 打造最高的信心指數、不要重複 Test 你的 Code、先用 Integration test 大範圍覆蓋測試產品,在用 Unit Test 測試一些重點 performance,需要定義出這些 Code 的重點、利用 SonarQube 去測試覆蓋率、Grafana 測試 pull request 的覆蓋率及 code small、串接 LighhouseCI去測試、測試 NPM 的 Security,使用 Renovate 去測試你的 dependencies 是否有問題,使用 SonarQube 做靜態掃描,使用ZAP動態把你的網站起起來後去攻擊的你網站,尋找並發現缺陷。


SwiftUI - Jason Liang

Jason

在最後四位新星計畫開發者介紹他們的產品前,最後由 Jason 帶來他們如何透過 SwiftUI 去打造直播購物的介面。

Skills

接著他們就在一張很屌的我們用了一堆技術的圖片下結束公司技術分享。


LINE ProtoStar

ProtoStar

產品名稱 說明
CARE724 看護保母照護預約
自由食間 無人商店 透過 LINE Pay 或信用卡結帳
PackAge+配客嘉 可回收性宅配包裹外包裝,透過 LINE 掃描歸還包裝
TWODAT 美甲美睫預約

有興趣都可以參考 LINE Today 的詳細簡短介紹

整體這些創新的應用都脫離不了 LINE Message 及 LINE Pay 的部分,不過還是滿開心能看到有這麼多應用的。


Conclusion & 結論

上次參加是 2020,在 2019 第一次參加的時候最期待的部分就是新創團隊的分享,隔年沒有新創的分享,但是今年又回來了,其實滿開心的,整體聽下來第一個反應是今年似乎沒什麼改變呢?有點像 Apple 的發表會,我們的裝置快今年又更快的概念,但仔細想想,一間公司規模越來越大,該專注地也許已經不是新的產品或者技術突破,還是有許多的部分需要好好審視一番,像是技術債。

ProtoStar

不過今年整體而言還是讓我感覺好像是倉促準備的感覺,又或者 LINE 意識到以往舉辦的規模太大了?好像很多東西都逐年在縮減縮小,連最後的結尾也是一張回饋表的 QRCode,讓我頓時間產生,蛤?已經結束了嗎的感覺(但整體還是很棒的)。

今年無法用紀念品來結尾了,不過還是滿期待明年的開發者大會又會有什麼內容。


參考網站