uxuuid-优快云博客

原创配置中心差点成了最大的漏洞：Nacos 三节点集群、鉴权加固与配置灰度实战（含 3.x 权限绕过处置）

那天早上九点十七分，同事在群里问了一句：“为什么 staging 的支付服务，连的是生产的数据库？我第一反应是不可能——我们明明给每个环境建了独立的命名空间，dev、staging、prod 三套配置互相不可见。可等我打开那台 Nacos 的控制台，花了几分钟翻完配置列表之后，手是凉的。那个控制台不需要登录。任何能访问到这台机器的人，都能看到全部三个环境的配置：生产库的连接串、几个第三方服务的密钥、一套还在跑的短信通道凭据。而且更要命的是，我随手在笔记本上对着公网扫了一下，

2026-10-22 21:40:18 229

原创为什么告警发出去了却没人看？Alertmanager 分组、抑制、静默与收敛路由实战（含告警风暴治理）

上上周六凌晨两点十四分，我被手机震醒，睁眼一看通知栏已经堆了三十多条，还在往上跳。那一夜我总共收到318 条告警：先是出口网络抖动，接着六台机器上的 Nginx 探活失败、数据库连接超时、应用健康检查失败、磁盘写入延迟升高……一条接一条，把手机刷成了瀑布。真正的问题是，我在被吵醒之后，花了整整二十分钟才从这三百多条消息里认出根因——出口网络抖动。而 318 条里有 289 条，是同一条网络故障在下游各个服务上留下的衍生告警。我明明有一套告警系统，却因为告警本身淹没了我，等于在最需要它的那一刻掉了链子。

2026-10-21 15:43:42 99

原创数据库盘被图片撑爆之后：单节点MinIO对象存储自建、纠删码配置与S3访问实战（含2026年版镜像替换方案）

那天凌晨两点半，我被 Prometheus 告警电话吵醒——MySQL 磁盘使用率超过 95%。爬起来登录机器一看，不是 Binlog 暴涨，也不是临时表没清理，是所在的那块系统盘，被 WordPress 上传的图片、备份文件、用户头像整整塞了 87GB，其中仅 2026 年下半年的媒体文件就占了 62GB。我当时第一反应是赶紧删文件腾空间，结果手快删了两个还在引用的附件，第二天早上被运营追着问为什么文章配图全裂了。文件和数据库放在同一块盘上，等于把定时炸弹放在保险柜旁边。

2026-10-20 17:32:45 268

原创单节点消息队列撑不过一次促销：RabbitMQ 集群与 Quorum 队列高可用实战（含经典镜像队列迁移与节点命名坑）

先说一个不是我的事故，但它让我立刻去检查了自己的 MQ。一个朋友的公司做电商，RabbitMQ 就一台，跑了快一年没出过问题。直到一次大促：流量翻了十几倍，队列开始积压，内存涨上去、磁盘写满，然后那台机器直接僵住。麻烦的地方不在于这台机器挂了，而在于它挂了之后，所有依赖它的业务全都停在那——订单创建要发消息、库存扣减要发消息、通知推送要发消息。消息队列是整条链路的中间那一环，它一死，上下游一起卡住。他们重启机器花了二十多分钟，积压的消息又多到把业务拖垮，前前后后折腾了两个多小时。

2026-10-20 17:01:01 329

原创从公共平台搬到自建：Gitea 私有代码托管 + Gitea Actions 流水线完整搭建记录

我先说三件促使我把代码托管搬到自己这边的小事。第一件：有个内部用的小工具，代码里带着一份真实的连接串，我本想放私有仓库，结果发现免费额度对“私有仓库的协作者人数”是有限制的，加到第四个人就卡住了。要么升级，要么把工具开成公开的——两个我都不想选。第二件：跑在服务器上的那个定时脚本，我改完之后忘记同步到仓库，过了半个月自己都分不清线上跑的是哪一个版本。公共平台的 CI 挺好用，但它是“代码在别人那里、构建也在别人那里”，我这边只是推了个包。

