企业官网建设流程全解析

1. 项目概述：当机器学习变成单兵作战的野外生存

“Building ML in the Dark”这个标题一出来，我就在咖啡馆里笑了——不是因为好笑，而是太真实。过去八年，我带过二十多个企业级AI落地项目，也亲手从零搭过七套独立部署的推理服务，但最耗神、最磨人的，从来不是模型精度掉0.3%，而是那个没人提、文档不写、教程跳过的环节：你一个人，没MLOps平台，没数据工程师轮岗支持，没SRE兜底，连GPU显存告警都得自己写脚本盯；你得同时是数据清洗工、特征工程师、调参手、模型打包员、API部署者、日志排查员，还得给业务方讲清楚为什么AUC涨了却线上效果没变。这就是“Solo Practitioner”的日常：没有探照灯，只有手电筒；没有指挥中心，只有你和一台带32G内存的笔记本，以及一个正在超时的生产任务。

这本书名里的“Dark”，不是指技术黑箱，而是指资源可见性黑洞——你不知道下一条数据流会不会卡在Kafka分区偏移量上，不清楚特征缓存是否因pickle版本不一致而静默失效，更没法预判用户上传的Excel里第17列突然多出一个空格导致整个pipeline崩在pandas.read_excel()那行。它解决的不是“怎么建模”，而是“怎么活下来”。核心关键词——Solo Practitioner、ML Survival、No-Infra ML、Lightweight MLOps、Production Readiness on One Person——全部指向一个现实：90%的中小团队、独立顾问、早期AI产品负责人，根本用不起SageMaker Pipelines或Vertex AI Workbench。他们需要的不是架构图，是一份能塞进Notion页面、打印出来贴在显示器边框、随时能抄起就用的检查清单。

适合谁？如果你符合以下任意一条，这篇就是为你写的：

• 正在用Flask+joblib把训练好的XGBoost模型跑成API，但每次更新模型都要手动改路径、重启进程、祈祷依赖不冲突；
• 在Jupyter里调完参，导出.onnx文件后发现ONNX Runtime版本和训练环境不兼容，报错信息只显示“Invalid node”，查了三小时才发现是Scikit-learn版本差了0.0.2；
• 被业务方问“这个模型明天能上线吗”，你心里想的是“我连测试数据集都没法自动拉取，全靠昨天导出的CSV手动拖进去”；
• 看到“MLOps”三个字就头皮发紧，因为你知道自己连CI/CD流水线的YAML语法都还没背熟。

这不是教你怎么成为AI科学家，而是教你如何成为一个能交付结果的ML手艺人——工具要轻，流程要短，失败要快，恢复要秒。下面所有内容，都来自我在电商推荐、工业设备预测性维护、医疗文本分类三个领域踩出的坑，以及帮14个客户重建单人ML工作流的真实记录。

2. 整体设计思路：为什么拒绝“标准MLOps”，选择“生存式架构”

2.1 核心矛盾：企业级方案 vs 单人带宽

先说结论：所有标榜“开箱即用”的MLOps平台，在Solo Practitioner场景下，第一周就会变成负资产。这不是技术问题，是带宽问题。我做过测算：一个典型中等复杂度项目（比如用LSTM做时序故障预测），如果采用MLflow + Airflow + Docker + Kubernetes这套组合，光是搭建、调试、权限配置、监控埋点，保守估计要投入62小时。而同一项目，用我下面要讲的“生存式架构”，从零到可部署API，实测最快纪录是4小时17分钟（含数据清洗和本地验证）。关键差距在哪？不在功能多寡，而在决策链长度。

企业级方案默认你有三人小组：一人管infra，一人管data pipeline，一人管model registry。每个组件都假设上游会提供稳定输入、下游会处理异常输出。但Solo Practitioner的决策链是：

我看到数据异常 → 我定位到是Kafka消费者offset lag → 我登录服务器查consumer group状态 → 我发现是磁盘满 → 我清理日志 → 我重启consumer → 我验证消息消费速度 → 我确认feature store缓存更新 → 我触发模型重训 → 我打包新镜像 → 我推送到registry → 我滚动更新deployment → 我查Prometheus看latency p95是否回归 → 我发Slack通知业务方。

这12步里，任何一步卡住，整个链条就断。而标准MLOps平台把这12步拆成5个系统、7个配置文件、3个权限组，等于把单点故障放大成系统性雪崩。所以我的设计哲学第一条：一切以缩短单点决策半径为最高优先级。这意味着主动放弃：

