记录牧安平台从 0 到 1 的开发过程一个待业在家的网安老兵边做边想。第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 的开发过程一个待业在家的网安老兵边做边想。上期AI开发牧安 · 第2期 做着做着一个后台装不下了下期AI开发牧安 · 第4期 那个后台是怎么堆出来的。