2026-10-19 14:40:09 219

原创网站挂了却没人告诉你？自建站点可用性监控实战：Uptime Kuma + 证书到期 + 域名解析监控

先说两件让我下定决心做这件事的小事。第一件：有天晚上我在外面吃饭，手机弹出一条读者留言——“你网站打不开了”。我打开一看，502。回到电脑前查日志，服务大约两小时前就挂了，是一个我改配置时的低级错误。但那两个小时里，我的服务器监控面板是全绿的：CPU 不高、内存不高、磁盘不高、进程……哦，进程确实没了，可我没配进程告警。第二件更尴尬：某个周二早上，我收到一封读者的邮件，说“你们网站提示证书不安全，我没敢继续”。我一查，HTTPS 证书三天前就过期了。

2026-10-19 14:29:01 329

原创 WordPress 找回密码邮件进了垃圾箱？从 PHP mail() 到 SMTP + SPF/DKIM/DMARC 的发信配置实战

网站发出的邮件，用户经常收不到。最早发现是在一个深夜。有个读者在评论里问我，说他注册了账号但一直收不到验证邮件，重置密码也石沉大海。我当时的第一反应是"是不是他邮箱填错了"，让他再试一次，还是不行。第二天我用自己另一个邮箱重新走了一遍注册流程——邮件确实发出去了，wp_mail()返回true，日志里干干净净，但我的收件箱里什么都没有。翻到垃圾邮件文件夹，它安静地躺在那里。找回密码的邮件，十次里有两三次用户反馈没收到；评论回复通知，我自己都很少看到；

2026-10-18 16:02:08 254

原创从旧服务器搬到新服务器：WordPress 网站零停机迁移完整实战（数据校验、域名切换、回滚方案）

第一次给网站搬家，我把它想得太简单了。那次是帮一个朋友的博客从一台旧机器换到新机器。旧机器还剩半个月到期，他急着让我把站挪过去。我当时想的是：文件打包下载，数据库导出，传到新机器，改改，完事。整个流程在我脑子里大概值二十分钟。结果第一天晚上我折腾到凌晨两点。首页能打开，但文章点进去全是 404；后台登录进去提示“重定向次数过多”；有几张封面图成了一个空白框；侧边栏的小工具全没了。最要命的是，我明明只改了两个字段，为什么整个站点像被人抽掉了骨架？

2026-10-18 15:47:30 146

原创从单机到三节点：Vault Raft 高可用集群与自动解封实战

上一篇把密钥从应用仓库里彻底搬进了 Vault，仓库里一个明文都没有了。爽了大概两个月，然后被一次主机维护教育了。那天主机商发通知说夜里有个维护窗口，会重启宿主机。我当时想的是"重启就重启吧，Vault 有数据落盘，起来再解封就行"。结果第二天早上打开面板，几个服务全是异常——ESO 拉不到密钥，Pod 卡在。Vault 起来之后是 sealed 状态，得有人拿着解封密钥分片去解。而钥匙在我家里那台笔记本的密码管理器里，我那会儿人在外面。等折腾回能操作的时候，服务已经挂了四十分钟。问题具体表现单点。

2026-10-17 17:24:34 315

原创从日志里翻线索到一条链路看清全局：Grafana Tempo + OpenTelemetry 分布式链路追踪实战

上个月有个用户反馈：下单页面偶尔会卡十几秒，但刷新一下又好了，频率低到没法复现。我当时的做法很原始——登机器，grep三个服务的日志，对时间戳。前两台的日志已经轮转掉了，第三台里倒是留着一行。等我把这条线索和前面几台的记录拼起来，**已经过去两个多小时，而真正分析问题只花了十分钟。**剩下那两小时全花在"找线索"上。这件事让我把链路追踪补上了。指标告诉我"P99 涨了、错误率有波动"，但它是一堆聚合数字，没有单次请求的概念；日志。

