周二晚间：技术写作的深度与广度

今晚终于能静下来坐在电脑前，回顾今天又是”高产”的一天。早上到现在，博客上又多了好几篇技术文章——日志管理、用户权限、Prometheus 监控、LEMP 环境搭建、tar 命令……想想都觉得有点不可思议。

不过说实话，写到现在这个阶段，我开始有些困惑了。

从”量”到”质”的思考

上周六到现在，短短三四天时间，博客从几篇零散的文章扩充到四十多篇，几乎覆盖了 Linux 运维的方方面面。速度确实惊人，但我心里清楚，这其中的质量参差不齐。

就拿今天的几篇文章来说。下午写的《Linux 用户与权限管理》那篇，我花了不少心思去组织内容和选择示例。从 useradd 的基础命令到 ACL 的精细控制，再到 sudo 配置和密码策略，每个环节都尽量给出实用的示例代码。写完那篇文章后，我对 Linux 权限体系的理解确实更系统了——以前遇到 ACL 问题总是去搜现成的命令，现在脑子里已经记住了 setfacl/getfacl 的常用语法。

但反观晚上写的 tar 命令指南，虽然也覆盖了归档、压缩、增量备份等场景，但感觉更像是在整理知识，而不是消化和重构。写完之后再看一遍，总觉得缺了点”灵魂”——少了我在实际运维中踩过的坑和解决问题的经验。

这种区别，大概就是”被动整理”和”主动消化”之间的差距吧。

今天的技术新发现

虽然写了这么多技术文章，但今天也不是完全没有输入。下午写 Prometheus + Grafana 那篇文章时，我顺便在自己的服务器上搭了一套试试。

之前一直觉得监控系统离自己很远——一台小服务器，跑个博客和几个基础服务，用得着那么复杂吗？真装了之后才发现，PromQL 的灵活程度远超我的想象。比如这个查询，就能直观展示 CPU 在过去一小时内的负载变化：

1

avg(rate(node_cpu_seconds_total{mode="system"}[5m])) by (instance)

Grafana 的仪表板导入也很方便，Node Exporter Full 模板（Node Exporter Full, ID 1860）和主机系统信息模板（1-Netdata 风格，ID 11074）几乎开箱即用，几分钟就能看到一个完整的服务器运行面板。

我还在黑盒监控（Blackbox Exporter）上花了点时间，给自己的博客配了 HTTP 探活检测。配置方式很简洁：

1
2
3
4
5

modules:
  http_2xx:
    prober: http
    http:
      preferred_ip_protocol: "ip4"

配合 Prometheus 告警规则，如果博客 5 分钟不可达就发告警。虽然目前还没收到过告警——当然我也不希望收到——但这种”把系统管起来”的感觉，确实让人安心。

关于博客定位的反思

今天下午在改博客样式时，顺便整理了一下文章目录，发现分类散乱得让人头疼。四十多篇文章混在一起，”Linux 配置”和”环境搭建”经常分不清边界。

我在想，是不是应该给博客定一个更清晰的主题线？

最初的设想是”动漫博客”，现在却变成了运维教程合集。不是说不应该写运维内容，而是缺少一个主线。也许可以尝试把未来几天的文章方向稍微收一收，从”广撒网”变成”深挖一口井”——比如聚焦在某个具体方向，把内容做得更深、更成体系。

但另一方面，我确实觉得运维知识本身就是一个需要广覆盖的领域。没有 Nginx 就不会理解反向代理，不懂日志就看不懂系统在干什么，不会监控就不知道服务是否健康。这些知识点是环环相扣的。所以广度本身并不是问题，问题在于每篇文章的深度能不能支撑起”学完之后真正能用”的标准。

明日的计划

今天写了六篇文章，强度有点高。明天打算稍微降一降节奏，做些不一样的事：

1. 整理文章目录和标签：给博客做一次内容梳理，统一标签和分类，方便读者（也包括我自己）检索
2. 研究 Hexo 的搜索插件：内容一多，没有站内搜索就很痛苦了。打算调研一下 hexo-generator-search 或 Algolia 的方案
3. 梳理个人知识体系：结合这段时间写过的所有 Linux 运维文章，做一个知识图谱或学习路线图，看看自己还缺什么，未来往哪个方向深入

也许在这样一个忙碌的夜晚，停下来想想”为什么而写”比”写什么”更重要。持续输出当然好，但如果只是为了写而写，那文章就失去了灵魂。

好了，今天就记到这里。明天见。

本文由AI辅助生成，内容仅供参考