2024 Appier 暑期實習心得 ·

面試
#

有關於 Appier 的面試過程
可以參考

總結來說，看完 Intern 的組成
只能說在大二升大三拿到 Appier 暑期實習的機會真的很幸運 !

關於暑期實習計劃
#

為什麼說是暑期實習「計畫」呢？

在我實習的第一天
剛好有舉辦一個聚集所有暑期實習的培訓
和後續與暑期實習有關的所有活動都是用「Summer Internship Program」來稱呼
今年是 Appier 的第 3 年暑期實習計畫

暑期實習計劃本身以活動來說主要分為 3 個部分

培訓 (Orientation Training)
專案本身
專案分享

培訓 (Orientation Training)
#

雖然說是培訓
但其實算是一個很輕鬆的活動
也剛好辦在我實習的第一天

Orientation Snack — 當天還有 KOBE SWEETS 神戶果実的蛋糕跟**再睡五分鐘**的飲料

主要介紹暑期實習計劃的主要活動
歷年的申請狀況 ( 今年好像有 600 多位申請 )
公司的文化
各個 Intern 自我介紹
最後放時間讓大家自由交流

Intern 的組成
#

當天大概有 15 位暑期 Intern
聽完大家的自我介紹後
粗略統計有約 10 來個都是 NTU or 要出國讀 or 在國外讀回台灣的學生
也有準備要去念 MIT 的高中升大學生 @jieruei Orz

當天蠻好笑的是
幾乎每個人都有認識的朋友在這次的暑期實習
像我跟 @m4xshen 是高中同學
@vax-r 算是在成大 GDSC 認識的
然後又有很多人說也跟另外一位 Intern 認識
聽到蠻多是之前在 AppWorks Camp 互相認識的 ~
讓 600 多取 15 的機率變得感覺好像不是那麼低了 XD

Onboarding
#

我其實是在 7 月第二個週才開始實習的

5 6 月左右 HR 有連絡我問可不可以延後一週開始
原本是在 7 月第一週開始
主要因為第一週有太多人要 Onboard
所以希望能夠分散一下
因為我暑期實習的時間相對完整 ( 是到 9 月的第一個星期正式結束 )
有蠻多 Intern 都是要在 8 月中就結束了

第一個星期都在等相關的權限申請
所以都在看內部有關 Data Engineering 的文件
也正常參加 Team 上的 Meeting
看一下現有的 Codebase

專案本身
#

每個 Intern 都是在不同部門的專案上
所以大家做的專案都不太一樣
蠻看該部門當時的需求

而我是在 Data Platform 部門擔任 Backend Intern
專案可以理解為「Operation Dashboard」
這個 Dashboard 不是 Grafana 或是 Kibana 這種 Monitoring Dashboard

而是一個 Data Platform 部門給上、下游相關部門使用的 Web Dashboard
供與 Appier 的 OAuth Authentication 和內部的 Authorization 整合
提供相關部門在有權限的情況下能夠

改 Data Platform 相對應的 Config: 如 XX Team 的 Dev Role 當前 Worker 數量
查看 Data Platform 的狀態: 目前有哪些 Dataset，並提供相對應的 filter
自動化 Operation Task: 原本需要對 Data Team 開 Ticket 的操作，現在可以在 Dashboard 上直接操作
也會對以上的操作保留相對應的 Audit Log 紀錄

解決的問題
#

主要解決如下所提的情境

XX Team 的 oncall 發現需要緊急增加 Worker 數量

原本還是需要聯絡 Data Team 來改 Config 處理
- 如果 Data Team 沒有人注意到，可能會造成 XX Team 的服務中斷
現在可以直接在 Dashboard 上操作，不用透過 Data Team 才能改 Config
- XX Team 的 oncall 可以直接操作，並且有 Audit Log 紀錄

XX Team 提出 Operation Task

原本需要開 Ticket 給 Data Team 來處理
- 一般來說這種 Task 都是下一段 script 就可以直接解決的
- 但 Data Team 可能有更緊急的 Task 或是在會議中
現在可以直接在 Dashboard 上操作，不用透過 Data Team 才能處理 Task
- 節省雙方的時間成本

技術層面
#

系統架構
#

Operation Dashboard 由 Streamlit 開發的前後端
使用 Postgres 紀錄 User Authorization
並有另外一個 Cronjob 來定時同步 Appier 的 Authorization 關係到 Postgres

還有像前面提到的情境
所以 Operation Dashboard 要能夠 call Kubernetes API 來改 Config
或是 call Data Platform 內部的 API 來呈現狀態

框架選擇
#

之前也有其他 Team 有開發過類似需求的 Dashboard
就是使用 Streamlit 來開發

