服务故障先分层，再看业务代码

同一种超时可以来自六层。先判断落在哪一层，再打开那一层的日志。从业务代码里的异常栈开始搜，经常是入口或发布已经错了。

网络和入口：DNS、端口、防火墙、负载均衡或网关、证书。502、504、403、connection refused 先看这里。

进程自己：OOM、死循环、依赖的服务还没起来、环境变量或数据库地址写错、依赖升级后接口对不上。

数据库和缓存：连不上、连接池耗尽、死锁、缓存击穿，或者缓存和库已经不是同一份数据。

机器：CPU、内存、磁盘、文件句柄。对应 OOMKilled、no space left on device、too many open files。

外部依赖：对方失败、凭证过期、被限流。403 和 429 先看对方，而不是先改自己的重试次数。

发布：容器起不来、镜像拉不下来、环境变量没有带上、线上的包和本地不是同一个版本。

提问

让模型参与排查时，问题本身按四个槽写。角色限定它站在哪一层看。任务写清要的产物，例如「指出最可能的一层，并给出要看的一条日志」，而不是「看看」。格式指定分点或表格。边界写明不要什么，例如不要同时给一套新架构。

输出不稳定时再加两种约束。给一个已经做好的例子，让后面的回答沿用格式。或者要求按步骤来：先解释现有路径，再指出和症状相符的一层，最后才给改动。步骤和例子不是每次都写上。四个槽每次都写。