GitHub 与博客：要不要做，怎么做

结论先放前面：需要，但不是门槛，是证据。它解决的不是"没作品"，是"外包身份下说不清哪些活是自己做的"。

一、先说结论

甲方和云厂商的 DBA JD 里几乎不会写"有 GitHub"，写的是：MySQL/PG 原理、高可用架构、备份恢复、性能优化、故障处理、自动化（Shell/Python）、云上经验。

所以 GitHub 和博客不是门槛，是证据。

你真正的卡点也不是"没有作品"，是：外包环境里活是别人派的，你说不清哪些是你做的。 这两件事解决的就是"归属权"——让某样东西看起来、查起来、问起来都是你自己的。

按投入产出比排序（从高到低）：

二、博客：你已经有站点了，但发的地方不对

已有资产

• 自建站：https://wiki.lyforcdf.cn （Hugo + hextra，能自己部署，边际成本 0）
• 问题：自建站没有流量、SEO 弱，HR 和技术面试官不会主动访问一个陌生域名

有效的顺序（这一步很容易做错）

先发墨天轮 → 再同步到 ITPUB 博客 / 自建站存档

原因很硬：墨天轮的「墨力原创作者计划」明确要求 “原创文章首发于墨天轮”。你先发自己站上，就失去参赛资格了。

墨天轮的规则（2026 年在跑的，原文见 http://www.modb.pro/db/608489）

参与方式：文章首发 + 打上「墨力计划」标签，每月一个活动周期。

硬要求：

• 字数 > 500 字（代码不计入）
• 格式清晰、主题明确

明确不合格的红线（都是官方原文）：

1. 搬运文（网上摘抄杂糅）
2. 流水账（代码占比 80% 以上，自己的总结少）
3. 翻译文（大篇幅翻译且无自己实操）
4. 广告文 / 外部引流
5. 刷阅读量
6. AI 代写 —— AI 生成内容或聊天记录占比超 50% 即不合格
7. 非首发于墨天轮

奖励：合格奖 10 墨值/篇（新人首月 20）；优秀文章奖 100 元/篇（当月需 ≥2 篇合格）。另有「特约作者」通道：2000 字以上深度文章，300 元/篇起，最高叠加到 1000，附带首页推荐流量和免费参加数据技术嘉年华的资格。

官方偏好的文章结构（可以直接照抄）：

• 故障处理类：问题现象 → 问题定位与分析 → 问题处理 → 问题总结
• 踩坑类：踩坑场景 → 问题现象 → 避坑方案 → 效果验证
• 调优类：问题现象 → 原因分析 → 调优方案 → 实施步骤 → 效果验证

官方在征的主题标签：故障处理、性能优化、国产数据库、PG

注意第 6 条。如果打算用 AI 批量生产，会被判不合格；而且面试官顺着文章问三个细节就能问穿。只写自己真做过的事。

分发渠道（一份内容，多处放）

1. 墨天轮（首发，拿流量和奖金）
2. ITPUB 博客 https://blog.itpub.net （老 DBA 聚集地，你的读者在这）
3. 自建 wiki https://wiki.lyforcdf.cn （当归档，标注原文链接）
4. 公众号（有余力再说，别一开始就搞）

一个心态调整

不要写「MySQL 索引原理」「InnoDB 架构详解」——这类文章有 10 万篇，你写不过数据库内核专家。

写别人写不出来的：你的 4 年基础组件运维经历。 这段经历在简历上是减分项，在技术内容上却是稀缺素材——因为它能回答"DBA 面试最爱问但大多数人只会背答案"的那类问题。

三、10 个你马上就能写的选题（全部基于你现有经历）

