「那你現在算全端了嗎？」
「不不，還差得遠！😅」
「不不，還差得遠！😅」
# 前言
在應用系統開發實務上，就算你把前端刻得出來、後端 API 也設計得有模有樣，頂多只是做出了一個「能動的東西」。但「能動」跟「能活」，是兩件差很多的事。
一個能活的系統，需要有人（或者一套機制）負責讓它在對的環境裡跑起來、確保它跑歪了有人知道、更新它的時候不會順便把什麼東西搞壞、以及保護它不被奇奇怪怪的人亂戳。
這些，就是本篇文章要聊的後半場課題：DevOps、資訊安全、系統分析與設計、還有系統整合。
# DevOps
在開始接觸 DevOps 之前，我對它的理解大概是：「寫個 script 讓程式自己更新，這樣就不用手動了。」這個理解沒有大錯，但它只抓到了 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 上跑的。一切都很和平，直到你需要把服務部署到伺服器上...... 只要你在台灣的製造業或者傳統企業 IT 環境裡工作過，絕對有高度共鳴的痛處之一。
換行符號、檔案權限、套件管理、系統依賴...... 各種雷還有坑，族繁不及備載。而要把這個主題要單獨拉出來講，也不太對。因為綜合本篇以及前兩篇文章所提到的前後端工程、網路工程、DevOps、資訊安全等等，皆可以跟這個主題有所關聯，然後再次觸及到「到底要還要學到多廣、多深才夠用？」這個命題。
所幸，這些坑不是一天兩天才有的。在過去數十年來，在那個 AI 還不普的年代，就已經有諸多前輩烈士留下了許多避雷指南，讓我們後人有機會乘涼🙏剩下的，是我們自己願不願意去找到那顆能夠乘涼的樹。
# 資安
說到資安，這大概是資料科學家最容易有「那是 IT 部門的事」的錯覺的一個領域。
在許多非 IT 人員的認知當中，資安就是防火牆、防毒軟體、還有那個每季都要重設一次的密碼政策，以及其他可能讓人感到不方便的各項政策。但實際上當然不是只有如此。
幾個對資料科學家來說最直接相關的面向是這些：
# 尾聲
「那麼，資料科學的底子，有沒有幫上什麼忙？」
「有，而且是關鍵時刻才看得出來的那種幫忙。」
在 DevOps 的場景裡，對模型效能指標的敏感度，讓我在設計監控機制時，很自然地會想到要追蹤的不只是系統層面的指標（response time、error rate），還有業務層面的指標（預測誤差有沒有在這次部署之後悄悄變大？）。這個視角，純粹的 DevOps 工程師不見得會有，但對做過模型監控（Model Monitoring）的人來說幾乎是反射動作。
# 跨越 Windows / Linux 的系統鴻溝
大多數資料科學家的日常開發環境是 Windows、公司配的筆電是 Windows，Excel 是 Windows，連 Jupyter Notebook 大概也是在 Windows 上跑的。一切都很和平，直到你需要把服務部署到伺服器上...... 只要你在台灣的製造業或者傳統企業 IT 環境裡工作過，絕對有高度共鳴的痛處之一。
換行符號、檔案權限、套件管理、系統依賴...... 各種雷還有坑，族繁不及備載。而要把這個主題要單獨拉出來講，也不太對。因為綜合本篇以及前兩篇文章所提到的前後端工程、網路工程、DevOps、資訊安全等等，皆可以跟這個主題有所關聯，然後再次觸及到「到底要還要學到多廣、多深才夠用？」這個命題。
所幸，這些坑不是一天兩天才有的。在過去數十年來，在那個 AI 還不普的年代，就已經有諸多前輩烈士留下了許多避雷指南，讓我們後人有機會乘涼🙏剩下的，是我們自己願不願意去找到那顆能夠乘涼的樹。
# 資安
說到資安，這大概是資料科學家最容易有「那是 IT 部門的事」的錯覺的一個領域。
在許多非 IT 人員的認知當中，資安就是防火牆、防毒軟體、還有那個每季都要重設一次的密碼政策
幾個對資料科學家來說最直接相關的面向是這些：
- 【憑證管理】：API key、資料庫密碼、各種存取令牌，絕對不能寫在程式碼裡。環境變數（environment variables）或者密鑰管理服務（Secret Manager）是正確的做法。這個習慣養成之後，其實不麻煩，但沒有養成之前，你甚至不會意識到自己哪裡做錯了。
- 【輸入驗證】：這件事在後端 API 的設計上已經有提過，但從資安的角度來看，重點不只是「確認格式對不對」，而是「確保使用者送進來的任何輸入，都不能讓系統做它不該做的事」。SQL Injection 是最經典的例子，但在資料科學的應用場景裡，還有一種比較少被討論的威脅：如果使用者可以影響你的模型訓練資料，他有沒有辦法讓你的模型學到奇怪的東西？（這就是所謂的 Data Poisoning，在 ML 資安的領域裡是一個真實存在的攻擊面向。）
- 【最小權限原則】：你的服務用來存取資料庫的帳號，需要有 DROP TABLE 的權限嗎？大概不需要。但如果你在設定的時候圖方便直接給了最高管理員權限，那一旦這個帳號的憑證外洩，損失就不只是資料被讀走，而是整個資料庫都可以被人操作。
# 尾聲
「那麼，資料科學的底子，有沒有幫上什麼忙？」
「有，而且是關鍵時刻才看得出來的那種幫忙。」
在 DevOps 的場景裡，對模型效能指標的敏感度，讓我在設計監控機制時，很自然地會想到要追蹤的不只是系統層面的指標（response time、error rate），還有業務層面的指標（預測誤差有沒有在這次部署之後悄悄變大？）。這個視角，純粹的 DevOps 工程師不見得會有，但對做過模型監控（Model Monitoring）的人來說幾乎是反射動作。
又例如：對資料品質的直覺，讓我在接到一份來自上游系統的資料時，會習慣性地先做基本的合理性檢查，而不是直接拿去跑模型。這種「資料來了先別急著用，先看看它長什麼樣子」的習慣，其實就是統計訓練裡的 EDA 精神，只是換了一個舞台繼續發揮。 說到底，這些轉型的過程並不是「拋棄原本的自己去學一套新的技能」，而是更像是在原本的語言能力上來學會新的方言。
而原本，當初在想著這一系列文章的構成時，文章篇幅數要比現在還來得多了。但後來想想，我並不是在教科書、也沒有衝貼文點閱次數的需求 這年代誰還在部落格文章衝點閱數。只是想留個「自己己也走過」、「我還在這條路上」的記錄。
而原本，當初在想著這一系列文章的構成時，文章篇幅數要比現在還來得多了。但後來想想，我並不是在教科書、也沒有衝貼文點閱次數的需求 這年代誰還在部落格文章衝點閱數。只是想留個「自己己也走過」、「我還在這條路上」的記錄。
既然如此，就還是別寫得發散，而是讓每一位還願意花時間把文章看到尾聲的人們、以及我自己知道，自己還願意走在這條路，不容易，也值得勉勵！