© 本文著作权归作者所有，转载前请务必署名
凌晨三点，磁盘告警响了——不是业务暴涨，是某个接口在循环里打了 log.info，一天滚了 80GB。更讽刺的是，真出故障时，运维在几 TB 日志里搜 ERROR，关键信息淹没在噪音里；还有些地方只打了 e.getMessage()，堆栈根本没落盘。日志的目标只有两个：出问题能定位，平时别拖垮系统。
上周排查一个商品列表接口：P99 1.8s，代码 50ms，DB 30ms，CPU 35%——横向加了实例，单节点出口带宽规格没升，还是慢。最后发现是出站带宽打满了，利用率 96%。响应体在发送队列里排队，客户端才觉得卡。这类问题 Java 后端不罕见，排查清单里却常漏「带宽」这一项。一、带宽打满是
有一次线上告警没响，CPU 也正常，用户却在群里说页面转圈。我 curl localhost:8080/api/order，30 秒没反应。进程在、端口也在听——这就是服务假死：JVM 没挂，但已经接不住新请求了。一、假死和真死，别搞混状态进程端口业务请求真死退出连不上直接失败假死还在跑能连上超时、
OpenSpec：AI 编程先对齐需求，再写代码 用 Cursor 写功能，聊着聊着、代码也出了，合并才发现理解偏了——需求只活在聊天里，关窗口就没了。OpenSpec 是 规格驱动开发（SDD，先写清"系统应做什么"再写代码） 的轻量框架：写代码前先在仓库对齐「系统应做什么」
用 Cursor 或 Claude Code 写代码，你可能反复解释同一件事：PR 怎么写、commit 格式、发版前要跑哪些检查……每次新开对话从头教，费嘴也费 Token。Skill 把这类「怎么做」沉淀成 可版本控制、可跨工具复用、按需加载 的说明包——相关任务才翻开全文，而不是整本手册常