1. chrony/ntp 时间漂移导致主从延迟误判 —— Seconds_Behind_Master 显示 0 但其实已经延迟 40 秒，证据链怎么取
2. 集群节点小版本不一致：一次 yum 源没对齐，导致 MGR 节点加不回去
3. THP（透明大页）没关，MySQL 偶发 200ms 抖动 —— 从 perf top 到 /sys/kernel/mm/transparent_hugepage/enabled 的完整证据
4. swappiness 默认 60 在数据库机器上有多坑 —— 一次内存回收引发的查询变慢
5. IO 调度器与预读参数实测：同一台机器，换参数前后 sysbench QPS 差多少
6. 外包运维视角：一个脚本巡检 100 个实例 —— 分库分环境、结果汇总成一份报告
7. “备份"不算备份，“恢复演练"才算 —— 一次 restore 失败记录（binlog 缺失 / GTID 不连续）
8. XFS 与 ext4 在数据库场景下的差异实测
9. 监控采得太勤反而拖慢数据库？ —— 采集频率与 performance_schema 开销实测
10. 从 ntp 到 TSO：时间同步在分布式数据库里为什么是命门

每篇 500–1500 字，2–3 小时能写完（因为你是在写已经发生过的事，不是查资料编）。

26 周写 26 篇 = 每 2 周 1 篇。 这不算是新增任务，素材是从工作日里捞的，只是多了一道"记下来"的动作。

四、GitHub：不要做项目，要做三样东西

DBA 圈的 GitHub 文化是小工具文化，不是框架文化。参照这些真实存在的形态：
Percona Toolkit、mydumper、gh-ost、Patroni、mysqld_exporter、Yearning、dbatools。
共同点：只解决一个具体运维动作，但别人真的会用。

Repo 1：db-fault-lab（最重要，优先做这个）

解决的问题：外包环境里你轮不到碰核心故障。那就自己在家造。

db-fault-lab/
├── README.md              # 每个实验：目的 / 怎么起 / 怎么触发 / 预期现象 / 怎么定位
├── mysql/
│   ├── docker-compose.yml # 一主两从，可切 MGR
│   ├── inject/            # 故障注入脚本
│   │   ├── disk-full.sh
│   │   ├── kill-master.sh
│   │   ├── semi-sync-stall.sh
│   │   ├── lock-wait.sh   # 造一个 MDL 阻塞
│   │   └── binlog-corrupt.sh
│   └── observe/           # 观测脚本：抓什么指标、看哪个视图
├── postgres/
│   ├── docker-compose.yml # 流复制 + Patroni
│   └── inject/            # 复制槽堆积、XID 回卷、表膨胀、checkpoint 风暴
└── docs/
    └── 01-disk-full.md    # 每篇：现象 → 我的排查路径 → 根因 → 修复 → 防复发

面试怎么用：打开 repo，docker compose up，当场把主库 kill -9，讲一遍你观察到的现象和判断顺序。这比背"我知道怎么做故障切换"强一百倍。

额外好处：这套东西做完，你会自动拥有一批"我亲手复现过"的故障案例，正好是墨天轮选题库。

Repo 2：db-healthcheck（对应 JD 里的"自动化能力”）

一个脚本，输入实例清单，输出一份 Markdown/HTML 巡检报告。

检查项写实的，不要贪多：

• 版本 / 参数偏离基线（对比一份 baseline.yml）
• 连接数、Threads_running、慢查询 Top10
• 复制状态与延迟、复制槽堆积
• 表空间增长 Top10、无主键表、超大表
• 备份是否最近成功、binlog 保留时长
• 磁盘剩余、inode 使用率

为什么有效：甲方面试必问"你日常怎么做巡检”，绝大多数人答"看监控"。你有代码，差别在这里。
加分点：输出成 HTML 报告，能直接发给领导看——这正是甲方 DBA 每天在干的事。

Repo 3：db-postmortem（纯 Markdown，零代码）

每篇一个文件，结构固定：

# 2026-11-05 MySQL 半同步卡住导致业务写入超时
## 时间线（精确到分钟）
## 现象与告警
## 排查过程（包括走错的路）
## 根因
## 修复动作
## 防复发（改了什么监控、什么参数、什么流程）