Streamlit 是一個可以用 Python 寫 Web App 的框架
主要用於呈現 Data Visualization 或是 Machine Learning Model 的結果
( 內建提供很多對 Pandas, Matplotlib, Plotly 的支援 )

可以只透過 Python 來開發，不需要額外的前端知識
剛好 Data Platform 部門沒有前端的人力
所以選擇 Streamlit 來開發

Streamlit Router Framework
#

因為這個 Dashboard 主要被當作前端使用而已
原生 streamlit 提供的 multi-page: st.navigation 功能
都需要直接把一個頁面寫在單一個 Python 檔案裡
以在 IDE 中來 trace code 來說是很不方便的 ( 沒辦法直接按 shift + click 來跳到 definition 的區塊 )

所以刻了基於 st.navigation 的 decorator-based 的 framework
可以讓不同的 Page 寫在同一個 Python 檔案裡
並提供 Router 來註冊不同的 Page
能夠更方便的 trace code
對於常寫 FastAPI 或 Flask 的人來說應該會比較習慣

import streamlit as st
from framework import Router

router = Router(prefix="/dashboard")

@router.page("/config")
def config_page():
    st.write("Config Page")

@router.page("/status")
def status_page():
    st.write("Status Page")

Framework 大概用起來會像這樣

Authentication
#

Authentication 是指一個 User 是否已經登入

因為這個 Dashboard 是要給上、下游相關部門使用的
所以需要整合 Appier 的 OAuth Authentication 和內部的 Authorization

Authentication 就透過 Google OAuth 來實現
不過因為 Streamlit 本身框架實作的限制，只能用內部的 session 來實現已經登入的狀態
不能透過 JWT + HTTP Only 的 Cookie 來實現

Authorization
#

Authorization 是指一個 User 是否有權限執行某個 Action

如果這邊還需要從 0 開始維護一個給所有 Data Platform 相關部門的 Authorization

會增加 Data Platform Team 的維護成本
可能與原本 Appier 內部的 Groups-Users 關係有不一致的地方

至少簡化到只需要讓 Data Platform Team 維護 Groups-Users 與 Action 的對應關係就好
所以會有一個 Cronjob 來定時同步 Appier 的 Groups-Users 關係到 Postgres
而在 Dashboard 上的 Authorization 都會透過這個 Postgres 來判斷是否有權限

erDiagram Group { int group_id PK string group_name } User { int user_id PK string user_name } Action { string action_name PK } Group }o--|| Action : "can do" User }o--|| Action : "can do" Group }o--|| User : "has"

Authorization 在 Postgres 的 ER Diagram 大概會長這樣

專案分享
#

暑期實習計劃最重要的一環就是約半小時的全英文專案分享
( 不過可以用 Google Slides 補一些講稿 )
最後會有 5 分鐘的 Q&A
也都是全英文進行

每個暑期 Intern 都會在實習的最後一週分享自己的專案
幾乎都是 2 位 Intern 一組來分享
所有 Appier 的同事都可以參加這個分享
會在實體的會議室裡進行
有興趣的人可以來會議室或實體參加
主要透過這個機會了解其他部門的維護的服務

Team 與 Mentor
#

Data Platform Team
因為不算 Product Team 所以也沒有前端，都是 Backend、Data Engineer

