关于这个博客
# 1. 一句话定位
一线 DBA / SRE 出身，现在把 MySQL · Elasticsearch · Redis 的运维经验 复用到 AI Agent 基础设施 上——网关、Profile 隔离、模型路由、可观测、 GPU 推理节点这些是最近两年的主战场。
# 2. 能力矩阵
| 领域 | 量级 / 规模 | 代表文章 |
|---|---|---|
| MySQL DBA | 5+ 年生产实践，从日常调优到完整运维 SOP | MySQL 为什么有时候会选错索引 · MySQL8 故障处理手册 |
| Elasticsearch | 自建 3 节点集群长期主备，分片 / 磁盘 / 慢查询全链路 | ES 集群节点磁盘使用分配不均解决办法 |
| Redis | 集群 / 哨兵 / 大 key / 慢查询全覆盖 | Redis 集群部署 |
| AI Agent 基础设施 | 多 Profile 平台、Gateway、模型路由、技能工程与可观测 | 实战旗舰：让 Agent 部署并恢复 7 节点生产集群 |
| GPU 推理服务 | 8 卡 A100 节点上的 vLLM 服务：容量测算、健康检查、告警设计 | vLLM 推理节点运维 |
| 索引 / 优化器深度 | 抽象表 + 执行计划 + 递归 CTE 复现路径 | ORDER BY 配合 LIMIT 触发的索引选择陷阱 |
| 跨 Profile 路由与巡检 | 自托管服务巡检，AI Agent 平台 SRE 实践 | 跨 Profile 消息路由与自托管服务巡检 |
弱项也写在能力矩阵里：K8s / 容器编排这块积累偏薄，是我正在补的方向。
# 3. 在管系统清单（脱敏）
- AWS RDS：作为托管基线对照
- 自建 ES 集群（3 节点）：分片 / 副本 / 磁盘分配 / 慢查询全链路运维
- 多 GPU 推理节点（8×A100）：vLLM 服务的容量规划、健康检查与故障模式
- AI Agent 编排平台：多 Profile 隔离、模型路由、Gateway、Telegram 接入
这里写的都是职责与系统形态，不写具体主机名、内网 IP、实例 ID、Profile 名。 写"3 节点 ES、单节点 64GB"，不写"node-1.example.internal"。
# 4. 精选文章
每条标注「这篇能看出什么」，方便按面试追问的颗粒度挑读：
ORDER BY 配合 LIMIT 触发的索引选择陷阱 看出 MySQL 优化器行为的深度——执行计划判读（Extra / type 比 rows 重要）、 强制索引、延迟关联、ANALYZE TABLE 四种解法对比，能追问到
optimizer_trace。实战旗舰：让 Agent 从零部署并灾难恢复一个 7 节点生产集群 看出 AI Agent 在真实基础设施上的执行闭环——不是 demo，是带断言的端到端 自动化（部署 / 验证 / 故障注入 / 恢复），可追问到技能工程与心跳协议。
Elasticsearch 集群节点磁盘使用分配不均解决办法 看出 ES 排障的工程化——分片分配策略、磁盘水位、reroute，能追问到 ES 内部的分片平衡算法。
MySQL8 故障处理手册（SOP 第六章） 看出 规范化与团队协作意识——SOP 系列的方法论入口，能追问到 Runbook 的设计、复盘节奏、值班交接。
vLLM 推理节点运维：容量、健康检查与故障模式 看出 GPU 推理服务的 SRE 判断力——容量按 KV token 而非 QPS 计、 显存与 GPU 利用率为何都是伪信号、网关默认值（健康检查关闭 / 重试 5 次） 如何放大故障，能追问到就绪探针设计与 prefill 密集型负载的成本结构。
跨 Profile 消息路由与自托管服务巡检 看出 多租户 Agent 平台的 SRE 视角——两个被忽略的边界：消息路由的 隔离、巡检与告警的去重，能追问到 SLO 设计与告警降噪。
# 5. 联系方式
- GitHub：https://github.com/Carry00 (opens new window)
- Email：
admin@ranisa.cn
公开范围：个人技术主页 + 工作邮箱。不放手机号、身份证、现公司具体 业务名、真实客户名。
# 6. 这个博客本身
- 建于 2018-09-23，至今仍在持续更新。
- 主题：vuepress-theme-vdoing (opens new window)
- 部署：Cloudflare Pages（Node 22），push 到
master即上线。 - 源码：Carry00/Notes (opens new window)