做 Backend 以后发现，最可怕的不是报错，而是“什么都没报错” 😂

以前刚开始写 Backend 的时候，看到 error log 会很紧张。
现在工作久了以后发现，有 error 反而是好事，至少它告诉你哪里出问题了 😂
真正让人害怕的是：
用户说有问题，但是 dashboard 全绿，logs 也没有 error。
这种时候 debugging 就开始变成侦探游戏了。
先查 request 有没有进来 → 查 service logs → 查 DB → 查 downstream API → 查 timeout → 查最近有没有 deployment……
查了一圈全部正常。
然后你开始怀疑是不是用户操作错了 🤣
结果两个小时以后发现，某个 service 虽然一直返回 200，但是 response 里面的数据其实已经不对了。
那一刻真的会突然理解为什么 observability 不只是 logging。
以前准备 System Design 的时候，经常看到 logging、metrics、tracing 这三个词，当时觉得不就是“多打点 log”吗？
真正遇到 production issue 才发现完全不是一回事。
Log 告诉你发生了什么，metrics 告诉你什么时候开始不正常，而 tracing 才能帮你搞清楚一个 request 到底死在了哪一层。
现在看到一个新的 service，我第一反应已经不是：
“功能能不能跑？”
而是：
“出问题的时候，我要怎么知道它为什么没跑？” 😂
感觉这可能才是 Backend 从“能写代码”到“能维护 production system”最大的区别之一。
大家遇到过最难查的 production bug 是什么？那种最后发现原因特别离谱的 😂

太同意了，最吓人的永远是 200 OK 但数据错了。我们之前有个定时 job 天天显示成功，后来业务方跑来问怎么账对不上，一查发现半个月写的数据全是错的，关键它还天天绿灯，metrics 漂亮得不行😂 从那以后我查问题先不看 log，直接看数据对不对，metrics 绿都不信了。还有楼上说的 graphql 包 error 变 200 的操作真的窒息，全链路 tracing 没配好的时候查问题全靠猜，猜两次不中就直接认输。

怕的就是明明是error外面却包上一层200

bolun1234 发表于 2026-09-20 21:46:30
怕的就是明明是error外面却包上一层200

Graphql😳

bolun1234 发表于 2026-9-20 21:46
怕的就是明明是error外面却包上一层200

暴力通过unit test 和regression test，为了通过deployment pipeline掩盖error的常规操作。
local非常难复现和debug。
常见祖传代码，遇到了就只能猜了。

swli5 发表于 2026-09-21 04:32:23
Graphql

graphql骚操作之一
明明自己只是独立建立在http之上的应用端协议 偏偏要触碰http这一层的东西