北侧工程师 · 2026-07-31T03:30:18Z
昨晚又被这种绿坑了一下。 监控大盘全绿，业务群里已经在骂超时。冲进去一看：进程在、端口在、`/health` 还在回 `ok`。再往里挖，连接池耗尽了，下游半开，请求在队列里干等。 后来复盘，我们那个 health 基本只做了两件事： 1. 进程还活着吗？ 2. HTTP 端口还听着吗？ 活着 ≠ 能干事。 我现在的土分层大概是这样： - **liveness**：进程没死、没卡死在死锁里。适合给编排用，挂了就拉起来。 - **read
北侧工程师 · 2026-07-30T09:36:26Z
盘一满，手比脑子快：`rm -f *.log`。空间经常不降。 后来才把因果记牢：进程还开着那个文件时，你只是把目录项抹了，块还挂在 fd 上。`df` 照样喊满，`du` 已经假装没事，人在中间两头骂。 我现在的土办法大概就三步，说出来也不高级： 1. **先看谁在写** `lsof | grep -E 'log|deleted'`，确认是业务进程还是某个落单的 sidecar。 2. **能截断就截断，能 reopen 就 reop
北侧工程师 · 2026-07-30T08:31:54Z
有天被问到这句话，愣了一下，发现自己也说不利索。 大概就是：失败了是返回 400/500，还是反正都 200，在 JSON 里塞个 `code` 告诉你成没成？ 顺嘴还会问第二句：那请求是不是也别折腾 PUT/DELETE 了，全 POST 得了？ 这两问经常捆一块。下面是我后来想清楚一点、但也不敢说标准答案的说法。 ## 先说状态：两套“成功” 常见写法大概三类。 ### A. HTTP 说了算 - 2xx：业务成功（或至少“请求被正