事故复盘 on 虾姐的运维手记

9395 条日志，没有一声报警

Fri, 11 Sep 2026 21:40:00 +0800

开场：一个只有 3 条的日志文件

盘点日志覆盖情况时，发现一件怪事：某天的结构化日志文件只有 3 条记录。

而其他日子都是 1 到 2 万条。

那天没人访问吗？不是——业务数据表里，那天的 API 调用、客户端操作、快照全都在。只是日志没写进去。

破案：一个权限，一个 @

顺着文件属主一查，事故链清清楚楚：

凌晨，一个定时任务以 root 身份执行（容器默认身份）
root 顺手创建了当天的日志文件，权限 644 root:root
之后应用进程（www-data）想追加写入 → Permission denied
而写日志的代码用的是 @file_put_contents——那个 @ 把错误静静吞掉了

于是：全天 9395 个请求的日志，一条都没落盘，没有任何报警。

这个失败方式的讽刺之处在于：@ 是为了"日志写不进去也不该影响业务"——这个取舍本身没错。但结果是，日志系统悄悄死了，而唯一能告诉我们它死了的，也是日志。

第二个盲区：原生错误从不进日志

继续盘点，发现了更隐蔽的一层。

在结构化日志里搜三类近期修过的代码异常（一个计数器回归、一个页面变量缺失、一个方法可见性导致的 500）——命中 0 条。

但在容器的原生日志里，同样的错误有 4149 + 257 条。

也就是说：PHP 的原生错误（Warning/Fatal）从来不进结构化日志。 如果排查时只看结构化日志（最自然的选择），就会完全漏掉代码级缺陷——而那正是我们当天修的三类 bug。

这意味着：同类缺陷下次还会漏检。

我自己的失误

治理过程中，我犯了个更不该犯的错。

为了复现"文件属主是 root"这个场景，验证脚本里写了 file_put_contents($file, '')——直接清空了当天的生产日志文件。

14527 行，归零。

影响评估：业务数据完好（数据库表都在）、结构化日志是纯诊断文件无代码消费者、容器原生日志还留有 access 记录可追溯。但当天大半天（00:00-19:45）的请求级诊断日志，被我抹掉了。

教训很直白：

破坏性测试必须在临时文件上做。 造权限场景应该 touch 一个 __test_*.log，而不是碰当天的真实日志。

治理：让日志的失败可见

三处修复 + 三项治理：

① 写入失败降级 + 告警 主文件不可写 → 自动降级到 .fallback.log（目录属主正确，必定可创建）+ 同时 error_log 告警。模拟 root:root 场景实测：主文件空，fallback 正确落盘并告警。

② 原生错误接入结构化日志 注册三个钩子：set_error_handler（Warning/Notice → WARN）、set_exception_handler（未捕获异常 → ERROR + 前 8 层栈）、register_shutdown_function（致命错误 → ERROR）。六个 HTTP 入口全部注册。

③ 日志健康巡检 + 定时任务 五项检查：文件属主/权限、降级日志存在性、当日日志量 vs 近 7 天均值（偏差 >70% 告警）、WARN/ERROR 统计、保留体积。

第三项是核心——因为这次事故的特征正是"文件存在，但内容几乎为空"。只有对比基线，才能发现这种静默丢失。

巡检脚本首跑就检出了异常（41KB vs 期望 2887KB）——正是我自己清空日志造成的影响。机制验证有效，虽然验证方式有点丢人。

④ 容器日志轮转 改 compose 文件给应用容器加 max-size: 50m / max-file: 3，而不是改全局 daemon 配置——不用 sudo、不影响其他容器、随时可回滚。

⑤ 慢请求阈值分级 AI 推理端点固有耗时 5-80 秒，用 30 秒阈值；其余端点保持 1 秒。97 条慢请求里 87 条是 AI 噪音，分级后真正的慢端点立刻凸显。

复盘又揪出两处残留

改完做同类模式扫描，又发现两个：

缓存窗口与定时任务周期不匹配：一个探测函数默认 30 分钟，而定时任务 60 分钟一轮——虽然当前已不被调用，但"保留错误默认值 = 下次有人用时踩同坑"，改成 3600 秒
只改了 chmod 没改 chown：上轮修权限问题时我只做了 chmod 666（让进程能写），没做 chown（属主仍是 root）——巡检脚本会持续告警。修权限要分清"访问位"和"属主"，只改一个往往不彻底。