2026-10-16 23:40:40 212

原创从逐台翻日志到集中检索：Loki + Alloy + Grafana 搭建轻量日志系统实战（含 LogQL 查询与日志告警）

事情的起因很朴素：有天下午一个后台接口开始间歇性报错，我要查日志。于是我打开终端，第一台机器ssh上去，翻了五分钟没看到异常；想起来接口是在第二台上，又连第二台；这时候第一台的日志已经滚过去一大截了。等我连到第三台，第二台那段关键报错已经被 logrotate 切走了。最后这件事花了快两个小时，其中真正“分析问题”可能只有十分钟，剩下的一小时五十分钟，全都花在**“去哪台机器上找这段日志”**这件事上。复盘的时候我意识到问题不在排查能力，而在日志的位置。

2026-10-16 18:21:08 206

原创从被动等队列到主动按画像提前拉：GPU 推理服务预测性保温四条路线实战

44 秒左右。量出来之后，问题并没有解决，只是变清楚了——这个 44 秒花在哪儿、能不能不花。我一开始的想法很朴素：把调小、把阈值调低、把scaleUp调激进，让“发现队列”这一步更快。配完确实快了几秒，但很快意识到自己调错了地方。被动伸缩的软肋，从来不是反应速度，而是它的信息来源。一旦开始排队，我拿到的是“请求已经进来了”，然后才去拉副本，副本还要加载模型。这条链路上，用户等待的时间几乎全在“请求已经来了、但服务还没起来”这一段。用户请求到达│├─ 请求进入队列 ← 用户开始等│。

2026-10-15 19:54:27 221

原创从手动 helm upgrade 到合并即发布：GitHub Actions + Helm 自动化部署实战（镜像构建、Chart 打包、多环境发布完整记录）

事情是这样来的。前面那篇把服务改造成 Helm Chart 之后，我确实爽了一阵子——升级一条、回滚一条，比手搓 YAML 舒服多了。Chart 是包好了，可发版的整套动作还是我一条一条在本地敲的。本地git pull拉最新代码构建镜像，推仓库把 Chart 里的镜像 tag 改成刚推的版本升到集群出问题再看着就五步，但每一步都靠我记着、靠我手敲。忘了改镜像 tag。代码推上去了，镜像也推了，但 Chart 里写的还是上一个版本，

2026-10-14 17:32:49 351

原创从手写 YAML 到一键发布：Helm 包管理与应用发布实战（Chart 编写、values 覆盖、版本回滚、私有仓库完整记录）

事情是这样来的。用 K3s 把集群搭起来、证书也自动签好之后，我以为部署这块已经顺了。集群是好用了，但我的部署方式还停留在“手写一堆 YAML 然后”的阶段。一开始不觉得有什么。架个服务嘛，写个 Deployment、再来个 Service、要外网访问就加个 Ingress，三四个文件，一下，完事。同一个应用，一堆文件。Deployment、Service、Ingress、ConfigMap、Secret……散在一个目录里，改个镜像版本要翻好几个文件。改一处配置，要动好几个地方。

2026-10-14 17:28:20 187

原创从零到多地域高可用：自托管服务器技术栈完整学习路径与命令速查总集

过去一年多，我把自己一台入门云服务器，一步步折腾成了一组带有多地域就近接入、入口高可用、数据同步和故障演练能力的小架构。单个技术点都好搜，难的是不知道它们之间什么关系、该按什么顺序学。一上来就配 Keepalived，结果发现会话没做一致性，用户一刷新就掉登录；监控先上了 Grafana，却没配告警规则，磁盘写满了都没人知道；多地域节点铺好了，才发现数据库还写死在一处，异地读总是旧数据；演练脚本写得很漂亮，第一次真出事时，探活脚本自己先挂了。

