上個(gè)月我花了一周時(shí)間把一個(gè)人工智能小工具從本地開發(fā)機(jī)搬到生產(chǎn)服務(wù)器。原本以為只是把代碼傳上去、起個(gè)服務(wù)、開個(gè)端口就能完事結(jié)果在終端工具切換、數(shù)據(jù)庫連接串、模型加載路徑、自動(dòng)化測試用例、服務(wù)重啟方式和證書續(xù)期這些環(huán)節(jié)上輪番踩坑。整個(gè)過程讓我重新理解了“工具、測試與部署”這三個(gè)詞它們不是三個(gè)獨(dú)立的步驟而是一條必須打通的價(jià)值鏈。這篇文章我用自己的真實(shí)項(xiàng)目復(fù)盤把里面有共性的經(jīng)驗(yàn)、代碼和配置寫出來希望對你有參考價(jià)值。1. 工具選型不被“熱門工具”裹挾先弄清楚自己缺什么1.1 終端工具和數(shù)據(jù)庫工具日常效率的真正瓶頸很多人選工具時(shí)喜歡看“最全推薦”“十大神器”但我更建議按工作流倒推。這次項(xiàng)目里我每天要重復(fù)做的事是改代碼、連服務(wù)器看日志、查數(shù)據(jù)庫里的臨時(shí)表、把本地文件傳到服務(wù)器。如果每一步都打開不同的軟件光切換就浪費(fèi)半小時(shí)。終端工具我最終選了 Tabby。它最打動(dòng)我的不是好看的主題而是兩點(diǎn)一是多標(biāo)簽和會(huì)話分組我同時(shí)維護(hù)測試環(huán)境和生產(chǎn)環(huán)境各開一個(gè)標(biāo)簽組不容易搞混二是內(nèi)置了 SFTP 面板部署時(shí)直接把本地文件拽到遠(yuǎn)程目錄省去再開一個(gè) FTP 客戶端的麻煩。Windows 自帶的 cmd 和 PowerShell 不是不能用但是會(huì)話管理、回滾記錄、快捷鍵自定義這幾個(gè)體驗(yàn)確實(shí)差一些。數(shù)據(jù)庫工具方面項(xiàng)目里用了 dbx 這個(gè)工具來連接 MySQL 和 PostgreSQL。我選它的原因是輕量啟動(dòng)快補(bǔ)全不卡頓而且它可以直接查看表結(jié)構(gòu)和執(zhí)行批量更新對測試階段清理臟數(shù)據(jù)特別方便。有些團(tuán)隊(duì)喜歡用某全家桶 IDE 連數(shù)據(jù)庫但項(xiàng)目小的時(shí)候全家桶啟動(dòng)一分鐘等它連上庫我都能跑完三條 SQL 了。需要清醒一點(diǎn)工具是為流程服務(wù)的不是為“看起來很專業(yè)”服務(wù)的。如果你不是每天都會(huì)用到某項(xiàng)高級功能那這個(gè)高級功能就不該成為你選它的理由。1.2 調(diào)試工具與系統(tǒng)工具關(guān)鍵時(shí)刻能救命的冷門選擇日常開發(fā)中IDE 的調(diào)試器夠用但到了線上環(huán)境很多問題只能靠命令行工具。比如這次排查一個(gè) C 語言服務(wù)崩潰最后就是靠 gdb 調(diào)試工具定位到段錯(cuò)誤發(fā)生在字符串處理函數(shù)里。很多人看到 gdb 的字符界面就退縮其實(shí)核心命令就那幾個(gè)break、run、bt、print。尤其是bt崩了之后打一下調(diào)用棧立刻出來。順便提一句我還在 U 盤系統(tǒng)維護(hù)上用到過 Rufus 這類工具。當(dāng)時(shí)給一臺(tái)老筆記本重裝系統(tǒng)默認(rèn)刻錄工具總失敗換成 Rufus 選對分區(qū)格式一次就過了。這些系統(tǒng)級工具平時(shí)不起眼真要用的時(shí)候沒有會(huì)很崩潰。工具清單不需要很長我把它分成了四類每一類只留一個(gè)主力和一個(gè)備選用途主力工具備選方案選型理由終端連接TabbyWindows Terminal會(huì)話管理 內(nèi)置SFTP部署省一步數(shù)據(jù)庫操作dbxDBeaver輕量、響應(yīng)快多庫切換無壓力崩潰排查gdbAddressSanitizer定位段錯(cuò)誤快調(diào)用棧一目了然系統(tǒng)維護(hù)RufusVentoy啟動(dòng)盤制作穩(wěn)定兼容性好最關(guān)鍵的不是這個(gè)名單而是你評估工具時(shí)用的標(biāo)準(zhǔn)是否活躍維護(hù)、是否跨平臺(tái)、能否腳本化、學(xué)習(xí)成本多高。把一個(gè)工具的使用成本乘以每天打開的次數(shù)才是它的真實(shí)成本。1.3 一個(gè)可以照抄的工具評估流程我現(xiàn)在每引入一個(gè)新工具都會(huì)先跑一遍四步評估第一步寫下我要解決的問題而不是我想用的功能第二步列出兩三個(gè)候選工具都裝到本地試用二十分鐘第三步看社區(qū)活躍度太冷門的工具就算再好用出問題都找不到人問第四步確認(rèn)能否命令行調(diào)用因?yàn)楹竺嬉獙戇M(jìn) CI/CD 流水線。如果它只有圖形界面我就會(huì)很謹(jǐn)慎。工具選型這件事本質(zhì)上是為自己的工作流做減法。把那些花里胡哨、一年用不了幾次的功能砍掉剩下能讓你在終端里少敲一次命令、在數(shù)據(jù)庫里少點(diǎn)一次鼠標(biāo)的才是好工具。2. 把測試當(dāng)“安全網(wǎng)”來設(shè)計(jì)自動(dòng)化測試不是給領(lǐng)導(dǎo)看的2.1 從手動(dòng)點(diǎn)頁面到 pytest 腳本一次痛苦的覺醒這個(gè)項(xiàng)目一開始的接口測試全靠 Postman 手動(dòng)點(diǎn)。做了一周以后我發(fā)現(xiàn)自己每次改完接口都要重復(fù)點(diǎn)十幾個(gè)請求而且經(jīng)常漏掉某個(gè)參數(shù)組合。后來社區(qū)里大家經(jīng)常討論自動(dòng)化測試框架 pytest我也決定遷移過去。pytest 的優(yōu)勢很直接fixture 管理測試環(huán)境參數(shù)化覆蓋多組輸入斷言失敗時(shí)錯(cuò)誤信息一目了然。舉個(gè)例子我用 Flask 起了一個(gè)服務(wù)想測幾個(gè) GET 接口是否正常import pytest import requests pytest.fixture def base_url(): # 測試前的環(huán)境準(zhǔn)備可以在這里動(dòng)態(tài)讀取配置 return http://127.0.0.1:5000 pytest.mark.parametrize(path,expected, [ (/health, 200), (/docs, 200), (/, 200), ]) def test_get_endpoints(base_url, path, expected): r requests.get(base_url path) assert r.status_code expected這段代碼里有幾個(gè)思路值得展開說base_url這個(gè) fixture 把環(huán)境信息抽離出來以后從測試環(huán)境切到預(yù)發(fā)布環(huán)境只改一處parametrize讓同一段邏輯跑多組數(shù)據(jù)不用復(fù)制粘貼用例。實(shí)際項(xiàng)目里我連數(shù)據(jù)庫連接串都是從環(huán)境變量讀的因?yàn)楸镜販y試和生產(chǎn)測試用的根本不是同一個(gè)庫。pytest 還有豐富的插件生態(tài)。比如pytest-html生成可視化報(bào)告pytest-cov統(tǒng)計(jì)覆蓋率pytest-xdist并行執(zhí)行用例。但我不建議一上來就全加上先跑通最核心的接口用例再一步步加。2.2 功能測試之外安全測試和兼容性測試也要納入流程很多人對測試的理解就是“功能能跑就行”但這次項(xiàng)目讓我意識(shí)到安全測試和兼容性測試同樣要在測試用例里留位置。網(wǎng)上有個(gè)熱搜詞叫“手機(jī) app 登錄密碼是否明文存儲(chǔ)”這就是一個(gè)很典型的安全測試點(diǎn)。我在做 Web 接口時(shí)也遇到過類似問題開發(fā)階段為了調(diào)試方便接口直接走 HTTP密碼字段也可以明文返回。這個(gè)東西如果在測試階段不寫進(jìn)用例等到上線前用抓包工具一看才會(huì)嚇一跳。我的做法是寫一個(gè)安全斷言用例檢查登錄接口的證書是否是 HTTPS返回報(bào)文里是否包含password字段的明文必要的時(shí)候用測試環(huán)境的抓包代理跑一遍主要流程。這不需要多復(fù)雜的工具在 pytest 里加一個(gè)簡單的測試項(xiàng)就可以。兼容性測試也很容易被忽略。比如你本地用的 Python 版本是 3.11生產(chǎn)環(huán)境的鏡像還留在 3.9某些語法或依賴就會(huì)出問題。所以我在測試階段會(huì)刻意用和生產(chǎn)環(huán)境相同版本的運(yùn)行時(shí)跑一遍用例。這聽起來是常識(shí)但每一次線上事故背后幾乎都有一條“測試環(huán)境和生產(chǎn)環(huán)境不一致”的教訓(xùn)。2.3 讓測試結(jié)果真正被用起來報(bào)告、CI 與質(zhì)量門禁測試用例寫出來如果只是本地跑一下價(jià)值就少了一半。我的做法是把 pytest 接入 GitLab CI在每一次提交代碼時(shí)自動(dòng)跑一遍。CI 里的流程大概是安裝依賴用生產(chǎn)環(huán)境的鏡像版本跑一遍 pytest生成 HTML 報(bào)告如果核心用例失敗就打回提交不允許合并這樣測試就成了項(xiàng)目的安全網(wǎng)而不是一個(gè)每周日晚上才想起來的手動(dòng)儀式。我還用到了一個(gè)技巧把并行的測試環(huán)境用容器隔離每個(gè)測試用例跑完自動(dòng)銷毀避免上一次運(yùn)行殘留的數(shù)據(jù)影響下一次結(jié)果。這一點(diǎn)非常重要特別是當(dāng)你的測試會(huì)真實(shí)寫數(shù)據(jù)庫時(shí)。注意不要把測試環(huán)境的臟數(shù)據(jù)帶到下一次測試?yán)?。我見過太多失敗用例是因?yàn)樯弦粭l測試數(shù)據(jù)沒清干凈而非代碼邏輯有問題。聰明的做法是每個(gè)用例用獨(dú)立事務(wù)或者獨(dú)立表前綴。3. 部署實(shí)戰(zhàn)本地模型、服務(wù)器服務(wù)、邊緣設(shè)備各自怎么玩3.1 本地模型部署ollama 和 mineru 的安裝與依賴處理項(xiàng)目里有一個(gè)需求是要在本地跑一個(gè)大語言模型不把數(shù)據(jù)送到外部 API。社區(qū)里最常提到的工具就是 ollama 本地部署。Ollama 把模型下載、量化、API 暴露都封裝好了安裝也簡單ollama pull llama3 ollama serve拉下來的模型一般存在~/.ollama/models里API 默認(rèn)跑在11434端口。對于大多數(shù)個(gè)人項(xiàng)目這個(gè)方案的開箱體驗(yàn)比從頭部署 Transformer 框架要順手太多。但 ollama 也不是沒有坑一是模型文件很大拉取時(shí)要注意磁盤空間二是默認(rèn)并發(fā)數(shù)不高多個(gè)請求同時(shí)打過來響應(yīng)會(huì)明顯變慢。你需要手動(dòng)看日志確認(rèn)是不是 CPU/顯存成為瓶頸。另一個(gè)文檔解析工具 mineru 本地部署也值得提一句。它的安裝涉及 PyTorch 和若干底層依賴最容易碰到的坑是 CUDA 版本對不上。我當(dāng)時(shí)的解決方式是顯式指定一個(gè)和顯卡匹配的 PyTorch 版本再用pip install -r requirements.txt重建虛擬環(huán)境。不要用系統(tǒng)自帶的 Python 去直接裝否則依賴沖突遲早找上你。我的建議是本地部署的模型類項(xiàng)目盡量把 Python 包管理器和底層驅(qū)動(dòng)分開。用虛擬環(huán)境管理 Python 包用docker管理運(yùn)行環(huán)境里的系統(tǒng)依賴兩層隔離才能平穩(wěn)。3.2 服務(wù)器部署Flask Gunicorn Nginx 的標(biāo)準(zhǔn)組合項(xiàng)目里主服務(wù)用的是 Flask開發(fā)階段直接flask run就能跑但生產(chǎn)環(huán)境不能這么干。我需要一個(gè)能管理進(jìn)程、能重啟、能開機(jī)自啟的方案。最后用的組合是 Gunicorn 負(fù)責(zé)多進(jìn)程承載Nginx 負(fù)責(zé)反向代理和靜態(tài)文件systemd 負(fù)責(zé)進(jìn)程守護(hù)。先看一個(gè)最簡單的 systemd 服務(wù)文件[Unit] DescriptionMy Flask App Afternetwork.target [Service] Userdeploy WorkingDirectory/home/deploy/app EnvironmentFile/home/deploy/app/.env ExecStart/home/deploy/app/venv/bin/gunicorn -w 4 -b 127.0.0.1:8000 wsgi:app Restartalways RestartSec5 [Install] WantedBymulti-user.target這個(gè)文件里的幾個(gè)配置要理解EnvironmentFile是我從外部讀環(huán)境變量避免把密鑰硬編碼進(jìn)代碼Restartalways讓服務(wù)在崩潰后五秒自動(dòng)拉起-w 4是四個(gè) worker 進(jìn)程要根據(jù) CPU 核心數(shù)和內(nèi)存調(diào)整不是越多越好。Nginx 側(cè)的配置核心就是一條反向代理把/流量轉(zhuǎn)發(fā)到本地 8000 端口同時(shí)把上傳大小限制、訪問日志開好。部署后一定要通過 Nginx 去訪問而不是繞過它直接打到 Gunicorn。外面那層是統(tǒng)一的網(wǎng)關(guān)入口才能在后面加 TLS、限流和緩存。3.3 邊緣設(shè)備部署rk3588 跑 YOLOv8 的關(guān)鍵是模型轉(zhuǎn)換如果你和我一樣要把模型放到 RK3588 這種邊緣設(shè)備上跑常規(guī)的 PyTorch 部署方式就不好使了。它雖然自帶 NPU但需要把模型轉(zhuǎn)成 RKNN 格式。我這次跑 YOLOv8整體流程分三步在 PC 上用 YOLOv8 的導(dǎo)出接口把模型轉(zhuǎn)成 ONNX用 rknn-toolkit2 把 ONNX 轉(zhuǎn)成 RKNN同時(shí)設(shè)置量化方式在板子上加載 RKNN 模型用 NPU 推理輸出檢測結(jié)果。最容易出的問題在第二步ONNX 里有些算子 RKNN 不認(rèn)需要簡化模型或者替換算子。處理方式通常是先到 RKNN 工具鏈的文檔里查算子支持列表或者在轉(zhuǎn)換時(shí)打開 debug 模式看哪個(gè)節(jié)點(diǎn)報(bào)錯(cuò)。我第一次轉(zhuǎn)的時(shí)候就卡在 NMS 算子最后把后處理挪到板子 CPU 上跑才解決。從實(shí)際效果看RK3588 上跑 YOLOv8 的檢測幀率比純 CPU 快不少但比不過獨(dú)立顯卡。它的價(jià)值是低功耗、小體積適合邊緣盒子這樣的場景。部署這種設(shè)備時(shí)一定不要把 PC 上的環(huán)境原樣搬過去而是交叉編譯好 Python 模塊和依賴再一起打包部署。3.4 自動(dòng)化部署容器、任務(wù)編排和證書續(xù)期一起考慮部署到服務(wù)器后下一步就是讓整個(gè)過程自動(dòng)化不能每次發(fā)布都手工 ssh 上去敲命令。我現(xiàn)在的做法是把服務(wù)打包成 Docker 鏡像推到私有倉庫然后在服務(wù)器上docker compose pull docker compose up -d完成更新。這樣做的最大好處是環(huán)境一致本地怎么跑服務(wù)器就怎么跑不會(huì)出現(xiàn)“在我機(jī)器上是好的”這種問題。除了一般的 Web 服務(wù)圖數(shù)據(jù)庫這類基礎(chǔ)組件也適合用 Docker 部署。比如 Dgraph 鏡像部署兩條命令就能拉起一個(gè)單機(jī)實(shí)例省去自己折騰安裝依賴的麻煩。不過要注意數(shù)據(jù)持久化容器重生的時(shí)候不能把數(shù)據(jù)卷丟掉。自動(dòng)部署還包括證書續(xù)期。之前用 certum 證書自動(dòng)部署方案配合 ACME 協(xié)議和定時(shí)任務(wù)證書快到期時(shí)自動(dòng)聯(lián)網(wǎng)續(xù)期。我補(bǔ)了一個(gè)部署鉤子續(xù)期成功后自動(dòng)重載 Nginx真正做到“無人值守”。如果沒有這個(gè)機(jī)制證書過期是一個(gè)特別常見又特別隱蔽的事故點(diǎn)——直到用戶訪問才發(fā)現(xiàn)在瀏覽器上赫然寫著“不安全”。4. 端到端發(fā)布流程把工具、測試、部署串成一條鏈4.1 一次發(fā)布要經(jīng)過的檢查站工具也選好了測試也覆蓋了部署也練過手了接下來要思考的是它們怎么被組織成一條可靠的發(fā)布流程。我把一次發(fā)布拆成七個(gè)檢查站開發(fā)分支提交觸發(fā) CI靜態(tài)檢查和單元測試構(gòu)建 Docker 鏡像并做安全掃描推送鏡像到私有倉庫在預(yù)發(fā)布環(huán)境跑一遍 pytest 集成測試生產(chǎn)環(huán)境滾動(dòng)更新先更新一臺(tái)機(jī)器觀察健康檢查通過后再更新其余機(jī)器檢查證書、日志和監(jiān)控告警是否正常。這條流程看著平淡無奇但每個(gè)檢查站背后都對應(yīng)著一個(gè)踩過的坑。比如第三步以前不掃描鏡像后來發(fā)現(xiàn)基礎(chǔ)鏡像里有高危漏洞只能重新構(gòu)建再比如第五步預(yù)發(fā)布環(huán)境的數(shù)據(jù)庫如果和生產(chǎn)環(huán)境差異過大測試結(jié)果基本沒有參考價(jià)值。4.2 灰度發(fā)布、可觀測性與回滾如果你只有一個(gè)實(shí)例流程就只是“重啟一下”但真正服務(wù)線上用戶時(shí)必須有灰度意識(shí)。我建議至少做到按機(jī)器分批更新或者按流量百分比切一部分請求到新版本上。這樣一旦發(fā)現(xiàn)新版本有問題受影響范圍是一個(gè)可控的小集合?？捎^測性和回滾是配套的。我在部署后一定會(huì)檢查三個(gè)東西錯(cuò)誤率、響應(yīng)耗時(shí)、系統(tǒng)資源使用率。如果錯(cuò)誤率沒有升高再看耗時(shí)是否異常如果耗時(shí)暴漲即使接口請求成功也要懷疑是不是死鎖或者內(nèi)存泄漏?；貪L方案要提前定好最簡單的是把上一版鏡像重新拉起或者保留舊鏡像并讓 compose 文件切回上個(gè)標(biāo)簽。提示回滾不是發(fā)布失敗才做的事。有時(shí)候是新功能上線后用戶不買賬需要回到舊版本。所以每次發(fā)布前務(wù)必確認(rèn)舊鏡像還在倉庫里而不是被覆蓋了。4.3 環(huán)境、密鑰和數(shù)據(jù)庫遷移的邊界團(tuán)隊(duì)協(xié)作里最容易忽略的是環(huán)境邊界。每個(gè)人本地一套環(huán)境預(yù)發(fā)布一套生產(chǎn)一套如果環(huán)境變量沒有統(tǒng)一管理就會(huì)出現(xiàn)“本地能跑、生產(chǎn)崩了”的魔幻場景。我現(xiàn)在的做法是寫一份.env.example放到倉庫里真實(shí)密鑰放在服務(wù)器上的.env文件里并且該文件不入版本庫。數(shù)據(jù)庫遷移也要提前進(jìn)流程。我的習(xí)慣是發(fā)布新版本前先跑遷移腳本再切流量。最怕的是代碼已經(jīng)上來但數(shù)據(jù)庫表結(jié)構(gòu)還沒修改接口一調(diào)用直接報(bào)錯(cuò)。在 AI 相關(guān)項(xiàng)目里還要注意模型文件路徑不同版本可能對應(yīng)不同的模型文件部署腳本里必須顯式指定版本不能用“最新”這種模糊方式。5. 踩坑實(shí)錄部署后服務(wù)假死、環(huán)境不一致、版本失控5.1 部署后“服務(wù)假死”的排查過程上線后最讓我頭疼的問題不是服務(wù)直接崩掉而是它“假死”——端口還在監(jiān)聽但請求不處理半天沒有響應(yīng)。第一次遇到時(shí)我 ssh 上去看進(jìn)程還在用curl訪問本地端口也通但實(shí)際業(yè)務(wù)請求超時(shí)。一步步排查之后才發(fā)現(xiàn)是工作線程池被占滿了。Gunicorn 默認(rèn) worker 數(shù)開得少模型推理的耗時(shí)又長前幾個(gè)請求堵住后面的請求全部排隊(duì)。解決方法是增加 worker 數(shù)并設(shè)置請求超時(shí)時(shí)間同時(shí)把耗時(shí)的模型加載操作放到初始化階段而不是每次請求都加載一遍。從那以后我再部署模型服務(wù)都會(huì)先壓測一下并發(fā)量再?zèng)Q定 worker 數(shù)量。5.2 測試環(huán)境與生產(chǎn)環(huán)境不一致導(dǎo)致的經(jīng)典問題還有一次測試完全通過結(jié)果生產(chǎn)環(huán)境啟動(dòng)失敗報(bào)錯(cuò)說某個(gè)系統(tǒng)庫找不到。后來發(fā)現(xiàn)測試環(huán)境的操作系統(tǒng)是 Ubuntu 22.04生產(chǎn)環(huán)境是 CentOS 7基礎(chǔ)依賴不同。這就是典型的“測試環(huán)境和生產(chǎn)環(huán)境不一致”。這也是我后來堅(jiān)決要引入 Docker 的原因?；A(chǔ)鏡像一鎖定系統(tǒng)庫、Python 版本、運(yùn)行時(shí)全部一致再?zèng)]有出現(xiàn)過“本地能跑、服務(wù)器跑不了”的抱怨。如果你暫時(shí)沒有容器化的條件至少要在測試環(huán)境里裝一個(gè)和生產(chǎn)環(huán)境版本一致的系統(tǒng)虛擬機(jī)否則測試通過這件事沒有意義。5.3 工具鏈版本鎖定的重要性最后想提醒的是版本鎖定。Python 依賴、Node 依賴、模型文件、工具鏈版本任何一個(gè)漂移都可能讓前面的測試和部署白做。我見過同事因?yàn)橐蕾嚴(yán)锏囊粋€(gè)flask小版本更新導(dǎo)致接口返回格式變化測試用例沒有覆蓋到直接上線后用戶反饋頁面異?！，F(xiàn)在我要求所有項(xiàng)目都要有鎖文件Python 用requirements.lock前端用pnpm-lock.yaml模型文件有單獨(dú)的版本清單。CI 里構(gòu)建鏡像時(shí)也明確只用鎖文件不做“安裝最新版本”的操作。這樣做看似保守但能保證你在任何時(shí)候拉回來的代碼都能復(fù)現(xiàn)出和線上一致的行為。工具、測試、部署每一件事單獨(dú)拿出來都不難真正難的是讓它們作為一個(gè)整體為項(xiàng)目兜底。我覺得最有價(jià)值的不是掌握了某條命令或某個(gè)框架而是建立起一套“先想清楚再做”的習(xí)慣。工具為流程服務(wù)測試為變化兜底部署為交付鋪路。三者真正打通之后你發(fā)布一個(gè)版本的心悸感會(huì)少很多多出來的是對這套流程的信任。下一次再遇到類似項(xiàng)目我會(huì)先問自己我的工具選對了嗎我的測試能不能攔住回歸我的部署回滾快不快這三個(gè)問題答上了項(xiàng)目基本就穩(wěn)了。