背锅侠日记 - 技术博客
Redis 官方免费云实例:博客开发环境终于不用开虚拟机了
我的博客后端用 Redis 做缓存和访问计数,启动必须连上 Redis,否则服务直接挂。以前每次本地改代码都得先开虚拟机把 Redis 跑起来,又慢又费电。 前两天发现 Redis 官方有免费云实例(30 MB 档),适合开发环境临时用。注册时 GitHub 登录报错——邮箱设成隐私不可见导致,换 Google 账号一次成功。 流程:选免费 30 MB 计划 → 香港 Region(ap-east-1)→ 默认账号密码(或 Data Access Control 自定义)→ redis-cli 跑 info 验证 → 改 settings.yml 的 redis.url / password,日志出现「Redis 初始化完成」即接好。…
LVM thin pool 元数据占满,引发的 MySQL 事故复盘
备份从机MySQL 某天突然自己退出,栈帧显示 InnoDB 在复制回放写入时于 os_file_flush 触发致命失败而就地自尽。根因不在数据库,而在底层 LVM thin pool 元数据 LV 占用 100%(数据才 47%):元数据记录块分配映射,满格后任何需新分配块的写入都落不了盘。这雷是此前库膨胀加盘时埋的——只扩了数据空间,忘了独立元数据 LV(仅 520MiB)。修复:VMware 加 1T 盘,pvcreate/vgextend 后 lvextend --poolmetadatasize +2G 把元数据扩到 2.51GiB,Meta% 由 100 降到 20.25,再扩数据池与 root 各 900G、xfs_growfs 在线刷新、重启恢复。教训:df 只看数据层,thin pool 的 Meta% 才是隐形杀手,须单独监控、预留空间。…
给数据库备份"减负":从本地落盘到流式直传对象存储的踩坑之路
这是一篇从运维视角出发的复盘。我们的数据库每天做全量物理备份,最初的设计很朴素:先在本地产出备份文件,再上传到一套 S3 接口兼容的对象存储,本地只是"过路"。但库一大,这个看似人畜无害的流程开始反噬——备份产物把本地盘写满,触发硬盘告警;临时目录普遍不够大,于是给备份机挂 NAS 顶上,容量够了却慢且脆。更糟的是备份时间集中、表又多,xtrabackup 往临时目录同时写入海量中间文件,直接写错、进程卡死。兜兜转转,最终出路是把"先落盘再上传"改成"边产生边上传":用 rclone 做流式直传,备份流从产生那一刻就流向对象存储,本地几乎不再留一片叶子。本文记录这条从踩坑到收敛的完整链路。…
@agent.qq.com 邮箱开抢,好前缀只能改一次——手慢的没了
先说个扎心的现实:咱们现在用的那个私人邮箱,早就不干「通信」的活了。它现在就两件事——注册各种服务时随手填一下,收一堆验证码。你点开收件箱翻翻,验证码、注册回执,外加铺天盖地的广告,能划半天才找出一封真人写的信。 所以腾讯这个新出的 `agent.qq.com` 是干嘛的?按官方说法,就是专门给 Agent 收验证码用的独立邮箱。说实话,单看这功能,现在有点扯——验证码这玩意儿,至于专门整个邮箱出来接吗?但转念一想,好歹是腾讯亲儿子,域名就一个 `@agent.qq.com`,前缀先到先得。**功能可以以后再吐槽,ID 这东西,不抢就没了。** 私人邮箱已经够脏了,没必要再塞给 Agent 当垃圾桶。给它一个独立的收件口,才是正经用法。 重点不在「又多了个邮箱」。重点在这个邮箱的前缀是先到先得的,而且——注册好之后**只能改一次**。这两条加一块,意思就很明确了:好记的短前缀,现在不抢,以后就是别人的了。…
Claude Code失智对策小妙招:从"差不多"到"双方签字"
Claude Code 这把双刃剑我用快两年——平时省心,时不时就降智,没规律,每次是不同锅.这一年没少踩坑:migration 撞号、同事 KV 段被我手滑覆盖、加钩子测 8 个场景才敢上.痛定思痛后护栏摁进三层.文档层:我口述、cc 整理、另一 AI 复述校反复到几乎逐字一致;再开 session 让 cc 出步骤,我反问为什么嚼到能讲清;对账后丢给 cc,每功能 e2e兜底.对账层:陪练(我用 workbuddy)挑刺 2-3 轮.hook 层:真阻断、强提示、上下文注入三种梯度,CLAUDE.md 反复叮嘱都不管用的(像 dev=生产=同库)只能让 hook 物理拦截.三层摞起来,中型功能慢30%,事故率从月均 1 次干到 0.…
DeepSeek 峰谷定价来了:白天涨价一倍,牛马又要熬夜写代码了
DeepSeek 正式落地峰谷定价,白天 API 调用价格直接翻倍,精准覆盖 9:00–12:00 和 14:00–18:00 的标准上班时间。加上智谱、阿里云等厂商在订阅套餐里玩分时倍率,算力行业的"峰谷电价"已成趋势。偏偏开发者的正经干活时间全在晚上——白天被会议占满,加班才能安静写代码调 AI。峰谷定价一落地,白天开会摸鱼混过去、晚上熬夜赶工省 token 成本,活生生把加班搞成了省钱刚需。本文盘点了各家分时计费的玩法,顺带算了笔账:账面上省的是 Token 成本,背地里耗的是我们的下班时间。…
固定Token套餐小妙招:既省Token又不丢失上下文
最近一直用 Claude Code 做项目迭代,踩了一个特别折磨人的坑:明明只是改几行简单代码、修复小Bug,Token 消耗却疯狂暴涨,轻轻松松干掉几千万 Token。而且经常没几次会话上下文就100%了。 一开始我特别费解,改动逻辑一点不复杂,为什么 Token 消耗会爆炸式增长? 折腾复盘了好几天,彻底摸清了固定时间窗口+周总量Token套餐的消耗逻辑,也摸透了 AI 代码助手的上下文堆叠规则。今天把这套「省Token、不丢上下文、提升迭代效率」的实战技巧完整分享出来,专门适配和我一样用包月/固定额度套餐的开发者。…
代码审查进阶:我用 3 个 LLM 揪出 2 个博客安全漏洞
上篇设计了"多 LLM 互喷辩论"的代码审查方法论,但偏演示性质。这次我动真格的:用 codex、qoder、workbuddy 三个大模型,对我的博客 e2e 测试框架(394 个用例)完整跑了一遍"审查 → 辩论 → 复核 → 修复 → 验证"全流程。结果揪出了 2 个真生产安全漏洞(公开 API 泄露草稿、JWT 撤销缺失),以及 1 个"跑了但没断言"的摆设测试。最终 5 个 PR 全部落地,测试从 394 条增至 399 条,全绿通过。本文是完整实战记录,包含工具选型、互喷过程、修复细节和踩坑经验。…
代码审查谁说了算?我让 3 个 LLM 互喷到一方服
我平时 90% 的代码活靠 Claude Code,但有个问题它解决不了 —— 它自己审自己写的代码,我总不放心。同一天我跟同事吃饭,他随口说:"现在会薅很多 agent 的羊毛做代码审查。"我眼睛一亮 —— workbuddy 和 qoder 那俩免费工具我平时基本不开,免费额度反正放着浪费,这次的事正好用上,凑 3 个 LLM 一起审 6 万行 Go 后端。…
踩坑记录:OpenAI Codex 设置中文失效?一招搞定
最近 OpenAI 的 Codex 火了,作为一个爱折腾的开发者,我当然第一时间打开了 Windows 应用商店,搜索、点击、安装,一气呵成。打开应用的那一刻,看着清爽的界面,新奇劲还没过,然后我打开设置,想把界面语言切换成中文——毕竟母语看着亲切嘛。 改了设置,重启 Codex,界面纹丝不动,依然是一口流利的英文。我以为是自己操作不对,又改了一遍,重启,还是不行。 作为一个有经验的技术人员,我开始了经典的排查三连......…