2026-10-13 22:37:28 185

原创多地域高可用架构总收口：一张总架构图 + 一套运维 Runbook 完整梳理

前前后后折腾了挺长时间，这套多地域的架构算是搭得差不多了：DNS 做了就近接入，入口层做了双机热备，Web 层做了负载均衡，数据层做了跨地域同步，最后还专门做了一轮故障演练把各个环节打了一遍。但真正让这套东西"能用"的，不是某个组件配得多漂亮，而是最后这一步——把散落各处的配置和零散的经验，收拢成一张图、一本手册。为什么这么说？因为我踩过一个很典型的坑：有一次半夜入口切换异常，我爬起来处理，结果发现光是"主入口机器是哪台、VIP 是多少、故障时该先看哪个日志"，我就翻了好几个笔记文件才凑齐。

2026-10-13 22:32:22 314

原创 GPU 显存规划与多模型共存部署实战：vLLM + Ollama 显存预算分配、并发调优完整记录

前几篇我把 GPU 的状态监控搭起来了，从此显卡温度、显存占用、谁在占卡都能看得清清楚楚。但监控解决的是“事后知道”，解决不了“事前不让它爆”。显存不够用，但我又不想只跑一个模型。日常写代码、查资料，我想用一个 7B 级别的通用模型，响应快、随时在线；处理长文档、做点复杂推理，我又想切到一个 14B 甚至 32B 的量化模型上；偶尔还要跑个 embedding 模型做知识库检索，或者跑个小模型做翻译、摘要这类杂活。结果就是，每次换模型都要先把上一个卸掉，等它重新加载。

2026-10-12 20:25:15 274

原创 GPU 服务器状态监控与多实例管理实战：nvidia-smi + DCGM Exporter + Prometheus + Grafana 完整记录

上一篇我搭了一套针对 CPU、内存、磁盘、网络的监控告警体系，跑了一段时间确实省心不少——磁盘快满了会提前发邮件，站点探活挂了十几秒就有通知。它完全看不见 GPU。我手上这台机器是用来跑 AI 任务的，CPU 和内存常年闲着，真正的“重体力活”全在那张显卡上。而显卡恰恰是最容易出状况、也最难靠"看网页能不能打开"来判断的地方。训练脚本跑了两个小时，loss 一直不降，最后发现是显卡温度上去了自动降频，算力掉了一半，但日志里一点提示都没有；推理服务凌晨挂了，因为显存泄漏。

2026-10-12 16:29:59 254

原创从手动部署到自动化：GitHub Actions + Docker 实现云服务器自动部署完整记录

之前部署项目一直是“本地打包 → scp 上传 → 服务器上拉起来”这套土办法，项目少的时候还行，后来同时维护三四个站点，每次改几行代码都要重复一遍手工流程，不是忘了重启服务，就是传漏了文件，有一次半夜改完顺手 scp 上去，第二天才发现依赖没更新，页面直接 500。代码 push 到 GitHub，剩下的构建、推镜像、发布、重启、健康检查全部交给流水线。

2026-10-10 21:07:03 236

原创 WordPress 网站性能优化实战：PHP-FPM 调优、OPcache、Redis 对象缓存、页面缓存、数据库清理、图片压缩完整记录

手上有几个用 WordPress 搭建的站点，一开始只装了缓存插件就不管了，后来发现首页 TTFB 一直在 800 ms 以上，后台文章列表越翻越慢，数据库体积一个月涨了近 100 MB。于是花了几个晚上，从 PHP-FPM、OPcache、对象缓存、页面缓存、数据库、图片、前端资源一路到 CDN，把整站重新优化了一遍。这篇文章把完整过程记录下来：每一步都先测试优化前的数据，改完再测一次，把前后的数字放在一起对比，方便判断哪一步真正有效、哪一步其实没什么用。

2026-10-10 21:02:52 474

uxuuid的博客