单人在线运维一个站点，最怕的不是技术难，而是「记不住」。三个月前怎么排的那个故障、当时改了哪一行配置、为什么最后选了那个方案——如果不写下来，下次再遇到同一个问题，等于从零开始。运维笔记不是写给老板看的文档，而是写给三个月后的自己的操作手册。这篇讲清楚笔记该记什么、记在哪、怎么记，以及怎么让它真的被用起来。
一、为什么大多数人的运维笔记最后都废了
几乎每个运维都开过笔记，也几乎每个运维的笔记最后都烂尾了。常见死法有四类：
- 写成了流水账：只有「今天升级了内核」「今天改了个配置」，没有上下文、没有结论、没有可复现的步骤，三个月后自己都看不懂。
- 散落在五个地方：微信收藏一点、浏览器书签一点、某个文档里一点、终端历史里一点。真要找的时候，哪个都找不全。
- 只有成功记录：只记「最后怎么解决的」，不记「试过什么没用」。结果下次遇到同类问题，又把那些无效方案重新试一遍。
- 没有入口：笔记写了三百条，但没有目录、没有标签、没有检索方式，等于没写。
这四条的共同点是：把笔记当成了「记录行为」，而没当成「检索系统」。判断一份笔记有没有价值，唯一标准是——三个月后的你，能不能在三十秒内找到需要的那一条。
二、该记什么：四类内容，四套模板
不是所有事情都值得记。按价值排序，值得记的只有四类，每类的结构不一样。
第一类：故障复盘（最高价值）
每次线上故障，无论大小，都要记一条。模板固定成六个字段，写起来很快：
- 现象：用户/监控看到什么。写原始报错文本，不要转述。「502 Bad Gateway」比「网站打不开」有用一百倍。
- 排查路径：按时间顺序写每一步做了什么、看到什么。这一步最有价值，因为它记录的是「怎么想」而不只是「是什么」。
- 根因：一句话说清。如果说不清，说明还没查完。
- 处置：改了哪一行、执行了哪条命令。要能复制粘贴。
- 代价：影响了多久、影响多少人。
- 后续：怎么防止它再发生。这一条决定笔记的长期价值。
第二类：配置变更记录
每一次改 Nginx、MySQL、防火墙、定时任务，都记一条最小记录：时间、文件路径、改前改后的关键片段、为什么改、怎么回滚。关键在「怎么回滚」——只写「改了 worker_connections」不够，要写「改前是 1024，备份在 nginx.conf.bak_20261029，回滚命令是 cp 回去再 nginx -s reload」。
第三类：一次性知识
那些「查一次就够但下次还会忘」的东西：某个命令的准确语法、某个服务默认端口、某张表的结构、某个日志字段的含义。这类笔记要写得极短，一句话加一段示例代码，标题就是检索词本身，比如「nginx 如何只对某个 location 关闭 gzip」。不要为了完整而稀释它。
第四类：决策记录
为什么选 A 不选 B。这类记录写作成本最高，但价值随时间长尾越明显。比如「为什么最后没用 Docker 部署」「为什么数据库留在本机没上云」「为什么放弃某个 CDN」。半年后想重新评估时，这份记录能让你不必重新踩一遍当初的坑。
三、记在哪：一个目录，纯文本，进版本库
工具选择上的争论很多，但结论其实很朴素：纯文本 + 一个目录 + Git，就是个人运维笔记的最优解。
理由有三条：
- 纯文本永远不会因为软件停更而打不开。十年后 Markdown 还是 Markdown，某个笔记 App 可能早就没了。
- 纯文本可以被
grep。三百条笔记里找一个关键词，一条命令搞定，比任何花哨的搜索都快。 - 放进 Git 就有了时间线和历史版本。某条笔记什么时候写的、后来改过什么，一目了然，而且天然异地备份了一份。
目录结构按「类型 + 时间」分就够了，不要设计得太复杂：
~/notes/
├── incidents/ # 故障复盘，文件名 2026-10-29-nginx-502.md
├── changes/ # 配置变更，文件名按 年月 归档
├── howto/ # 一次性知识，标题即文件名
└── decisions/ # 决策记录文件名统一用「日期-关键词」或「关键词」，全小写、连字符分词。这样无论用什么工具，按文件名排序天然就是时间线。
四、怎么写：三条让笔记能用的规则
规则一：故障现场就写，不要等「有空再补」。故障处理的当下，脑子里全是排查路径，这时候花三分钟敲一段原始记录，质量是事后回忆的十倍。可以在文件里先写一半，标记 TODO: 根因，处理完再补。
规则二：命令和输出都要贴，而且要贴原始文本。转述会丢信息。看到「连接超时」和看到完整的 curl: (7) Failed to connect to 127.0.0.1 port 3306: Connection refused，指向的是完全不同的两个方向。
规则三：每条笔记末尾写一句「下次怎么办」。哪怕只是「下次先看 nginx -t」，这一句话就是笔记从「档案」变成「手册」的那一步。
五、让它活起来：检索与回顾
写好只是第一步，能查到才算数。三个低成本机制：
一个总索引文件。手动维护一个 INDEX.md，每条一行：日期 + 一句话 + 链接。不用全，只放「值得反复用的」那些，一年下来大概五十条，这就是你的私人运维手册目录。
用 grep 代替搜索框。查某个关键词在哪些笔记里出现过：
grep -ril 'worker_connections' ~/notes/查带上下文的原文：
grep -rn -A3 -B3 '502' ~/notes/incidents/ | head -60打字比点开应用快得多，这也是纯文本方案真正的优势。
每月一次回顾。固定在每月最后一个周末，花二十分钟翻一遍本月笔记，把同类问题合并成一条「通用处置流程」，把已经解决的临时标记删掉。回顾的意义不是整理，而是发现模式——当你看到一个月里三次同类故障，那说明该改的是系统而不是继续救火。
六、把笔记和实际操作连起来
笔记最大的价值在于「写的时候顺便把流程固化了」，而这需要一点纪律：任何操作前先搜一遍笔记。这个习惯只要坚持两周就会变成肌肉记忆，收益很直接——同样是改 php-fpm 的 pm.max_children，搜索一次能省掉重新推导内存分配公式的十分钟。
另一个技巧是把常用的排查命令固化成小脚本，放进笔记目录的 scripts/ 子目录里，并在对应笔记里引用它。脚本比文字可靠，因为它是可执行的。比如一个「三分钟体检」脚本，检查磁盘、内存、负载、Nginx 状态、MySQL 连接数、最近的错误日志尾部，输出一屏。这类脚本写一次用三年。
七、常见误区
误区一：追求笔记体系完整。很多人先花一周设计分类体系、标签规范、模板字段，然后一条笔记都没写。正确顺序是反过来：先写二十条，写到觉得乱了再整理，这时候的分类才是从实际需求长出来的。
误区二：只记技术不记背景。「把 innodb_buffer_pool_size 调到 1G」这条笔记，三个月后你在另一台 512MB 的机器上照做，机器直接 OOM。技术结论必须带前提条件：机器配置、数据量、业务类型。
误区三：笔记只给自己看就不认真写。恰恰相反，给自己看的笔记更要写清楚，因为三个月后的你，对这个项目的上下文记忆几乎为零，和陌生人没什么区别。事实上，写笔记时按「写给接手的人」这个标准去写，质量最稳。
八、小结
个人站长的运维能力，很大程度上不体现在「会不会」，而体现在「能不能稳定重复」。运维笔记就是这件事的载体：故障复盘记的是排查思路，配置变更记的是可回滚的路径，一次性知识记的是检索词，决策记录记的是判断依据。工具用纯文本加 Git 就够，结构按四类分开，纪律是现场就写、每条都给「下次怎么办」、每月回顾一次。坚持三个月，你会发现排查同类问题的时间从两小时降到二十分钟——这就是笔记真正的复利。