Skip to main contentSkip to footer
Search
LY Corporation Tech Blog

支持 LY Corporation 和 LY Corporation Group (LINE Plus, LINE Taiwan and LINE Vietnam) 服務，宣傳技術和開發文化。

Backend Intern 之旅 ＿ 中央大學資工系企業參訪

前言

大家好，我是 Alpha Dev 的 Evan，今天很高興能來跟大家分享一下在LINE 擔任Backend Enginner Intern 的過程

今天主要分成三個部分跟各位同學介紹：

  1. 我在Alpha Dev 這個部門底下，大概做了些什麼
  2. 我是今年三月進來的到現在11月，大概8個多月，說一下這段期間學習到什麼技能
  3. 最後分享一下，我在LINE實習的生活

Alpha Dev 負責任務

AI Meeting Noter

一開始進到 LINE，我主要負責開發一個 會議記錄系統。
雖然市面上其實已經有很多現成的會議工具，像是 Zoom 或 Notion AI， 但由於大公司內部有一些 法規與資安層面的考量，外部工具沒辦法直接導入 還要經過一些poc等等，
再加上內部一些團隊又希望有一些客製化的功能和需求，要是都外包也不夠彈性 所以評估後還是自行開發一套符合內部規範的解決方案。

這個系統針對音檔的處理主要提供兩種使用方式：

  1. 立即錄音
  2. 上傳錄音檔

為了讓內容產出更彈性，也讓使用者可自行選擇逐字稿呈現方式和會議類型
像會議的話就可以選擇是針對單次會議、週期性會議、甚至演講，提供對應的轉錄摘要邏輯。 另外，在結果產出後，系統會自動將會議摘要用markdown format 形式同步到公司內部的知識庫平台， 讓團隊成員可以隨時查閱，省去手動搬移的工。

Infrastructure

在我實習過程中，除了後端開發，也接觸到一些跟 infra 和 DevOps 相關的東西。簡單跟大家分享一下我實習期間幫忙建置系統服務的流程
整個流程可以大概分成三個部分：

  1. 先利用 Terraform 負責自動化把雲端基礎建設給建立起來
  2. 用 Kubernetes 去實際跑服務
  3. ArgoCD。它會持續監控 GitHub 上面的 Kubernetes YAML，如果偵測到有更新，就會自動同步到 Cluster，做到真正的 GitOps

簡單來說： Terraform 建環境 → Kubernetes 跑服務 → ArgoCD 自動部署、同步狀態。

那大概流程是這樣，再讓我萊一一解說這三個部分：

Terraform

那 Terraform 是什麼呢？
簡單說，他就是可以透過寫code方式就自動化建立一些服務所需的基礎設施。像是VM,、load balance, DNS等等

這種做法叫做IaC, Infrastructure as Code（基礎設施即程式碼），意思是把所有環境設定都用程式碼管理，這樣除了好追蹤、好版控之外，未來部署類似環境時，也可透過相同的配置再次重建 這篇文章是我8月時寫的，主要是在分享怎麼從零開始，用 Terraform 和 GitOps 打造一個自動化的完整應用。大家有興趣可以掃下方 QR Code 看全文。

Kubernetes

這張圖主要在說明，我們的服務是如何部署在 Kubernetes 上的。 首先，我們會撰寫對應的 Kubernetes Manifests，通常會由多個 YAML 檔組成，例如 Deployment、Service、Ingress 等等。這些 YAML 會描述服務的整個生命週期，包括 Pod 要怎麼啟動、服務要如何對外暴露，以及外部流量該如何被路由進來。ReplicaSet 設多少等等

接著，我們會把這些準備好的 Manifests 推送到 GitHub Repository，然後由下一頁會介紹的 ArgoCD 透過 GitOps 流程自動接手，完成整個部署。

另外補充一下，這些 Manifests 不一定只用原生 Kubernetes 來寫。也可使用 Knative 來簡化無狀態服務的部署，讓流量的自動擴增或縮放更容易做到。而在多版本控管上（像 beta、rc、prod），通常會用 Kustomization 來管理不同版本的設定，避免重複寫大量 YAML，使整體部署流程更彈性且更好維護。

ArgoCD

然後 ArgoCD 的部分，就是將ArgoCD去與前面用 terraform 所建好的cluster 和放在github repo上的 k8s manifest 做綁定 之後就可用 ArgoCD 持續監控這個 Git Repo 的 YAML 變化，就可同步套用到 Kubernetes Cluster，自動建立或更新應用程式。 未來若要更新，只要修改 manifest 裡的 YAML，ArgoCD 就會自動幫我們部署。