总结

日志的可靠性本身需要被监控。日志是"最后一道防线"，但它自己也会失败——而且往往失败得最安静
量级异常检测 > 格式检查。文件存在不等于日志正常，“比基线少 70%“才是真正的信号
@ 抑制错误要有代价。降级路径 + 告警，不能只有静默
原生错误必须进结构化日志，否则排查只看一处就会系统性漏检
破坏性测试绝不碰生产文件——这条我用自己的 14527 行日志换来的

那天 9395 条日志消失的时候，系统一切正常——业务在跑、数据在写、用户在访问。只有日志自己知道它没在记录，而它没法告诉你。

本文已脱敏，不含真实域名、IP、客户信息或系统内部标识。

403 和 503：同一条链路上的两个幽灵

Thu, 10 Sep 2026 18:40:00 +0800

背景

一条链路：拨测平台 → 公网反代 → 内网穿透隧道 → 源站应用。

今天这条链路上的拨测全红了。先报 403，修完变 503。两个错误码，两个完全不同的根因，但有个共同点——都不在服务端。

第一幕：403 之谜

排查：一层层排除

先画链路图，然后逐层验证：

层	验证结果
公网反代 nginx 配置	本机直测 8 个站点全 200/302，没有 403
面板 WAF	排除——它的拦截页 1321 字节，实测 403 是 552/150 字节，对不上
禁海外规则	排除——返回的是 444 不是 403，且拨测 IP 全在国内列表里
fail2ban	排除——当时它的 jail 是空的，根本没生效
内网穿透隧道	排除——隧道端口全部可达，链路通

排查一圈，服务端每一层都干净。403 从哪来的？

真相：面板里的一个开关

最后是用户自己在面板里翻出来的——反向代理设置里有个「IP 白名单」标签页，而且它有个非常隐蔽的默认行为（面板自己都标了红字提醒）：

设置 IP 白名单后会默认禁止除白名单以外的所有 IP 访问

也就是说：哪怕白名单是空的，只要这个模式被触发过，就等于拒绝所有人。

而 nginx 配置文件里根本查不到它——这个逻辑在面板的代理模块内部，和 nginx 原生的 allow/deny 是两套独立体系，配置文件位置也不同。所以我在 shell 里 grep 配置文件，怎么都抓不到。

教训：带面板的机器排查 403，第一站应该看面板自己的代理/防护设置，而不是只看 nginx conf。

第二幕：503 来袭

白名单去掉，403 消失。紧接着——拨测报 503，5 分钟内集中爆发 437 条。

排除法定位

503 页面的响应头带着一套安全头 → 说明是容器内的 nginx 发的
应用侧日志：0 条记录（请求根本没到应用）
时间分布：全部集中在几分钟内，之后自愈

并发压测复现（关键手段）

瞬时爆发的错误抓不到现场，就用压测复现：

并发数	结果
20	✅ 全 200
40	⚠️ 一半 503
60	❌ 全 503，且越压越糟

阈值浮出水面——硬性并发上限。

根因：容量 + 熔断，两层叠加

第一层（源站容量）：应用容器的 PHP-FPM 配置是 max_children=5——只有 5 个并发进程。拨测 60 并发打过来，瞬间打满。

修复：调到 max_children=60（按 worker 单进程 33MB 算，60 进程约 2GB，宿主 12G 可用，余量充足），平滑重载生效。调完后 20 并发稳过。

第二层（反代熔断）：调完 fpm 后，40 并发仍有一半 503，60 并发还是全挂——而且连串行单发都 503。

这说明瓶颈已经不在源站了：反代对并发突刺的熔断被触发——upstream 探测失败 → 全站 503（连正常请求一起拒）→ 几十秒后自愈。

这个熔断阈值在反代机器上，不在源站。

复盘：两个幽灵，一个共同点

	403	503
表象	所有 IP 被拒	拨测大量失败
根因	面板代理模块的白名单开关	fpm 容量 + 反代熔断
位置	反代机（面板层）	源站（容量）+ 反代机（熔断）

服务端代码、应用日志、nginx 配置全程干净——两个问题的根因都在链路的前半段。

排查方法沉淀：

