你不在生产环境，怎么排查问题？

说起来你可能不信，我入行 FDE 的第一周，就碰上一个"经典场景"。

客户那边凌晨三点发来消息，说他们部署的模型推理服务突然不响应了，API 网关超时率飙到 60%。客户运维在群里喊了一串感叹号，然后问我怎么办。

我当时的第一反应是——"能不能给我开个服务器权限？"

对方回了一句让我记到现在的话："我们生产环境不允许任何外部人员直连，包括你们厂商。"

你看，这就是 FDE 的日常。你服务的客户，你部署的系统，你写的配置文件——但你进不去。没有 SSH，没有 VPN，甚至连个跳板机都没有。你只能隔着屏幕，像医生远程给病人做手术一样，靠有限的"监控画面"和"症状描述"来诊断问题。

有意思的是，我后来发现，这种"进不去"的状态，恰恰是 FDE 和传统运维最大的区别。传统运维靠的是"我能在机器上跑命令"，FDE 靠的是"我不用跑命令也能知道问题在哪"。

你别说，这事还真有方法论。

先说一个最笨但最有用的办法：日志，还是日志，永远是日志。

我当时跟客户说，你能不能把最近的日志发我一份。客户甩过来一个几百兆的日志文件。我打开一看，好家伙，全是 INFO 级别的常规记录，一条 ERROR 都没有。这说明什么？说明应用层没有崩溃，问题可能在更底层。

我让客户把 Nginx 的 access log 和 error log 也发过来。access log 一看，发现从某个时间点开始，大量请求的响应时间从 200ms 飙到了 8000ms 以上。error log 里有一条特别显眼——"upstream timed out"。

这就很有意思了。Nginx 没崩，但上游服务超时了。上游是谁？是模型推理服务。推理服务超时，说明要么推理请求量太大了，要么模型推理本身变慢了。

你看，光靠日志，我就把问题范围从"系统不响应"缩小到了"模型推理层"。这一步在 FDE 的术语里叫"问题隔离"——你不需要进机器，只需要把日志当成"探针"，一层一层往里扎。

我知道有人会说，这不就是看日志吗，有什么难的？

说实话，看日志本身不难，难的是在"信息不足"的情况下做判断。你不在生产环境，看不到进程状态，看不到资源占用，看不到网络连接数——你只能靠日志里的时间戳和状态码，在脑子里重建系统当时的运行状态。这有点像法医破案，现场早就没了，你只能靠痕迹还原。

我后来养成了一个习惯，每次部署的时候，除了把功能跑通，还会额外做一件事：把关键日志的格式和内容跟客户确认一遍。你的 ERROR 日志到底打什么？有没有 request_id 做链路追踪？时间戳有没有毫秒级精度？这些东西在平时无所谓，但出了事，就是你的救命稻草。

客户那边后来把模型推理服务的日志也发了过来。我一看，推理服务的日志里有一条规律：前 10 个请求都正常，第 11 个开始，推理时间突然从 50ms 飙升到 3000ms，然后一直居高不下。

我脑子里蹦出一个猜测——是不是显存被占满了？推理服务第一次加载模型的时候，把显存吃光了，后续请求排队等资源，所以越来越慢。

但问题来了，我一个外部 FDE，怎么看客户的显存？我连服务器都进不去。

这时候第二个方法就派上用场了：最小复现。

我跟客户说，你能不能写一个简单的脚本，就发一个推理请求，记录一下返回时间和资源占用？客户那边的人写了个 Python 脚本，跑了三次。第一次 50ms，第二次 52ms，第三次 3400ms。

三次就复现了。而且第三次慢的时候，脚本里顺手打了 nvidia-smi 的输出——显存占用 99%。

问题找到了。推理服务的内存泄漏，或者说，模型加载时没有释放上一个请求的中间变量。

你可能会想，这算不算"作弊"？让客户帮忙跑命令，跟你自己跑有什么区别？

说实话，区别挺大的。你让客户帮忙，就得把指令写得足够简单、足够安全。你不能说"帮我看看显存"，你得说"打开终端，输入这行命令，把输出粘给我"。而且每一步都要解释清楚——"这个命令不会改任何东西，只是看一下状态"。

我后来带新人，经常说一句话：FDE 的排查能力，不是看你多快能找到问题，是看你多快能教会客户帮你找到问题。

这也是我特别喜欢这个岗位的一点。你表面上是个工程师，实际上是个侦探加翻译。你要在信息极其有限的情况下还原真相，还要把技术问题翻译成客户能听懂的话，让他们配合你操作。

说回正题。问题找到之后，解决倒不算难。在推理接口里加了一个显存清理的逻辑，每次请求结束后释放中间张量。客户那边部署了新版本，再跑了一轮，正常了。

那天我从凌晨三点忙到早上七点，虽然全程没碰过客户的生产环境，但问题还是解决了。

这些经历让我总结了一个 FDE 远程排查的"三板斧"：日志隔离 → 最小复现 → 根因定位。每一步都依赖"信息"，而不是"权限"。你掌握的信息越多，对权限的依赖就越小。

当然，这套方法不是谁都能适应的。

谁适合做这样的远程排查？ - 能忍受"信息不全"的不确定性，不会因为没权限就束手无策 - 逻辑链条清晰，能从碎片信息里拼出全貌 - 沟通耐心，能把自己的技术判断翻译成客户能执行的操作

谁不适合？ - 习惯"先上机器看看"的排查方式，离开了命令行就不知道怎么下手 - 对模糊信息没有耐心，一定要看到全貌才肯做判断 - 不擅长跟非技术人员沟通，客户多问两句就不耐烦

说实话，我见过很多技术很强的后端工程师，转到 FDE 之后的第一关，就是这个"权限戒断反应"。以前在公司内部，所有机器随便上，所有日志随便看。到了 FDE 的岗位上，客户的系统你得先申请、再审批、再等窗口——大部分时候你根本等不到。

你猜怎么着？最优秀的 FDE，反而是在这种"被限制"的环境里成长最快的。因为你被迫去理解系统的运行逻辑，而不是靠"跑个命令看看"来蒙答案。

下篇我会聊聊 FDE 的沟通术——怎么跟非技术背景的客户聊需求，把"他们想要什么"翻译成"我们该做什么"。这可能是 FDE 所有技能里，最被低估的一个。

对了，你遇到过最离谱的远程排查经历是什么？有没有哪次是"连日志都拿不到，全靠猜"的？评论区聊聊呗。