- 博客(15)
- 收藏
- 关注
RSS订阅原创 把服务器当代码管
一次例行的反向代理升级，我服务器上所有站点断了九十秒。配置没动过，升级本身也很顺利。最后的解决办法是给一个文件改个名，至于为什么改名就好了，那是另一篇文章的事。让我记住的是之后的事：原因写进了仓库的 README，一个专门查这种故障的检查从此每天跑两次，而这两样东西都是以 commit 的形式进去的，跟这台机器上的其他东西一样。这就是的出发点：把真实的服务器当成一个程序来运行。上面跑什么，以 Git 为准；改动走 commit 和 push，而不是 SSH 上去东改一下西改一下。
2026-10-20 14:08:42
165
原创 我把所有服务搬上 Kubernetes，又全部搬了回来
作者在两周内将六个自托管服务从Docker Compose迁移至Kubernetes，实现完整GitOps闭环，但随后全部撤回。核心洞察在于：Kubernetes的价值仅在“自己编写、持续迭代的软件”上才能回本。第三方镜像作为消费型服务，无需金丝雀发布、服务网格或严格安全策略，强行部署反而带来跨层故障与运维负担。最终保留的仅为自研或实验性应用，印证了“平台为生产者而建，非消费者而设”。真正的能力不是工具本身，而是清晰区分“谁掌握变更”的边界——数据归我用Compose，代码归我则上K8s，否则便是为运维成本
2026-09-14 11:37:03
329
原创 Claude Code Recommended: 放弃
这篇文章记录了作者在Kubernetes集群上排查Istio Ambient Mesh网络问题的全过程。问题出现在PR预览环境的请求始终被路由到baseline pod而非目标pod。经过9小时的系统排查排除了众多可能性后，AI助手Claude Code建议标记为已知限制。但作者启用独立调查subagent后发现，真正的根源在于Cilium的socket-level负载均衡配置更新后未触发DaemonSet重启，导致实际运行配置与ConfigMap声明不符。最终通过重启cilium-daemonset解决问
2026-08-19 15:10:20
174
原创 Synced, Healthy, Running, Wrong
摘要：作者记录了两起由系统告警触发的故障排查案例，揭示了现代云原生系统中多层监控的"沉默失效"现象。第一起是Jaeger服务因内存超限被OOM Kill后持续引发页缓存抖动，尽管各层组件（Kubernetes、ArgoCD）都报告"健康"状态；第二起是trivy扫描作业因YAML配置错误导致并发锁竞争，但配置校验层层通过。文章特别指出三类典型失效模式：内核记账与用户层认知偏差（63GB读取被记在未主动读文件的进程）、配置静默丢弃（Helm不提示无效配置项）、运行时逻辑与配置声明背离（operator读取配置
2026-08-18 16:04:05
219
原创 二十小时的引信
摘要：本文复盘了一起由VS Code插件内存泄漏引发的服务器故障。故障始于8月14日Claude会话卡顿导致进程堆积，经过20小时缓慢积累，最终在次日因内存压力引发IO风暴，导致四核服务器负载峰值达38.7。作者通过分析进程树、压力指标和内核日志，发现59个VS Code进程占用7.3GB内存的根源是旧版本客户端未正确关闭会话。解决方案包括：1) 精确清理僵尸进程树；2) 添加4GB swap作为缓冲；3) 建立基于PSI指标的预警系统。核心教训是：系统防御需要覆盖从瞬时峰值到缓慢泄漏的全时间尺度，而观察工
2026-08-16 00:01:33
351
原创 合拢这道流
本文详细记录了修复Claude Code Router流式传输卡顿问题的全过程。作者发现问题的核心在于插件无法处理高频率的增量事件流，于是设计了一个安全合并事件的中间件：它只合并同类型连续事件，严格保持语义不变，同时通过环境变量精细控制不同事件类型的合并窗口。部署过程经历了五次尝试才成功，从补丁API选择、进程树覆盖到文件持久化方案，最终通过NODE_OPTIONS确保中间件在所有相关进程启动时自动加载。修复后事件数量减少23倍，但受限于插件单事件250-400ms的渲染成本，仍残留部分延迟。文章特别强调，
2026-08-15 23:03:28
171
原创 两个钟，都没说谎
摘要：作者发现Claude Code插件在处理第三方API的长响应时出现严重延迟。通过分析发现，问题根源在于插件逐token处理事件导致渲染队列积压，阻塞了控制消息。虽然会话逻辑已结束，但通知系统和界面显示存在时间差。最终通过中间件合并事件流解决了性能瓶颈。文章揭示了流式处理中颗粒度与性能的平衡问题。（149字）
2026-08-15 22:57:48
210
原创 唯一不在机器上的事实
本文讲述了一次由Docker重启引发的网络故障排查过程。作者在重启Docker后，发现反向代理后的服务无法连接，而网关正常。经过层层排查发现：1）反向代理的白名单规则碰巧与重启后随机分配的容器地址一致；2）关键网关流量实际通过内部DNS覆盖规则直连，而非公网路径；3）根本原因是关键容器未固定IP地址导致重启后地址漂移。最终通过固定反向代理和网关的IP地址解决问题。文章揭示了网络配置中隐藏的假设和偶然一致性可能带来的隐患，强调了系统设计记忆对故障诊断的重要性。
2026-08-07 09:20:39
294
原创 什么都没变——除了一个内核模块
《当K3s遇见Docker：一次由网络规则引发的"血案"》 故障现象：k3s安装后，原有Docker容器网络出现异常，同一bridge上的容器通信超时。 根本原因： k3s安装时自动启用了br_netfilter模块，并将net.bridge.bridge-nf-call-iptables设为1 这使得原本不经过iptables的bridge内部流量开始被iptables处理 Docker遗留的过时raw表规则（针对已删除的bridge接口）拦截了这些流量 排查过程： 确认故障与网络层相关（连接超时而非拒绝
2026-08-07 09:19:03
343
原创 十九个子域名，一个被放行的 IP
本文介绍了一种利用泛域名解析和Nginx反向代理构建安全自建服务的方法。作者通过*.example.com泛解析将所有子域名指向同一VPS，结合Docker网络和Nginx Proxy Manager(NPM)实现服务快速部署，仅需填写容器名、端口等基本信息即可完成HTTPS发布。所有服务都通过共享的Docker网络通信，不直接暴露端口。 关键安全措施是在Nginx配置中添加IP白名单（包括网关容器IP和VPS公网IP）和基础认证，形成双重保护。尽管服务都使用公开域名和证书，但实际访问需要满足IP和密码双重
2026-08-04 07:06:39
216
原创 236 个测试全绿，要发布的版本还是坏的
这篇文章讲述了一个看似简单的时区bug如何暴露了测试中的深层问题。作者修复了一个时区解析bug后，发现原本全绿的测试在CI环境中出现了失败，最终挖掘出三个隐藏问题：(1)测试依赖宿主机时区导致虚假通过；(2)测试未正确处理Python版本的兼容性；(3)CI环境噪声掩盖真实错误。文章揭示了测试的局限性——全绿不等于正确，只有当测试在多种环境下运行才能验证代码的真实行为。作者总结道，真正的解决方案不是具体的补丁，而是养成在发布前通过完整CI矩阵验证的习惯，让不属于开发者的机器来检验代码的健壮性。这篇文章生动展
2026-07-24 13:56:50
180
原创 为什么我总是收不到 claude code usage reset 的通知消息?
这篇文章讲述作者在开发claude-code-notify工具时遇到的两个关键bug：一个是工具未能识别Claude Code的用量限制错误，另一个是工具错误地将credits不足误判为用量限制。问题根源在于作者最初忽视了官方文档中关于异步写入会话记录的警告，以及错误地依赖了一个多义字段。通过添加调试日志、实施重试机制、优先使用结构化载荷数据，并引入更精确的错误码判断，最终解决了这些问题。文章强调了对系统行为的深入理解、结构化日志记录的重要性，以及不能仅依赖表面现象做判断的教训。整个历程展示了如何通过系统化
2026-07-24 13:43:07
334
原创 那个反复出现的 bug
文章摘要： 本文通过作者开发两个AI辅助编程项目的对比，揭示了纯聊天式编程工作流的局限性。在第一个项目blockly-platform中，作者仅通过Telegram与Claude Code交互，导致同一类安全配置错误反复出现四次却未被及时发现，因为缺乏代码可见性和连续性跟踪。第二个项目programming-learning-platform进行了三项关键改进：1）使用IDE远程开发模式获得代码可见性；2）强制实施brainstorm→plan→TDD的严格流程；3）最终切换到VS Code+Remote-
2026-07-15 14:54:24
241
原创 消失的问题：远程 Claude Code 与三小时陷阱
那个任务已经在我的远程主机上跑了一阵子——那种我启动之后就转身离开的、长时间多步骤的活。我人在别处，手机忽然震了一下。是我自己写的一个小提醒工具发来的 Telegram 消息，它会在 Claude Code 的一轮任务需要我输入、跑完，或者挂掉的时候通知我——这样我就不用一直守着。这次是第一种：Claude 走到了一个它自己做不了主的决定，停下来问我。我没能及时看到那条提醒。
2026-07-14 14:36:49
250
原创 骗了我的那条 claude code 通知
这篇文章探讨了在多项目并行开发时，使用 Claude Code 遇到的"任务状态不透明"问题及解决方案。作者最初通过简单的 Stop 钩子发送通知，但发现后台任务和子代理会导致误报。通过分析会话记录中的 tool_use_id 匹配任务状态，最终开发出可靠的 claude-code-notify 工具，能在三种关键场景（任务完成、需要输入、出错终止）时通过 Telegram 准确通知。该方案特别解决了用量限制导致的多任务同时卡死问题，将原本需要手动检查的工作转化为可信的异步通知系统。工具已开源，支持一键安装
2026-07-12 00:19:54
238
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人