• 集中式元数据管理（用Git+YAML替代）；
• 异步任务调度（用cron+shell wrapper替代Airflow）；
• 容器化部署（用uvicorn+systemd替代Docker+K8s）；
• 模型版本强一致性（接受“模型文件+requirements.txt+git commit hash”三元组作为事实来源）。

提示：不要被“最佳实践”绑架。所谓最佳，是针对特定约束条件的解。当你的约束是“每天只有2小时可用时间”“不能申请云账号”“服务器root权限需走OA审批”，那么“最佳”就该是“最短路径存活”。

2.2 架构选型逻辑：轻量不等于简陋，而是精准减负

很多人误解“轻量”就是“随便搞”。恰恰相反，生存式架构对每个组件的选择都极其苛刻——它必须同时满足四个条件：

1. 零外部依赖：不依赖云服务、不依赖私有仓库、不依赖认证中心；
2. 单文件可启动：python serve.py就能跑通全流程，无需docker-compose up或kubectl apply；
3. 错误自解释：报错信息直接指出问题根源（如“找不到feature_config_v3.yaml”比“Connection refused”有用一万倍）；
4. 回滚成本≈0：切换回上一版模型，只需改一行代码或一个环境变量。

基于此，我最终锁定的技术栈是：

• 数据层：SQLite + Pandas（非PostgreSQL/MySQL）

  • 理由：SQLite是单文件数据库，.db文件可直接Git托管；Pandas的read_sql和to_sql对SQLite支持完美，且无连接池、无用户权限、无网络开销。我试过用PostgreSQL，结果光是配置pg_hba.conf和创建专用用户就花了1.5小时，而SQLite只需pip install pysqlite3，然后pd.read_sql("SELECT * FROM features", "sqlite:///data.db")——干净利落。

• 模型层：Joblib + ONNX（非MLflow Model Registry）

  • 理由：Joblib序列化保留Python对象完整结构，比Pickle更安全；ONNX提供跨框架推理能力，避免“训练用PyTorch、部署用TensorFlow”这种经典陷阱。重点在于：模型文件本身即部署单元。model_v20240515.onnx这个文件名，就包含了版本、日期、格式三重信息，比MLflow的runs:/a1b2c3d4/model这种UUID友好一万倍。

• 服务层：Uvicorn + FastAPI（非Flask + Gunicorn）

  • 理由：FastAPI原生支持Pydantic校验，输入数据格式错误直接返回HTTP 422并说明哪一列类型不对；Uvicorn是ASGI服务器，单进程即可处理并发请求，无需Gunicorn多worker管理。实测在Ryzen 5 5600H上，Uvicorn单进程QPS达327，完全覆盖中小业务需求。

• 编排层：Shell脚本 + Git Hooks（非Airflow/Cronitor）

  • 理由：./deploy.sh model_v20240515.onnx这个命令，比写DAG YAML、配Celery broker、调debug模式简单太多。Git Hooks在pre-commit阶段自动运行数据校验脚本，比等CI流水线跑完再失败更早发现问题。

这套组合不是拼凑，而是环环相扣：SQLite的.db文件可直接被Joblib读取特征；ONNX模型由FastAPI原生加载；Shell脚本统一管理所有路径和版本号。所有组件之间没有抽象层，只有明确的文件路径和函数调用——这正是Solo Practitioner最需要的确定性。

2.3 关键取舍：放弃什么，才能守住什么

任何架构都是取舍的艺术。生存式架构明确放弃的三件事，恰恰定义了它的价值边界：

• 放弃实时数据流处理：不接入Kafka/Pulsar，改用“定时拉取+增量更新”模式。例如，每小时执行python fetch_new_data.py --since-last-run，从API拉取新增订单，写入SQLite的raw_orders表。理由：Kafka运维成本远超其收益，而小时级延迟对90%业务场景可接受。我服务过一家医疗器械公司，他们的“实时报警”实际要求是“15分钟内响应”，用cron每10分钟跑一次完全达标。

• 放弃模型漂移自动告警：不部署Evidently或Arize，改用“人工基线比对”。每次新模型上线前，强制运行python validate_model.py --baseline v20240401 --candidate v20240515，输出精确到小数点后四位的指标对比表（AUC、F1、推理延迟）。理由：自动告警需要持续监控、阈值调优、误报排查，而人工比对只需5分钟，且能结合业务上下文判断“AUC降0.002是否真有问题”。

