Skip to content

技术日志总览

Long-form Logs Production Notes Debug Archive

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

文章风格偏正式博客与排障复盘
阅读重点背景、命令、修复、验证、复盘
更新方向持续增加真实维护场景

近期记录

Release

发布流程与回滚演练

一个尽量可重复、可回退的服务发布过程整理。

Observability

监控与告警收敛

把监控系统从“什么都报”整理到“真正有用”的过程。

Release

CI/CD 发布复盘

一次发布链路中断后的复盘记录,重点在于流程和可观察性。

Container

Docker Compose 部署记录

从单机验证到 Compose 编排的一次标准化部署过程。

Ingress

Ingress 404 排查记录

一次 Ingress 访问返回 404 的完整定位过程。

Kubernetes

Kubernetes 集群排障

一次从症状到定位再到修复的 Kubernetes 故障排查记录。

Linux

Linux 初始整理

新机器上线前的系统检查、基础加固和常用命令记录。

Linux

Linux 磁盘占满排查

一次典型的磁盘告警处理记录,包含定位、清理和复盘。

Gateway

Nginx 与 TLS 入口整理

把反向代理、证书和站点入口收束到一个可维护模板中。

Network

apt update 卡顿与 Tailscale 误伤排障

一次把 APT 超时定位到 netfilter 规则误伤阿里云内网镜像的完整排障记录。

推荐阅读路径

从基础环境到入口层

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

再看部署与发布

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

最后看故障与观测

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

记录原则

先写事实,再写判断

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

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

只保留高频信息

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

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

让页面可被快速扫读

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

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

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

适合继续扩展的方向

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

写作建议

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

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

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

Focused notes for DevOps, Linux and Kubernetes.