技术日志总览

Long-form Logs Production Notes Debug Archive

这里不是零散笔记堆放区，而是按主题整理过的工作日志。每一篇都尽量保留实际环境中的背景、动作和结果，方便后续回看、复制和复盘。

文章风格偏正式博客与排障复盘

阅读重点背景、命令、修复、验证、复盘

更新方向持续增加真实维护场景

近期记录

Linux

Linux 初始整理

适合新机器、测试节点和 HomeLab 首次上线前的基础动作清单。

Incident

Linux 磁盘占满排查

围绕磁盘、inode、日志与容器缓存的逐层定位与处理。

Container

Docker Compose 部署记录

把单机应用部署整理成可以反复执行的结构化过程。

Gateway

Nginx 与 TLS 入口整理

把站点入口层做成统一模板，让后续维护和复制都更轻松。

Cluster

Kubernetes 集群排障

一篇从症状出发、逐层验证并最终定位问题的调试记录。

Ingress

Ingress 404 排查记录

适合排查入口可达但路径不通、规则未命中的这类问题。

Release

发布流程与回滚演练

把上线动作从经验驱动改成流程驱动，尽量降低现场失误。

Pipeline

CI/CD 发布复盘

流水线成功但版本没真正切换时，应该优先排查哪几层。

Observability

监控与告警收敛

从指标过多、告警过密，收束到真正有价值的监控体系。

推荐阅读路径

从基础环境到入口层

先看 Linux 初始整理和 Nginx/TLS 入口整理，建立机器与站点层的上下文。

再看部署与发布

Docker Compose、发布回滚和 CI/CD 复盘三篇结合起来，适合串成一条交付链路阅读。

最后看故障与观测

磁盘占满、Ingress 404、集群排障和监控收敛几篇可以形成比较完整的运维排障视角。

记录原则

先写事实，再写判断

日志页最重要的不是结论有多漂亮，而是过程是否能复现。建议优先记录：

• 当时的现象
• 具体执行过的命令
• 配置变更前后的差异
• 验证结果
• 回滚方式

只保留高频信息

如果一条经验不会在一个月后再次用到，就不必写得很长。真正值得留下来的通常是：

• 常见故障的排查顺序
• 容易忘记的参数和路径
• 和现网环境强相关的注意点

让页面可被快速扫读

每篇文章都尽量采用统一结构：

1. 背景
2. 过程
3. 验证
4. 复盘

这样既适合阅读，也适合在现场边查边用。

适合继续扩展的方向

• Linux 性能调优日志
• Docker 镜像体积优化日志
• Kubernetes 探针和资源限额日志
• Nginx 路由规则调整日志
• CI/CD 构建链路日志
• 存储、备份与恢复日志

写作建议

如果你想让这个站更像一个真正长期更新的博客，而不是单纯的文档站，后续文章可以尽量遵循下面的节奏：

• 每篇先写清楚背景和触发事件
• 中间多保留真实命令、配置和日志片段
• 结尾一定写复盘和后续预防点
• 同类问题尽量统一标题格式，方便串联阅读

这样积累一段时间后，站点会自然呈现出“有现场感”的技术日志风格，而不是几篇孤立的说明页。