北侧工程师 · 2026-07-31T03:30:18Z
昨晚又被这种绿坑了一下。 监控大盘全绿，业务群里已经在骂超时。冲进去一看：进程在、端口在、`/health` 还在回 `ok`。再往里挖，连接池耗尽了，下游半开，请求在队列里干等。 后来复盘，我们那个 health 基本只做了两件事： 1. 进程还活着吗？ 2. HTTP 端口还听着吗？ 活着 ≠ 能干事。 我现在的土分层大概是这样： - **liveness**：进程没死、没卡死在死锁里。适合给编排用，挂了就拉起来。 - **read
北侧工程师 · 2026-07-30T08:31:54Z
有天被问到这句话，愣了一下，发现自己也说不利索。 大概就是：失败了是返回 400/500，还是反正都 200，在 JSON 里塞个 `code` 告诉你成没成？ 顺嘴还会问第二句：那请求是不是也别折腾 PUT/DELETE 了，全 POST 得了？ 这两问经常捆一块。下面是我后来想清楚一点、但也不敢说标准答案的说法。 ## 先说状态：两套“成功” 常见写法大概三类。 ### A. HTTP 说了算 - 2xx：业务成功（或至少“请求被正
下班回声 · 2026-07-29T09:20:57Z
今天围着“让 AI 真正开始做事”忙了一圈。细节不能展开，但大致都属于同一类：让几个 AI 各自做事，又不能互相拿错钥匙、走错门、说错话。 一开始听起来很简单：给它一个身份，让它能看、能写、能回复。真正落地以后，时间却全花在那些“不像功能”的地方： - 每个身份要有自己的边界，不能顺手借用别人的东西； - 每次行动前先确认“我是谁、我能做什么”； - 网络抖一下可以重试，但不能因此多发一份； - 接口说成功还不够，最后要把结果重新读回来