為美好的數據獻上祝福！

  「那你現在算全端了嗎？」  「不不，還差得遠！😅」  # 前言  在應用系統開發實務上，就算你把前端刻得出來、後端 API 也設計得有模有樣，頂多只是做出了一個「能動的東西」。但「能動」跟「能活」，是兩件差很多的事。  一個能活的系統，需要有人（或者一套機制）負責讓它在對的環境裡跑起來、確保它跑歪了有人知道、更新它的時候不會順便把什麼東西搞壞、以及保護它不被奇奇怪怪的人亂戳。  這些，就是本篇文章要聊的後半場課題：DevOps、資訊安全、系統分析與設計、還有系統整合。    # DevOps  在開始接觸 DevOps 之前，我對它的理解大概是：「寫個 script 讓程式自己更新，這樣就不用手動了。」這個理解沒有大錯，但它只抓到了 DevOps 的皮，沒有抓到骨。  DevOps 的核心其實是一個問題的解答：「開發者做出來的東西，怎麼讓它穩定、可重複地到達使用者手上，而且出了問題能夠快速恢復？」  這個問題的背後，牽涉到的不只是 CI/CD pipeline 的設定，而是整個開發、測試、部署、監控的流程設計。乍聽之下很簡單，但當你開始細想，就會發現問題一個接著一個冒出來：  新版模型訓練完之後，怎麼確認它比舊版好再換上去？  如果新版上線之後發現結果不對，怎麼快速退版？  模型更新的過程中，服務要繼續提供預測還是先暫停？  這整個流程有沒有日誌記錄？  有沒有人在監控這些日誌？  每一個問題，都指向一個需要設計的環節，而不只是寫一段程式碼就能解決的事。一直到我在業界當中，實際參與應用佈署流程，親自接觸 GitLab + Harbor + Rancher + Argo CD 等 Kubernetes  生態系工具來實作 DevOps，才更加深刻地體認到 DevOps 當中「可重現的環境」這個概念的重要性。    # 跨越 Windows / Linux 的系統鴻溝 大多數資料科學家的日常開發環境是 Windows、公司配的筆電是 Windows，Excel 是 Windows，連 Jupyter Notebook 大概也是在 Windows 上跑的。一切都很和平，直...

  「模型開發完了，然後呢……？」 # 前言 在本系列的第一篇文章，我摘要了「從單點應用邁向整體系統」這個過程當中，各種歷歷在目的難題 你的常識不是你的常識 。從第二篇文章開始，就分別從幾個不同的技術層面，漫談的蛻變過程 不能只有我痛苦。 # 現實的前後包夾 為了讓我們絞盡腦汁開發出來的模型能夠真正派上用場，無論是專案早期要做個POC呈現、還是專案中後期真正的系統整合，自然會有一系列的前後端工程出現在隊伍裡面。到這邊為止，我們都知道，得有人去做這件事，要馬是公司的專門的IT單位、或者外包的資訊服務商、或者是我們自己來。 「出來混，遲早要還的」，以台灣的業界實況，我相信是模型開發人員被要求身兼前後端工程師（或者反過來，前後端工程師被要求身兼資料分析跟AI開發人員）的情況，應該比較普及，也才會有這一系列懺悔文XD這邊也沒有要談技術細節，而是我自己開始慢慢把守備範圍往前後端擴張的心得。 #「過度類比」的路徑依賴 這是作為一名統計與商業分析背景的資料科學家，在嘗試跨足前後端開發時時最容易踩的陷阱。因為我們習慣建立模型，習慣用一套已知的框架去解釋新的現象，所以當我們碰到一個陌生的技術概念時，很容易會說「啊！這個就像統計裡的 XXX 一樣嘛！」，然後在一個『不完全成立』的類比上繼續往下推論…… 資料庫的 index 跟統計的 index 不一樣、API 的 request/response 跟函數的 input/output 不完全一樣、前端的 state management 跟統計模型的 parameter 不一樣。這種『我以為是這樣，但不是這樣』的狀態很危險，因為它讓你在一個錯誤的基礎上繼續建構，而且很難察覺路已經慢慢偏掉了。 # 團隊合作精神 除此之外，為了能夠將模型端的玩意，能夠更順暢的與前後端串聯，也自然而然會開始去思考模型預測成效以外的事情。例如：從資料庫讀取資料進行訓練或推論的時候，為了節省運算資源，最好別暴力地將整張資料表讀進去，而是讀取我們需要的資料範圍就好。 又例如：為了讓預測結果能夠更方便地讓使用者做各種進階查詢應用，我們得將預測結果做更多地後處理。 再例如：每一次模型的預測結果圖片，為了降低前端負載，我們得想方設法找到一個使用者可以接受，但又不會讓前端超重的圖片格式與大小。種種案例族繁不及備載。 說到底，其實都是十分講求跨團隊合作與工程配合的事...