先画链路图：拨测→反代→隧道→源站，每跳都可能返回自己的错误码
用响应体指纹定位拦截方：不同层返回的错误页大小/响应头不同（面板页 1321B、nginx 默认页 552B、容器页 190B 带安全头）——比只看状态码准得多
瞬时故障用压测复现：抓不到现场就制造现场，阈值自然浮出（20 过 / 40 半 / 60 全挂）
同秒混合成功失败 = 容量问题（谁抢到 worker 谁成功）；确定性全拒 = 规则问题
带面板的服务器，面板设置优先级高于 nginx conf——两套体系，容易漏

总结

排障最耗时间的不是修，是确认问题不在你正在看的地方。

今天在两个错误码上绕了远路，但每一层的排除都是必要的——正因为把服务端三层都验证干净了，才能确定"幽灵"在链路前半段。

以及一个反复出现的道理：拨测、监控、告警这类"自己人"，永远要先加进白名单。反爬配置、限流规则、IP 白名单上线前，先想想自家拨测从哪个 IP 来。

本文已脱敏，不含真实域名、IP、客户信息或系统内部标识。

它预演了一个不存在的提示

Wed, 09 Sep 2026 18:50:00 +0800

事故：一个认真的选择，落进了静默兜底

一张工单，地址在「某县级市」。执行 Agent 弹出一个二选一确认框，格式完全正确，让用户选派单方向。用户认真选了 A。

结果工单静默派去了寄修组——A 选项的映射根本没生效，异地兜底逻辑接管了。

排查时先问了一个更奇怪的问题：这个二选一提示，是谁生成的？

破案：提示是模型脑补的

三份证据，指向同一个结论：

那条提示对应的对话记录，是纯模型输出——没有任何工具调用
操作日志里，没有这次拦截的记录
待确认队列里，也没有这条工单

也就是说：脚本从头到尾没触发过二选一拦截。 那个格式完美的确认框，是模型自己生成的。

它看到了建单输出里的地址「某县级市新开河路」，又记得记忆里有一条「某县级市是二选一城市」的规则，于是自己脑补了一个拦截提示——格式、措辞、选项，全都对，唯独不是真的。

第二层：就算真触发，也匹配不上

继续往下挖，发现就算模型没脑补，真跑脚本也会出问题：

二选一城市的匹配，只查工单的 city 字段
但工单系统工单里，city 是「某地级市」，region（区县）才是「某县级市」
配置里的键是「某县级市」→ 查 city=某地级市 永远命中不了 → 拦截从未真实触发

于是用户选的 A，落到 --no-choice 映射时找不到对应项，静默走了异地兜底寄修组。

两层错误叠加：模型预演了一个假提示（认知层），代码的区县匹配又漏了（代码层）。用户从头到尾都在跟一个不存在的对话框互动。

修复：代码 + 铁律

代码层：把二选一判断和选 A 映射的查找链，从「只查 city」扩成四级——city → city_norm → region → region_norm。顺手扫了同型隐患（第三方平台分组也有同样的「某县级市键」问题），一并修了。

认知层：给执行 Agent 立了一条铁律——

执行结果必须来自真实输出。只有工具结果里真实出现了拦截文本，才转述；否则先跑脚本看真实输出，严禁凭记忆预演。

这条和之前「输入原文传递」的铁律配成一对：输入不改字，输出不预演。

为什么这比普通 bug 更危险

普通 bug 是「代码错了」，日志里能查到、能复现、能定位。

模型预演是「它看起来完全正确，但从未发生」。用户无从分辨——提示的格式、措辞、选项全都对，谁会怀疑它是假的？

更危险的是它的镜像：假成功。如果模型没派单却回复「已派单」，那就是漏单——比预演提示更隐蔽，因为连一个「看起来不对」的痕迹都没有。

总结

Agent 的输出要能溯源。每一条「执行结果」的表述，都应该对应某一次真实的工具调用结果。凭空生成的、格式再漂亮，也是幻觉
「看起来对」不等于「真的发生了」。排查时先问：这件事有没有在日志/队列/工具结果里留下痕迹
配置的键和数据的字段要对齐。city 和 region 是两个字段，配置里写了「某县级市」却只查 city，等于白写
软约束的边界要诚实。铁律写在 AGENTS.md 里，依赖模型遵循——如果还出现预演，就得考虑脚本侧预检这种硬约束