算有 2 個 Mentor
一個主要 mentor 我暑期實習的專案
還有另一位主要是 mentor 我 refactor API 的專案
( 在最後 #關於長期實習提到的 refactor )

大家都很親切！
都很願意分享 Data Engineering 相關的知識、架構
跟自己的經驗～

辦公環境 & 食物
#

辦公室
辦公室在信義區捷運象山站附近
可以蠻清楚的看到台北 101
有些樓層還有旋轉樓梯可以走上下樓

午餐
因為在辦公室在信義區
午餐能吃到 200 內算超級便宜的 ~
跟 Team 去吃大部分都是去吃百貨公司
有時候也會往市政府的方向去吃小吃類的

( 圖4: Team Building 吃火鍋，吃到開始畫出 Kafka 的架構也是合情合理的 ouo )

辦公室有一整櫃的飲料還有一些些零食
大部分都是小鋁箔包
幾乎每天都會拿一瓶豆漿來喝 XD
偶爾會放一些水果 (有吃過香蕉、藍莓、桃子)
自己吃的時候幾乎都買附近的健康餐盒配辦公室的飲料水果 ~

Happy Hour
每週五下午會有 Happy Hour
可以點下午茶 !
有可能是飲料或是小點心，每次都不太一定
( 有一次是小木屋鬆餅不過剛好當天是 Team Building 沒有吃到超可惜的QQ )

社團
還有一天遇到期中一個社團在中午分享如何調酒
當天就有訂一堆披薩跟韓式炸雞 !

公司文化
#

每個公司都有自己的提倡的文化
Appier 的 core values 是

open-mindedness
direct communications
ambition

在與 Mentor 聊天時也有討論到不同公司的文化
在 Design Review 或 Code Review 也有感覺到是蠻 open-minded 的
Mentor 或主管只會設定一個大方向
剩下所有的技術細節都是自己可以設計、與大家討論的
Team members 也會在 Review 中提供 feedback

技術層面
#

Data Engineering
#

這次最主要新接觸到的是都是 Data Engineering 相關的技術
有太多可以分享了
額外寫在這邊介紹

Infra 與 Dev
#

在 Appier 這邊
自己部門 Application 的 Helm Chart 或是 Grafana Dashboard
或是 Application 會用到的 Infra 如 Postgres、Redis、Kafka 等
都是屬於 Backend 的範圍
並不會有 Infra 來幫忙維護

Infra 是以 Saas 的方式提供如：
有加上許多方便 plugin 的 ArgoCD
還有多個 Kubernetes Cluster 的管理或升級等
或是與 k8s 整合好的 EFK 提供 Log tracing
( 還有很多其他服務，不過目前有接觸到的只有這些 )

跟以前實習/ PT 的公司相比
主要是因為 Appier 的部門比較多
之前的公司也等於一個產品一個部門
部署或 Storage 相關的維護會有專職的 Infra

在 Appier 這邊 Backend 的防守範圍就更大了
要對自己 Application 使用的 Infra 有更多的了解
才能處理 Production Issue 來找 root cause

Infra as Code 實踐
#

在 Appier 有非常多部門
有數十個 kubernetes cluster 或是 Cloud SQL Instance
再加上 VPC、IAM、Secret 等等
這時候不太可能再用手動的方式來維護

在這邊又實際體會到 Infra as Code 的好處
可以 modularize 重複的 resource
並且在 repo 的 Terraform 就應該與實際的 Instance 的狀態一致

當 Cloud Infra 到一定的規模時
IaC 就有存在的必要性

Senior 的角色
#

Review Code
Cost Reduction
Root Cause Analysis
Sprint Planning
Performance Tuning

這些都是發現平常蠻難接觸到
發現與 Senior 的差異

之前只有比較有機會接觸到一些針對 OLTP 的 performance improvement
但這邊有很多針對 OLAP 、streaming 或 batch processing 的 tuning
都是之前都沒有碰過的主題

開發流程
#

Scrum 和 Sprint
#

應該所有部門都是跑 Scrum
並用 Jira 來管理 Sprint

以我目前待的 Data Platform 部門來說
是 2 週一個 Sprint
每個 Sprint 的開頭會有一個 Sprint Planning + Retro
隔週就是 Grooming

每天都會有 Daily Standup
就過一下目前 Ticket 的狀況
不過會有一天作為 No Meeting Day
大家要約會議就盡量避開這天

Design Review 和 Code Review
#

如果目前在做的 feature 或 refactor 需要設計新架構的話
就會有一張 Design 的 Ticket
並且會拉所有人過 Design Review
讓大家確認一下這個 System Design 有沒有什麼淺在的問題
對於未來的 Scalability 有沒有考慮到

我們部門的 Code Review 如果比較大的話
會拉一個 Code Review 的會來請大家幫忙看一下
如果只是小的修正就直接在 Slack @ 幫忙 approve

覺得還蠻新鮮的，以為大家過 PR 都是非同步進行的 ~

GitOps 與 Release
#

每週三都會有 Release Meeting
Service Owner 也會在 Release Note 加上自己的 Service 的更新

因為在 Kubernetes 上透過 ArgoCD 來部署
會在 Meeting 上跟各個 Service Owner 確認相對應的 PR 是否已經 Merge
有沒有要在這週 Release

如果 Release 當下有問題
就馬上 rollback
如果有對外的服務更新
也會在 Slack 上通知 stakeholder

關於長期實習
#

因為在 8 月第ㄧ週就把主要暑期實習的專案完成了
Mentor 也有問我對目前部門的哪一塊有興趣
我覺得要直接進入 Data Engineering 的專項 ( 如: Hive, Spark, Airflow 等 )
還有蠻大的學習成本

想先從部門負責的 API 下手
( 剛好也是使用我算蠻熟習的 FastAPI )
當時因為要進行其他 Tech Stack 的 Migration
就順便把原本是 Flask API 的 legacy codebase
搬遷到 FastAPI 的 monorepo 上
同時也裡用新 Stack 的 feature 來改善原本的 API

剛好我開始暑期實習時
Data Team 原本其中一個長期實習轉正職了 !
所以有 Headcount 可以轉長期實習
在 8 月底選課出來發現剛好星期一、二沒有課 ~
也想把正在 refactor 的 API 搬完
就決定繼續留下來做長期實習了 !