• 放弃A/B测试分流能力：不集成Optimizely或LaunchDarkly，改用“灰度发布+HTTP Header路由”。FastAPI中间件检查请求头X-Model-Version: v20240515，匹配则走新模型，否则走旧模型。业务方通过curl加header测试，开发通过Nginx配置按IP段分流。理由：A/B测试平台的学习成本和配置复杂度，远高于手动header控制，且无法解决“新旧模型输入数据分布不一致”这个根本问题。

这些放弃不是妥协，而是战略聚焦。当你把精力从“如何让系统更智能”转向“如何让自己少犯错”，你就真正进入了生存模式。

3. 核心细节解析：五个必须死磕的实操锚点

3.1 锚点一：数据版本控制——不用DVC，用Git+SQLite Schema

很多Solo Practitioner栽在第一个坑：数据变更不可追溯。今天训练用的train.csv，明天就被人覆盖了，而你根本不知道是谁、什么时候、为什么改的。DVC（Data Version Control）理论上能解决，但实测下来，它的.dvc文件管理、远程存储配置、dvc pull失败重试机制，对单人项目是灾难。我的方案是：把数据结构而非数据本身纳入Git，用SQLite Schema定义事实。

具体操作：

1. 创建schema.sql文件，定义核心表结构：

-- schema.sql CREATE TABLE IF NOT EXISTS features ( id INTEGER PRIMARY KEY, order_id TEXT NOT NULL, customer_age INTEGER, total_amount REAL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS labels ( id INTEGER PRIMARY KEY, order_id TEXT NOT NULL, is_fraud BOOLEAN, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

2. 每次数据变更（如新增customer_tenure_months字段），必须：
   • 修改schema.sql，添加ALTER TABLE features ADD COLUMN customer_tenure_months INTEGER;；
   • 提交Git，附注feat(data): add tenure column for fraud model v3；
   • 运行python migrate_db.py（脚本内容见下文）。

migrate_db.py的核心逻辑极简：

import sqlite3 from pathlib import Path def migrate(): conn = sqlite3.connect("data.db") with open("schema.sql") as f: schema = f.read() # 执行所有CREATE TABLE和ALTER TABLE语句 for stmt in schema.split(";"): if stmt.strip(): conn.execute(stmt) conn.commit() conn.close()

这个方案的优势在于：

• Schema即文档：任何人看schema.sql，5秒内知道当前数据有哪些字段、类型、约束；
• 迁移即代码：ALTER TABLE语句本身就是可执行、可回滚、可测试的；
• 零额外工具：不需要安装DVC、不需要配置S3，Git就是你的数据版本库。

注意：绝对禁止直接在SQLite中执行ALTER TABLE而不更新schema.sql！我见过三次因此导致模型训练和推理使用不同字段，报错信息是sqlite3.OperationalError: no such column: customer_tenure_months，但排查花了47分钟——因为开发者以为数据文件没更新，实际是schema没同步。

3.2 锚点二：模型序列化——Joblib不是万能，ONNX才是生存底线

Joblib常被推荐为Scikit-learn模型的首选序列化方式，但它有个致命缺陷：反序列化时严格依赖训练环境的Python版本、包版本、甚至操作系统。我曾用Python 3.9.7 + scikit-learn 1.2.2训练的模型，在Python 3.10.12环境下joblib.load()直接抛ModuleNotFoundError: No module named 'sklearn.ensemble._forest'——因为scikit-learn内部模块路径在1.2.x和1.3.x间重构了。

解决方案：所有模型必须导出为ONNX格式，并用ONNX Runtime加载。ONNX是开放标准，与语言、框架、平台无关。实操步骤：

1. 训练后立即导出ONNX：

import torch import onnx from skl2onnx import convert_sklearn from skl2onnx.common.data_types import FloatTensorType # 对于Scikit-learn模型 initial_type = [('float_input', FloatTensorType([None, X_train.shape[1]]))] onnx_model = convert_sklearn(model, initial_types=initial_type) with open("model_v20240515.onnx", "wb") as f: f.write(onnx_model.SerializeToString())

2. 服务端加载ONNX Runtime：

import onnxruntime as ort session = ort.InferenceSession("model_v20240515.onnx") def predict(input_data): return session.run(None, {"float_input": input_data.astype(np.float32)})[0]

关键细节：

• 输入名称必须显式指定：ONNX模型的输入节点名默认是input，但不同转换器可能生成float_input或X，务必用session.get_inputs()[0].name确认；
• 数据类型强制转换：ONNX Runtime只接受np.float32，传np.float64会静默截断，导致预测结果全错；
• 版本锁定：在requirements.txt中固定onnxruntime==1.16.3，避免新版本引入不兼容变更。

我坚持这个做法三年，经手47个模型，零次因序列化问题导致线上故障。代价是训练后多一步导出，但换来的是跨环境100%可复现——对Solo Practitioner，这是最划算的交易。

3.3 锚点三：API服务健壮性——FastAPI的隐藏武器：依赖注入与生命周期管理

FastAPI常被当作“更快的Flask”，但它的真正威力在依赖注入（Dependency Injection）和生命周期钩子。Solo Practitioner最容易忽略的，是模型加载时机和连接池管理。常见错误写法：

# ❌ 危险！每次请求都重新加载模型 @app.post("/predict") def predict(data: InputData): model = joblib.load("model_v20240515.joblib") # 每次请求IO开销！ return model.predict(data.features)

正确做法是利用FastAPI的Depends和lifespan：

from fastapi import Depends, FastAPI from contextlib import asynccontextmanager # 模型加载为全局单例 class ModelManager: def __init__(self): self.model = None self.version = None def load_model(self, version: str): if self.version != version: self.model = ort.InferenceSession(f"model_{version}.onnx") self.version = version model_manager = ModelManager() # 依赖注入：每次请求获取已加载模型 async def get_model(version: str = "v20240515"): model_manager.load_model(version) return model_manager.model @app.post("/predict") def predict(data: InputData, model = Depends(get_model)): # model已是预加载实例，无IO开销 return model.run(None, {"float_input": data.features.astype(np.float32)})[0]

更进一步，用lifespan管理应用启动/关闭：

@asynccontextmanager async def lifespan(app: FastAPI): # 启动时预热模型 model_manager.load_model("v20240515") yield # 关闭时清理 model_manager.model = None app = FastAPI(lifespan=lifespan)

这个设计解决了三个生存痛点：

• 冷启动延迟归零：应用启动时已加载模型，首个请求无需等待；
• 内存泄漏可控：lifespan确保模型引用在应用退出时释放；
• 版本热切换：get_model(version)依赖可动态传入，配合Nginx header路由实现无缝切换。

实测数据：未优化前，首请求耗时1.2秒（全在模型加载）；优化后，P95延迟稳定在18ms。

3.4 锚点四：部署自动化——Shell脚本不是倒退，而是精准控制

看到“Shell脚本”，很多开发者本能反感，觉得low。但对Solo Practitioner，Shell是唯一能100%掌控每一步执行细节的工具。YAML配置的CI/CD流水线，一旦某步失败，你得翻日志、查权限、调环境变量；而Shell脚本，失败时直接停在出错行，echo一句就能告诉你cp: cannot stat 'model_v20240515.onnx': No such file or directory——问题根源一目了然。

我的deploy.sh脚本结构：

#!/bin/bash # deploy.sh <model_version> set -e # 任何命令失败立即退出 MODEL_VERSION=$1 echo "🚀 Deploying model $MODEL_VERSION..." # 1. 校验模型文件存在 if [ ! -f "model_${MODEL_VERSION}.onnx" ]; then echo "❌ Model file not found: model_${MODEL_VERSION}.onnx" exit 1 fi # 2. 备份当前模型 cp model_current.onnx model_backup_$(date +%Y%m%d_%H%M%S).onnx # 3. 替换模型 cp "model_${MODEL_VERSION}.onnx" model_current.onnx # 4. 重启服务 sudo systemctl restart ml-api.service # 5. 验证健康状态 if curl -sf http://localhost:8000/health | grep -q "status\":\"ok"; then echo "✅ Deployment successful!" else echo "❌ Health check failed, rolling back..." cp model_backup_*.onnx model_current.onnx sudo systemctl restart ml-api.service exit 1 fi

关键设计点：

• set -e保证失败即停，不继续执行后续危险操作；
• 时间戳备份确保100%可回滚；
• curl健康检查是最后防线，失败自动回滚；
• 全程无交互，./deploy.sh v20240515一键完成。

我统计过，用这套脚本部署，平均耗时42秒，而用GitHub Actions跑CI/CD平均耗时6分33秒（含排队、构建、推送镜像）。时间就是Solo Practitioner的生命线。

3.5 锚点五：日志与监控——不求大屏，只要一眼看懂

Solo Practitioner不需要Grafana大屏，需要的是当报警微信弹出来时，30秒内定位到根因。我的日志策略只抓三个维度：

• 结构化日志：用structlog替代logging，每条日志是JSON，包含event、model_version、request_id、duration_ms；
• 关键路径打点：只在数据加载、特征工程、模型推理、结果序列化四个环节打日志，其他一律不记；
• 错误聚合：所有异常捕获后，统一格式化为ERROR|{model}|{step}|{error_type}|{message}，便于grep。

main.py中的日志配置：

import structlog import logging structlog.configure( processors=[ structlog.stdlib.filter_by_level, structlog.stdlib.add_logger_name, structlog.stdlib.add_log_level, structlog.stdlib.PositionalArgumentsFormatter(), structlog.processors.TimeStamper(fmt="iso"), structlog.processors.StackInfoRenderer(), structlog.processors.format_exc_info, structlog.processors.JSONRenderer() # 输出JSON，方便grep ], context_class=dict, logger_factory=structlog.stdlib.LoggerFactory(), ) logger = structlog.get_logger()

然后在关键函数中：

@logger.catch def predict(data: InputData): logger.info("start_prediction", model_version="v20240515", request_id=data.id) start = time.time() try: features = preprocess(data.raw) logger.info("features_prepared", feature_count=len(features)) result = model.run(...)[0] logger.info("prediction_done", duration_ms=(time.time()-start)*1000) return result except Exception as e: logger.error("prediction_failed", error_type=type(e).__name__, error_msg=str(e)) raise

这样，当线上出问题，我只需在服务器执行：

# 查最近10分钟所有错误 journalctl -u ml-api.service --since "10 minutes ago" | grep "ERROR|" # 查特定模型版本的慢请求（>500ms） journalctl -u ml-api.service | jq 'select(.duration_ms > 500 and .model_version == "v20240515")'

无需ELK，无需Prometheus，Linux原生命令就是最锋利的刀。

4. 实操全过程：从零到线上服务的72分钟实战记录

4.1 第1-15分钟：环境初始化与数据准备

场景：客户临时发来一份orders_202405.csv，要求2小时内上线欺诈检测模型。我的操作实录：

1. 创建项目目录：mkdir fraud-detect && cd fraud-detect；
2. 初始化Git：git init && git remote add origin git@github.com:me/fraud-detect.git；
3. 创建requirements.txt，只写三行：

onnxruntime==1.16.3 pandas==2.0.3 fastapi==0.110.0

4. 下载数据并导入SQLite：

# 用pandas自动推断schema并建表 python -c "import pandas as pd; df=pd.read_csv('orders_202405.csv'); df.to_sql('raw_orders', 'sqlite:///data.db', if_exists='replace', index=False)"

5. 编写schema.sql，定义特征表：

CREATE TABLE features AS SELECT order_id, CAST(STRFTIME('%Y', order_date) AS INTEGER) - CAST(customer_birth_year AS INTEGER) AS customer_age, total_amount, CASE WHEN total_amount > 1000 THEN 1 ELSE 0 END AS is_high_value FROM raw_orders;

6. 执行python migrate_db.py，生成features表。

这15分钟里，我做了三件关键事：

• Git初始化即版本起点：后续所有变更都有追溯依据；
• requirements.txt极简：避免包冲突，pip install -r requirements.txt12秒完成；
• SQL定义特征逻辑：比Python脚本更易读、更易审计、更易回滚（删表重跑SQL即可）。

实操心得：永远先建schema.sql再写代码。我曾跳过这步，直接用Pandas生成特征，结果两周后业务方要求“把年龄计算逻辑改成按月份算”，我翻了23个Jupyter Notebook才找到原始代码，重写花了3小时。现在，改schema.sql一行SQL，migrate_db.py一跑，全量特征自动更新。

4.2 第16-45分钟：模型训练与ONNX导出

数据就绪后，训练流程必须原子化、可复现：

1. 创建train.py，核心逻辑：

import pandas as pd import numpy as np from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from skl2onnx import convert_sklearn from skl2onnx.common.data_types import FloatTensorType # 1. 加载特征 df = pd.read_sql("SELECT * FROM features", "sqlite:///data.db") # 2. 准备X/y X = df[["customer_age", "total_amount", "is_high_value"]].values y = df["is_fraud"].values # 3. 训练 X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2) model = RandomForestClassifier(n_estimators=100) model.fit(X_train, y_train) # 4. 评估 print(f"Test AUC: {roc_auc_score(y_test, model.predict_proba(X_test)[:,1]):.4f}") # 5. 导出ONNX initial_type = [('float_input', FloatTensorType([None, X_train.shape[1]]))] onnx_model = convert_sklearn(model, initial_types=initial_type) version = "v" + pd.Timestamp.now().strftime("%Y%m%d") with open(f"model_{version}.onnx", "wb") as f: f.write(onnx_model.SerializeToString()) print(f"✅ Model saved as model_{version}.onnx")

2. 运行python train.py，输出：

Test AUC: 0.8923 ✅ Model saved as model_v20240515.onnx

3. 验证ONNX模型：

# verify_onnx.py import onnxruntime as ort import numpy as np session = ort.InferenceSession("model_v20240515.onnx") test_input = np.array([[35, 1200.0, 1]], dtype=np.float32) result = session.run(None, {"float_input": test_input})[0] print("ONNX inference OK:", result.shape) # 应输出 (1, 2)

关键控制点：

• 训练/评估/导出在单文件完成：避免跨文件状态传递，减少bug；
• 版本号用日期而非随机字符串：v20240515比v1.2.3-alpha更易排序、更易关联业务事件；
• 导出后立即验证：防止ONNX转换失败却未察觉。

这30分钟，我完成了从数据到可部署模型的闭环。没有实验跟踪，没有超参搜索，因为Solo Practitioner的第一目标是“能跑”，不是“最优”。

4.3 第46-65分钟：API服务开发与本地测试

main.py是整个服务的心脏，我坚持一个原则：所有业务逻辑必须能在不启动Web服务的情况下单元测试。因此，我把核心函数抽离：

# core.py import onnxruntime as ort import pandas as pd def load_model(version: str): return ort.InferenceSession(f"model_{version}.onnx") def preprocess(raw_data: dict) -> np.ndarray: # 特征工程逻辑，纯函数，无副作用 return np.array([[ raw_data["customer_age"], raw_data["total_amount"], 1 if raw_data["total_amount"] > 1000 else 0 ]], dtype=np.float32) def predict(model, features: np.ndarray) -> dict: result = model.run(None, {"float_input": features})[0] return {"fraud_prob": float(result[0][1])}

然后main.py只负责胶水逻辑：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel from core import load_model, preprocess, predict app = FastAPI() class PredictionRequest(BaseModel): customer_age: int total_amount: float @app.post("/predict") def handle_predict(request: PredictionRequest): try: model = load_model("v20240515") features = preprocess(request.dict()) result = predict(model, features) return result except Exception as e: raise HTTPException(status_code=500, detail=f"Prediction failed: {str(e)}") @app.get("/health") def health_check(): return {"status": "ok", "model_version": "v20240515"}

本地测试三步：

1. uvicorn main:app --reload启动服务；
2. curl -X POST http://localhost:8000/predict -H "Content-Type: application/json" -d '{"customer_age":35,"total_amount":1200}'；
3. 验证返回{"fraud_prob":0.9234}。

这20分钟里，我刻意不做任何“高级功能”：不加JWT鉴权（业务方没要求）、不接Redis缓存（QPS<10）、不设限流（单机足够）。先让最小可行服务跑起来，再迭代——这是Solo Practitioner的生存铁律。

4.4 第66-72分钟：部署上线与生产验证

最后6分钟，是决定成败的时刻：

1. 编写ml-api.servicesystemd服务文件：

[Unit] Description=Fraud Detection API After=network.target [Service] Type=simple User=mluser WorkingDirectory=/home/mluser/fraud-detect ExecStart=/usr/bin/uvicorn main:app --host 0.0.0.0:8000 --port 8000 --workers 1 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

2. 启用服务：

sudo cp ml-api.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable ml-api.service sudo systemctl start ml-api.service

3. 配置Nginx反向代理（/etc/nginx/sites-available/fraud-api）：

server { listen 80; server_name fraud.example.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

4. sudo nginx -t && sudo systemctl reload nginx；
5. 最终验证：

# 1. 检查服务状态 sudo systemctl status ml-api.service | grep "active (running)" # 2. 检查Nginx代理 curl -H "X-Model-Version: v20240515" http://fraud.example.com/predict -d '{"customer_age":35,"total_amount":1200}' # 3. 检查日志 journalctl -u ml-api.service -n 20 --no-pager

当curl返回正确结果，journalctl显示prediction_done日志，我知道：服务已活。全程72分钟，从收到CSV到线上可调用，没有一次git push，没有一次CI失败，没有一次权限申请——所有操作都在我自己的终端完成。

5. 常见问题与独家排查技巧

5.1 问题速查表：高频故障与秒级定位法