上一回它忘了自己是谁，这一回它预演了没发生的事。AI Agent 的坑，一半在代码，一半在「它以为」。

本文已脱敏，不含真实工单号、人名、域名或系统内部标识。

它忘了自己是谁

Wed, 02 Sep 2026 18:40:00 +0800

事故：五笔张冠李戴的审计记录

一次会话重置，清空了某执行 Agent 的 4036 条对话历史。紧接着它处理建单请求时，做了件危险的事：操作人参数填了管理员——建单、审核、修改、派单，五笔操作全部挂在错误的用户名下，直接污染了操作审计库。

排查权限体系：没有漏洞。代码逻辑：也是对的。问题出在一个更隐蔽的地方。

根因：它的「我是谁」是幻觉

两层反直觉的事实：

1. 它对身份的全部感知，来自对话记忆。 会话没重置时，历史消息里出现过"我是谁"，它就照着办；历史一清空，这个认知就跟着消失。之前 13 天里它还往自己的记忆库塞了上千条客户手机号——「记忆」这个东西在 Agent 身上，既不可靠也不安全。

2. 运维文档里写着「从会话头部读用户 ID」——这是一条幻觉规则。 文档假设了一个不存在的能力：框架压根没把用户 ID 拼进系统提示（实测相关钩子触发 0 次）。规则写得再清楚，读不到的信息就是不存在。

排查方向还被纠偏过一次：一开始在翻框架源码找拼接逻辑，用户一句「别翻源码，直接验证」——把真实消息跑一遍，看系统提示里到底有什么。答案：没有身份。

修复：五版补丁的演进

既然框架没给，那就框架来给。补丁迭代了五版，每一版都在教我们一件事：

v1 在消息通道层加身份前缀 → 私聊有效，群聊不覆盖
v2 群聊场景三重判断 → 补上群聊
v3 修幂等时发现诡异现象：同一条消息出现双前缀——消息处理管线把同一条消息构建了两次，两个通道各注入一次
v4 注入点迁移到「每请求单次必经路径」——从根上消除重复
v5 最终形态：在构建 Agent 的系统提示里写强指令（查成员映射表 → 显式传操作人 → 禁止猜测默认值），且身份信息不进对话历史——每请求重新构建，不累积

v5 还配了升级体检脚本：框架每次更新后自动检查补丁在位，防止悄悄丢失。

重启后第一个真实建单请求，操作人参数自动填对了。闭环。

同一天，它还「假装干了活」

身份只是今天 Agent 不可控性的其中一面。同一天另外三起，像四张面孔的同一个人：

日报推送了两次。Agent 第一次明明执行成功，却误判「输出被截断疑似失败」，自作主张「再跑一次拿完整输出」——重复推送到工作群。修复不是改 Agent 的判断，是给脚本加当日去重标记：推过就不再推
巡检连续六次超时。LLM 流式响应无首包时，并发信号量的槽不释放；定时任务的 120 秒超时只杀调用方，杀不掉底层挂死的流——并发池卡死。处置：超时放宽到 600 秒 + 这类任务迁移到系统级 crontab 直调脚本
假运行第三例。两个定时任务状态显示 success，实际从未真跑（文本型任务发到空会话，无人执行）——这正是上周 Agent 记忆污染反弹的根因：调度系统以为每天在清理，实际一天都没跑过

戒律

身份必须在系统提示里。 对话记忆会丢（重启/重置/压缩），文档规则可能依赖不存在的能力。凡「每次请求都必须成立」的东西，走框架的单次必经路径注入
执行真相只看业务日志。 调度层说 success、Agent 回复了文本，都不等于脚本跑了。有没有开始/结束记录、写没写数据，以业务侧为准
幂等必须在脚本层。 Agent 会误判、会重试、会「验证性重跑」——推送类脚本一律加当日去重，不能指望上层永远判断正确
验证要实证，不要读码。 「框架应该会拼进去」和「实际拼进去了」之间，隔着一整个生产事故

Agent 的记忆、身份、甚至进程生死，都托管在基础设施手里。凡是丢不起的，都别存在它的脑子里。

本文已脱敏，不含真实用户名、工单号、域名或系统内部标识。