那這邊也快速介紹一下ArgoCD 的UI
每一個方塊代表一個application,service 或pod之類的，也可以看到系統目前的狀態，目前是 healthy sync的 如果改天壞掉了 也會自己顯示unhealthy 或outofsync 或error之類的

那它也支援 自動回滾（Rollback） 功能， 也就是說如果新的版本有問題，只要一鍵就能退回到上一個版本， 而且所有動作、log 都會被記錄下來，方便追蹤。

那總結一下這整個流程
對工程師來說，這樣做的好處是：部署不再靠人工(像用Terraform的話，就不需要另外學習eg. Aws ,gcp ,azure他們雲端服務商提供的UI介面，也不需要像在學校學aws ec2一樣，要去console手動創建instance 還要設置一堆網路相關的東西）直接透過寫code方式完成，讓一致性更高 更好管理，也方便多人協作。 如果同學們未來對 SRE 或 DevOps 有興趣，這些技術其實就是進入那個領域的必要技能之一

AI Conversation Assistant

那接下來分享一下，目前我在做的專案是一個未來要對外推出的產品 AI Conversation Assistant

蝦米細LINE OA? 就是 LINE 官方帳號 (Official Account)
現在有很多商家都會跟LINE合作，有自己的帳號，像左上角就是大樹藥局的OA
那現有的官方帳號其實還不夠智能，他很死板．問他問題大多不會回應或需要等待真人客服

基於這點，我們現在主要是為現有的 LINE 官方帳號（OA）的管理後台開發出 AI 的功能。 我們的目標是要降低管理者的使用門檻並達到更智慧化

舉個例子：
未來商家可以在 OA 後台拍照上傳菜單或產品資訊
那只要當顧客在問問題時，AI 會自動從後台知識找到答案，生成回覆
同時也能分析顧客對話內容，協助商家更了解客戶需求與營運狀況
目標就是：降低商家管理 OA 的門檻，讓 OA 變得更智慧、更好用。

接著談一下技術面部分：
雖然聽起來很直觀，但要把整套系統做得可用、可上線，其實沒有這麼簡單。
同學可能會覺得：
「不就後面先建個vector DB、資料用chunk形式切一切、塞 embedding、做個 RAG 就好了嗎？」

但真正的難點在於：
檢索精準度要怎麼調到夠好
瞬間的大量訊息要怎麼處理
每一條訊息都要做rag嗎？每次call的Cost也要考量

因為台灣的 LINE 上有 數十萬個 OA 商家，
只要平時大概 5% 的商家同時有顧客在問問題，
流量就已經非常可觀。

所以除了 AI 功能本身，我們後端也花很多心力在架構設計上：
要怎麼穩定接收大量訊息
message queue（MQ）要怎麼設計
訊息要怎麼正確 publish 給各個 consumer
這些都是我們在做的事

Alpha Dev - AI Study Group

除了一堆開發的事情，我們team也有讀書會的習慣，
我們每週都會固定一起分享最新的 AI 技術，像是最近大家很關注的 AI Agent: AP2, A2A protocol, AutoGen、Claude Code 、Gemini 3、還有AI帶來的一些資安議題 最新的OWASP等等。 除了學習新東西之外，我們也會討論這些技術能不能實際落地，例如能不能整合到公司現有的系統、或優化我們的開發流程。 對我來說，這讓我不只是學工具，而是真的去思考「AI 怎麼改變工程實務」。

Learn Skill

Technical Skills

那從三月到現在，我主要接觸了這些東西

  • Backend: Spring Boot Framework/kotlin or Java, Python FastAPI Framework
  • DataBase: PostgreSQL,MongoDB,OpenSearch,Redis
  • DevOps: Jenkins, Github Actions, docker, k8s, Knative,Prometheus,ArgoCD, Grafana, Loki,Terraform

Clean Architecture

還有進來就是要學軟體工程中的design pattern
隨著你專案規模越來越大，如何維持程式碼的可讀性、可維護性與可測試性，就會變得越來越重要。我們深受「The Clean Architecture」的啟發。 這個架構的核心思想是關注點分離與依賴反轉（Dependency Inversion Principle, DIP）

從圖中可以看到

  1. 最內層是Entities，代表企業核心業務邏輯
  2. 往外是Use Cases，負責實現系統的具體功能
  3. 再往外是Interface Adapters，如 Controllers，用來處理將外部的輸入轉換成內部使用的格式。
  4. 最外層則是Frameworks & adapter，負責提供系統與外部世界互動

最重要的原則是：依賴關係永遠由外向內。內層的程式碼，不應該知道任何外層的細節。

Hexagonal Architecture

我一開始會議記錄工具那個專案便是採用 Clean Architecture 中的 Hexagonal Architecture，也稱為「Port and Adapter 架構」。這種設計將核心業務邏輯（Entities）與外部interface徹底解耦，讓系統更容易維護、測試，也更方便替換或擴充不同的輸入與資料來源。

SCRUM

那相信大家在課堂上應該也一直聽到敏捷開發
但一堆專有名詞 書中網路上形容的有些又蠻抽象的
像是什麼站立會議, planning poker 之類 所以想藉這個機會順便跟大家分享一下

我自己之前有聽過planning poker 但那時候查了還是不太懂
因為過去也沒有什麼機會實際跑正式的軟體開發流程
但實際體會過一次 說穿了那其實就是非常簡單的東西

舉planning poker來說：
假如現在要開發一個後端服務，例如實作 Message Queue 的串接

團隊會先定義好幾個點數大小(如1,2,3,5,8,13)通常以費波那契數為主，然後後端開發人員會再根據該服務的複雜度，各自來決定要出哪個點數出去

通常我們會取出大家討論後的共識值，來代表這個任務的 Story Point
Q: 那這點數可以幹嘛？
這些點數加總起來，就能幫助團隊了解這次 Sprint（開發週期）的總工作量
就是為了後續評估專案用的

讓我來快速介紹一下所謂的SCRUM 是什麼，那這張圖可能不是很正式，就是我就簡單畫一下跑SCRUM常見的部分而已

  1. SCRUM: 是一種用固定週期迭代的開發流程，而SCRUM 的所有流程、角色、會議都是圍繞著Sprint這個週期運作的
  2. Sprint: 就是在SCRUM 框架中實際執行開發工作的核心單位，通常都有個迭代週期，通常是1~4週之間，那常見的話會是抓2周左右，那在這段期間團隊會從product backlog中挑出幾個項目，並要在時間內完成開發交付

而Sprint 裡面又可以包含多個component

  1. ticket: 就是backlog item 的實際單位，一張票可以是：user story, Bug, Spike
  2. Daily Scrum (站立會議): 不是真的要站著開會，只是就是每天開簡短的會議 go through 一下整個團隊每位成員的現況，確保進度同步
  3. PBR (Product Baacklog Refinement): 前面提到，每個sprint 大概為期兩週，那當兩週快結束前，就會開PBR，用來確認下一週要做的事有哪些，要在下一個sprint 完成
  4. AC (Acceptence Criteria): 當dev 做完ticket，雖然可能都會自己做個簡單的測試 unit test之類的，但還是需要由ＱＡ來測，那QA 可能就會幫每個story寫一組明確可驗證的條件，用來判斷ticket 是否可通過、被接受，那可能會透過Given, When, Then 方式撰寫
  5. Retro: 回顧會議，每次sprint 快結束時，也會進行反思，看這次為期大概一兩週的sprint是否有哪些地方要調整，可以做的更好的，就會在會議上進行討論

Life as a LINER

左邊是今天6月的畢業分享會結束後的慶功宴
雖然我那時候才來LINE 三個月左右，但還是可以報名上去演講
我就好好把握這個可以站上舞台的經驗跟大家一起啦
我們就是去信義區的餐廳慶功 LINE有給公費讓我們去慶功，結束後再去信義的酒吧喝酒

那熊大那張圖，就是我們每屆的實習生合照 春季+秋季大約都有20人 大家感情都很好

而下方是LINE 內部偶爾會有品酒會，除了喝高檔的威士忌，也會娉請一些主廚來到LINE 現場提供美食，像這張圖是請到一間高級餐廳 叫做嶼我 這間餐酒館的主廚來準備
然後公司二樓也有飛鏢機 遊戲機 隨時累了都可以玩 我們很長一群實習生中午就聚在一起玩
中午也都會一起吃飯，偶爾吃個熱炒之類的

最右邊是LINE 發的紀念品，他是一個具備rfid 的吊飾，裡面還內建100元 真的可以使用
右下方是我跟主管的合照，每位同學進來LINE 都會有一位專屬的主管帶領你，幫助你成長

最後這邊是我的Linkedin 和 IG，有任何問題歡迎詢問
那最後就是歡迎大家來加入LINE啦！

image