价值：甲方最看重的能力就是"复盘"。你把这件事写成习惯，面试时可以直接展示输出节奏。

五、节奏（搭在现有 26 周计划上，不额外加负担）

发布前检查：仓库设为 public 前，扫一遍有没有内网 IP、主机名、账号密码、公司业务表名。外包身份尤其注意——不要泄露客户环境信息（脱敏成 10.0.0.x、db-prod-01）。

六、不要做的四件事

1. 不要做一个"数据库管理系统"或"运维平台" —— 做不完，做完了也没人信是你一个人做的。选小工具。
2. 不要写原理科普文 —— 竞争不过内核专家，且容易被判为搬运/AI 生成。
3. 不要把自建博客的 SEO 当回事 —— 域名对求职几乎零加成。内容发在有流量的地方。
4. 不要为了凑数发 AI 生成的文章 —— 墨天轮明文判不合格；面试官顺着问三个细节就穿帮。你的可信度是这个阶段最贵的资产。

七、一句话

GitHub 不需要 star，博客不需要域名。 你需要的是面试时能打开一个链接说：“这是我做的，你 clone 下来能复现，你想问哪个环节我都能答。”

附：账号取名与各平台怎么填

一个原则

用户名不是网名，是身份锚点。 它要满足三条：

1. 一致 —— GitHub / 墨天轮 / ITPUB / 公众号 / 简历上的链接，用同一个 ID。面试官从你的文章点进来，能一路找到你的代码，这条链才成立。
2. 可读 —— 别人看一眼能读出来、能复述给你同事。
3. 长期有效 —— 不绑年份、不绑公司、不绑某个具体产品。

实测可用性（2026-11-10 查的）

推荐：lianshan-dba

为什么不加年份、不加数字

lianshan2026、lianshan-dba-2026 这类，第二年会显得很怪；superman、xiaoming123、cool_dba（下划线 GitHub 还不允许）属于学生时代的 ID，放在简历上会削弱专业性。

几条硬约束

• 只能用字母、数字、单个连字符；不能以连字符开头或结尾（下划线不允许）
• 最长 39 字符，大小写不敏感
• 不要用外包公司名——一旦绑定，换工作时这个名字会一直跟着你
• 改名是可行的（GitHub 会把旧链接重定向），但会丢一部分外部引用，所以一次定好，别反复改

注册后顺手做两件事

1. Display name 单独写：用户名固定，显示名可以随时改。填 连山 | MySQL / PostgreSQL DBA，比纯拼音更像个人。
2. Profile README 只写三行：

   30 岁，7 年运维，正在转 MySQL / PostgreSQL DBA。
   在做的：db-fault-lab（可复现的数据库故障实验室）
   写的：墨天轮「连山」专栏
   别做那种堆徽章、堆技术栈图标的 README——DBA 圈看的是 repo 里的内容，不是主页装饰。

头像

别用默认的 identicon 方块。一张干净的真人照，或者一个简单的字标（“连山"两个字黑底白字），就够了。面试官真的会点开看一眼。

各平台怎么填（一张表）

先分清两层东西，这是最容易混的：

• 用户名 / ID：URL 里那串，只能是小写字母、数字、连字符 → lianshan-dba
• 显示名 / 昵称：人读的，可以带空格和中文 → 连山 DBA

为什么中文名和英文 ID 长得不一样：GitHub 页面上只显示 lianshan-dba，搜"连山DBA"是搜不到的。所以中文一律「连山DBA」、英文 ID 一律 lianshan-dba，靠 dba 这个后缀建立映射——人一眼能对上，机器也能搜到。

只注册 3 个，别一次铺开

26 周内你真正会用到的是：GitHub + 墨天轮 + ITPUB 博客。

把 10 个平台都注册一遍、每个都是空账号，等于给面试官看到一片荒地——空账号是负分，不如没有。剩下的等真写了内容再开。