Windows数据科学环境搭建：9年漏洞研究员的避坑与提效实战

　　去年11月份接了个活儿，帮某数据科学团队搭Windows环境——这活儿本身不复杂，但架不住甲方要求“既要又要还要”：要Anaconda全组件，要CUDA加速，要PyTorch最新版，还要VS Code远程开发，最后还补一句“别用WSL，我们就要原生Windows”。我原以为这不过是个配置文件改改的事，结果第一天就踩了三个坑，其中两个直接让虚拟机蓝屏——那台老式戴尔工作站的风扇声，从“嗡嗡”直接飙到“直升机起飞”，吓得隔壁工位做渗透测试的老张，把刚泡好的枸杞茶泼在了键盘上。

　　第一个坑是Anaconda的版本冲突。甲方非要用Anaconda3 2023.09版，说是“新版本更稳定”——我信你个鬼，这版本刚出两周，连官方文档都没更新全。装完发现PyTorch 2.1.0死活装不上，报错“conda.Context.rc_path not found”，查了半天发现是Anaconda的配置文件路径改了，但PyTorch的安装脚本还在用旧路径。我原以为改个环境变量就能解决，结果改完重启，VS Code的Jupyter内核直接崩了——后来才发现，Anaconda2023.09把默认的Python版本从3.9改成了3.11，而VS Code的Python扩展还没适配，得手动降级。那天下午，我在虚拟机和物理机之间来回切换，键盘都快敲出火星子了，老张在旁边看热闹，说了句：“你这环境搭得，比我挖0day还费劲。”

　　第二个坑是CUDA和显卡驱动的兼容性。甲方用的是NVIDIA Quadro P2000，这卡不算新，但驱动版本得卡在470.57.02——因为PyTorch 2.1.0的CUDA 11.8只支持这个版本。我原以为直接去NVIDIA官网下驱动就行，结果装完重启，设备管理器里显卡显示“代码43”，蓝屏代码是0x0000007E。查日志发现是驱动和Windows的Hyper-V虚拟化冲突——甲方之前为了跑Docker开了Hyper-V，但NVIDIA的驱动在Windows 11 22H2上和Hyper-V不兼容。最后只能二选一：要么关Hyper-V，要么降PyTorch版本。甲方选了前者，结果Docker又没法用了，又得重新装WSL2——这时候他们才承认，之前说的“不用WSL”是老板拍脑袋决定的，实际开发还得用。那天晚上，我蹲在机房里改配置，外面下雨，雨滴打在窗户上，和老张的键盘声混在一起，像在给这场闹剧打拍子。

　　第三个坑是VS Code远程开发的端口冲突。甲方要求用SSH远程连接，但他们的内网环境复杂，防火墙规则一堆，我原以为用默认的22端口就行，结果测试时发现连不上——后来才知道，他们的运维之前为了“安全”，把所有非80/443的端口都禁了，连22都不放过。最后只能改用3389端口，结果又和RDP服务冲突，蓝屏代码变成了0x000000D1。我打电话给运维，对方是个刚毕业的小哥，声音都在抖：“哥，这端口我真不敢开，上次开22端口，老板说我泄露公司机密……”最后没办法，只能让甲方在本地装VS Code，用本地内核跑——这时候他们才承认，之前的“远程开发”需求是老板看了一篇“高效协作”的公众号文章后加的，实际根本没人用。那天我改完最后一行配置，抬头一看，老张正趴在桌上打呼噜，桌上放着半包辣条和一杯凉透的咖啡。

文章配图，仅供参考

　　现在回想起来，这活儿最坑的不是技术问题，而是甲方的“既要又要还要”——他们自己都没想清楚要什么，就让我们搭环境，结果改需求比改代码还勤。我敢打包票，如果他们不先明确需求，下次搭环境还得踩同样的坑。至于我，下次再接这种活儿，得先签个“需求变更免责条款”——否则，真怕哪天被甲方逼得去写漏洞利用代码了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!