AI开发牧安 · 第3期 技术选型

第2期说到，三级架构拍完板，接下来是选型。这事儿我在家翻来覆去想了几天，结论其实不酷，但很实用。

先说最大的约束：这东西最后不是跑在我自己机器上，是得跑到客户的机器上。客户的机器什么样？天知道。有的还是 Windows Server 2012，有的连外网都不让出。所以选型第一条不是"用什么先进"，是"到了那儿别让我再解释一遍环境"。

图片

不用任何框架，纯标准库硬写

干安全这行的，一提 Web 后台，本能反应是 Flask、Django、FastAPI 三选一。我没选。从头到尾，一个第三方 Web 包都没 pip install。

后端就是 http.server 裸写路由，配 sqlite3 存数据。三级平台那个主程序 Shepherd_l3_app.py，满打满算就靠 Python 自带的两样东西撑着。一级、二级同理。

为啥这么寒酸？因为我想象过一个场景：客户现场一台没网的 Windows 服务器，我远程指导对方"你先 pip install flask"——然后卡住，因为没有外网，没有轮子，IT 还不在。这一下，服务就黄了。

用标准库，就没有这出。复制过去，能跑就是能跑。代价我认：路由得自己写，JSON 得自己拼，文件上传的 multipart 得自己拆。

是体力活，但体力活比"现场装不上"强。Shepherd_l3_app.py需要的就是开盒即用。

数据不上云，本地 SQLite 兜底

数据离场更是麻烦。客户的资产、告警、日志，默认全留在客户现场。

所以存储就一层本地的 SQLite。三级那个库叫 safety-net.db，第一次启动自己就建好了，连个 instance.json 记客户名和联系人，也是自动生成。二级本地的库同样 SQLite/PG 都行，断网了照跑不误。

这不是为了情怀，是合规红线。客户的东西，出了他的门，责任就说不清了。平台只报到云端中心的是聚合后的态势，不是原始数据。这点从总纲里就定死，后面没松动过。

至于safety-net.db万一被搞走了，直接明文了，怎么办，那个大概是二十期之后的事情了。反正平台和数据库解耦的模式，换上别的库，能跑了，再研究加密。

断网也得能干活

基于之前的一些项目经验：客户的网络，经常比我想的更脆。

所以二级、三级都做了断网自愈。三级本机有本地缓存和队列，网络一断，数据先堆着，等连上了再续传。二级本地平台更干脆，断网就当单机用，资产、检查、报告照常出，等跟一级通了再把态势补报上去。

这部分没啥好炫的，就是"别让客户断了网把我的服务搞趴下"。

一个产品，两种长相

这步是我后来拍板的：同样一套逻辑，Windows 和 Linux 打包成两副样子。

Windows 这边，直接 PyInstaller 打成 exe。双击 Shepherd.exe 就起，单文件夹、零依赖，复制走就能用。打包脚本 build_windows.spec 里把抓包那套 scapy 直接 excludes 掉——因为 Windows 形态只跑主机内 Agent，不携带可运行的抓包能力，这是当时定的规矩。

Linux 那边不打包 exe，直接跑 Python，但能上流量探针。装个 scapy，给 python 授权 CAP_NET_RAW，跑 run_probe.sh，探针就接在交换机镜像口上被动听流量了。Windows 上那套抓包界面是自动藏起来的，调 /api/probe/* 直接回 {"supported":false}。

为什么要分？因为抓包在 Windows 上又笨重又容易踩坑，而流量探针在安全运营里又确实是 Linux 的活儿。与其两头凑合，不如各管各的。

选这套，认的代价

说白了，我的选型哲学就一句：能复制就跑，比什么先进都重要。

标准库写路由累是累，但客户那边不用陪我折腾环境；SQLite 没集群没分片，但一个小客户的量，绰绰有余；断网自愈多写几十行，但真出了事不会全线崩。

在家折腾这些，经常是下午想通一个点，晚上就把 subprocess 调 schtasks 的自启脚本改了又改。没什么高深，就是顺着"到了客户机器上别掉链子"这条线，一点点把路蹚出来。

选型定了，骨架也就清楚了。下期聊聊，怎么用这套零依赖的骨架，堆出一个能登录、有权限、真能收数据的后台。

本系列记录牧安平台从 0 到 1 的开发过程，一个待业在家的网安老兵边做边想。

上期：《做着做着，一个后台装不下了》；下期：《 那个后台是怎么堆出来的》。