关于这个博客

# 1. 这里写什么

一线 DBA / SRE 的运维笔记。在管千台以上生产主机、十余种数据与基础组件—— MySQL · Elasticsearch · Redis · TiDB 体系 · SQL Server，加上 Kafka / Flink / Trino 这条大数据与流链路，以及 Nginx / MinIO / K8s 这些接入与基础组件。最近把这套运维方法论复用到 AI Agent 基础设施 上：网关、多租户隔离、模型路由、可观测、GPU 推理节点。

# 2. 内容地图

领域	实践规模	代表文章
MySQL DBA	5+ 年生产实践，在管实例近 200 台，从日常调优到完整运维 SOP	MySQL 为什么有时候会选错索引 · MySQL8 故障处理手册
Elasticsearch	近 200 台自建 ES 节点、十余套集群，分片 / 磁盘 / 慢查询全链路	ES 集群节点磁盘使用分配不均解决办法
Redis	150+ 节点，集群 / 哨兵 / 大 key / 慢查询全覆盖	Redis 集群部署
TiDB 体系	140+ 节点、多套独立集群，TiDB / TiKV / PD / TiFlash / TiCDC 全组件	对 TiDB 中算子的理解 · 关于 TiFlash
SQL Server	Linux 平台部署与 Always On 高可用，跨平台 DBA 视角下的差异对照	SQL Server on Linux 与 Always On 部署
大数据与流	100+ 节点：CDH、Kafka、Flink、Trino、Airflow、CDC 链路的日常运维与扩缩容	Kafka 日常操作 · Flink 部署指南
AI Agent 基础设施	多 Profile 平台、Gateway、模型路由、技能工程与可观测	实战旗舰：让 Agent 部署并恢复 7 节点生产集群
GPU 推理服务	8 卡 A100 节点上的 vLLM 服务：容量测算、健康检查、告警设计	vLLM 推理节点运维
索引 / 优化器深度	抽象表 + 执行计划 + 递归 CTE 复现路径	ORDER BY 配合 LIMIT 触发的索引选择陷阱
跨 Profile 路由与巡检	自托管服务巡检，AI Agent 平台 SRE 实践	跨 Profile 消息路由与自托管服务巡检

K8s / 容器编排这块积累偏薄，写得少，是正在补的方向。

# 3. 在管系统清单（脱敏）

统一纳管在一套自建监控平台（夜莺 + VictoriaMetrics + categraf）下，下面的量级都是从监控资产表实时取的口径，不是估算：

维度	量级
纳管主机	1000+ 台，全部为生产环境；业务高峰期曾近 2000 台
计算规模	合计 2 万+ vCPU
云与机房	4 个：自建 IDC 为主（约 88%），另有三家公有云共约 120 台
业务线	14 条，最大一条近 300 台（大数据），其次两条各 100~250 台

按技术栈拆（主机数，同一台可能带多个角色标签）：

Elasticsearch ~190：十余套集群，含多套日志集群与游戏数据热集群；分片 / 副本 / 磁盘水位 / 慢查询全链路
MySQL ~180：主从与多源架构、慢查询治理、故障 SOP，另有 AWS RDS 作托管基线对照
Redis ~150：集群与哨兵，大 key / 热点 key / 命中率治理
TiDB 体系 ~140：TiDB / TiKV / PD / TiFlash / TiCDC，多套独立集群
大数据与流 ~100：CDH、Kafka、Flink、Trino、Airflow、CloudCanal / CDC 链路
接入与基础组件 ~80：Nginx、K8s master、MinIO、InfluxDB、Logstash、DNS / NTP、堡垒机
GPU 推理节点：8×A100 单节点上的 vLLM 服务，容量规划、健康检查与故障模式
AI Agent 编排平台：多 Profile 隔离、模型路由、Gateway、IM 接入

# 4. 精选文章

如果只挑几篇看，建议从这几篇开始，每条标注它解决的是什么问题：

ORDER BY 配合 LIMIT 触发的索引选择陷阱 讲的是 MySQL 优化器行为的深度——执行计划判读（Extra / type 比 rows 重要）、强制索引、延迟关联、ANALYZE TABLE 四种解法对比，延伸阅读方向是 optimizer_trace。
实战旗舰：让 Agent 从零部署并灾难恢复一个 7 节点生产集群 讲的是 AI Agent 在真实基础设施上的执行闭环——不是 demo，是带断言的端到端自动化（部署 / 验证 / 故障注入 / 恢复），延伸阅读方向是技能工程与心跳协议。
Elasticsearch 集群节点磁盘使用分配不均解决办法 讲的是 ES 排障的工程化——分片分配策略、磁盘水位、reroute，延伸阅读方向是 ES 内部的分片平衡算法。
MySQL8 故障处理手册（SOP 第六章） 讲的是 故障处理 SOP 怎么写——SOP 系列的方法论入口，延伸阅读方向是 Runbook 的设计、复盘节奏、值班交接。
vLLM 推理节点运维：容量、健康检查与故障模式 讲的是 GPU 推理服务怎么定容量、怎么判健康——容量按 KV token 而非 QPS 计、显存与 GPU 利用率为何都是伪信号、网关默认值（健康检查关闭 / 重试 5 次）如何放大故障，延伸阅读方向是就绪探针设计与 prefill 密集型负载的成本结构。
跨 Profile 消息路由与自托管服务巡检 讲的是 多租户 Agent 平台的两个边界问题——两个被忽略的边界：消息路由的隔离、巡检与告警的去重，延伸阅读方向是 SLO 设计与告警降噪。

# 5. 开源贡献

在自建的 Agent 平台上跑生产工作负载，踩到的 bug 会顺手回上游修掉。向 Hermes Agent (opens new window)（Nous Research 的开源 Agent 框架）提交过 11 个修复 PR，都是从生产故障里反推出的根因补丁，不是文档或格式改动：

方向	修的是什么
多租户隔离	终端环境缓存未按会话隔离，导致跨 profile 的 SSH 连接串台
远程后端	远程 backend 下把 `TERMINAL_CWD` 当本地路径处理；SSH 后端读文件缺失时不自动推送本机附件
模型与鉴权	同一自定义端点下辅助任务不复用主模型 api_key；单密钥鉴权失败时耗尽重试次数而非快速失败
运维与清理	磁盘清理把 cron 产物的分类范围放得过宽；技能同步把 `.hub` / `.archive` / 备份目录一起推进沙箱
CLI / TUI	`.env` 写入未加引号、Gemini 视觉模型白名单过窄、TUI 子进程 `PWD` 与 cwd 不一致