<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>时年小记</title><link>https://notes.aceo.top/</link><description>Recent content on 时年小记</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><lastBuildDate>Sun, 04 Oct 2026 09:15:00 +0800</lastBuildDate><atom:link href="https://notes.aceo.top/index.xml" rel="self" type="application/rss+xml"/><item><title>轻量监控应该回答哪些问题</title><link>https://notes.aceo.top/posts/lightweight-monitoring/</link><pubDate>Sun, 04 Oct 2026 09:15:00 +0800</pubDate><guid>https://notes.aceo.top/posts/lightweight-monitoring/</guid><description>小型服务器不需要一开始就部署复杂的可观测性平台。轻量监控的目标，是在异常发生时快速回答几个基本问题。
服务还在线吗 最外层应该从用户访问的地址检查 HTTP 状态、TLS 证书和响应时间。只在服务器本机请求 localhost，无法发现 DNS、证书或公网网络问题。
机器是否有资源压力 CPU、可用内存、磁盘空间和系统负载已经能解释多数基础故障。比“已使用内存”更值得关注的是可用内存，因为 Linux 会主动利用空闲内存作为缓存。
最近发生了什么变化 告警时间附近的部署、重启、证书续期和配置修改，往往比更多指标更有价值。为重要变更保留简短记录，可以明显缩短排查时间。
告警是否真的能送达 监控系统显示红色并不等于有人收到通知。应定期制造一次无害的测试告警，验证采集、判断、通知和恢复消息整条链路。
保持监控与被监控对象分离 至少把外部可用性检查放在另一台机器上。否则当主机完全离线时，部署在同一主机上的监控也会一起消失。
好的轻量监控不是图表最多，而是在几分钟内告诉你：哪里坏了、影响多大、应该先看什么。</description></item><item><title>Docker 服务上线前的五项检查</title><link>https://notes.aceo.top/posts/docker-production-checklist/</link><pubDate>Thu, 01 Oct 2026 16:40:00 +0800</pubDate><guid>https://notes.aceo.top/posts/docker-production-checklist/</guid><description>Docker 让应用很快跑起来，但“容器正在运行”和“服务可以长期维护”之间仍有距离。上线前，我会重点检查下面五项。
一、端口是否只开放在需要的位置 数据库和内部 API 通常不需要暴露到公网。反向代理后的应用可以只绑定回环地址：
ports: - &amp;#34;127.0.0.1:8080:8080&amp;#34; 然后通过 ss -lntp 查看宿主机实际监听情况，不能只看 Compose 文件。
二、状态数据是否持久化 明确哪些目录包含数据库、上传文件和运行配置。升级容器前，确认这些路径位于命名卷或宿主机目录中，并纳入备份。
三、镜像版本是否固定 latest 方便试用，却会让不同时间部署的结果不一致。生产环境至少固定版本标签；要求更严格时，可以固定镜像摘要。
四、是否有健康检查 进程存在不代表应用可用。健康检查应访问一个轻量端点，并验证依赖服务已经就绪。部署完成后，还要从反向代理外部再检查一次。
五、资源与重启策略是否合理 设置内存和进程数上限，避免单个容器拖垮整台机器。restart: unless-stopped 适合多数常驻服务，但持续重启也可能掩盖真正的启动错误，因此还需要监控重启次数。
这五项不能覆盖所有安全问题，却能避免自托管环境中最常见的一批故障。</description></item><item><title>备份真正有用之前，还差一次恢复演练</title><link>https://notes.aceo.top/posts/backup-restore-drill/</link><pubDate>Mon, 28 Sep 2026 11:20:00 +0800</pubDate><guid>https://notes.aceo.top/posts/backup-restore-drill/</guid><description>备份最容易制造一种错觉：只要定时任务显示成功，数据似乎就安全了。真正决定备份价值的，却是它能否在另一处环境中完整恢复。
先确定需要保护什么 一个常见的自托管服务通常不只有数据库，还可能包括：
用户上传的图片和附件； 应用配置与环境变量； 数据加密所需的密钥； 反向代理和证书配置； 当前运行版本与部署文件。 只复制数据库，可能得到一份无法解密的数据；只复制应用目录，也可能遗漏独立的数据卷。
给备份加上可验证的信息 备份任务完成后，至少记录文件大小、生成时间和校验值：
sha256sum backup.tar.zst &amp;gt; backup.tar.zst.sha256 数据库还应该执行自身的完整性检查。例如 SQLite 可以对备份副本执行 PRAGMA integrity_check，而不是只确认文件非空。
定期从零恢复 恢复演练最好在隔离目录或临时机器中进行：
准备一个没有原始数据的干净环境； 按文档还原配置、密钥和数据； 启动服务并完成一次真实读取； 记录缺失步骤，更新恢复文档； 删除演练环境，避免留下第二套生产数据。 能够被恢复的备份，才是备份。其他文件只是尚未验证的希望。</description></item><item><title>一个简单的每周整理习惯</title><link>https://notes.aceo.top/posts/weekly-reset-routine/</link><pubDate>Sun, 27 Sep 2026 18:30:00 +0800</pubDate><guid>https://notes.aceo.top/posts/weekly-reset-routine/</guid><description>工具越来越多以后，整理本身很容易变成一项复杂工程。为了避免不断调整系统，我现在只在每周末做一次简短整理，时间控制在半小时左右。
先清理看得见的地方 我会先整理桌面和下载目录。需要保留的文件移到明确的位置，临时安装包和重复文件直接删除。浏览器里只留下下一周确实要继续处理的标签页，其余内容放入书签或关闭。
再看没有完成的事 任务列表里长期没有动作的项目，需要重新判断：继续、等待，还是放弃。比起让它们一直占据注意力，明确删除往往更轻松。
接着为下一周选出三件真正重要的事。不是列出所有可能做的工作，而是确认即使临时安排增多，也不应该被挤掉的内容。
最后留下一段空白 整理结束后，我不会立刻开始下一项任务。泡杯茶、听一会儿音乐，或者什么都不做。这个短暂空白像是一条边界，让上一周真正结束。
一套整理习惯是否有效，不取决于模板多漂亮，而在于它能否长期减少混乱。越简单，通常越容易留下来。</description></item><item><title>HTTPS 证书续期容易忽略的细节</title><link>https://notes.aceo.top/posts/https-renewal-notes/</link><pubDate>Fri, 25 Sep 2026 19:20:00 +0800</pubDate><guid>https://notes.aceo.top/posts/https-renewal-notes/</guid><description>HTTPS 证书通常只有较短的有效期。自动化工具让续期变得容易，但“安装了工具”并不等于续期链路真的可用。
一条完整的续期链路 域名解析仍指向正确服务器； ACME 验证路径可以从公网访问； 定时任务能够执行； 新证书被复制到 Web 服务实际读取的位置； Nginx 或 Caddy 在更新后成功重载； 外部客户端看到的是新证书。 验证证书时间 openssl s_client -connect example.com:443 -servername example.com &amp;lt;/dev/null 2&amp;gt;/dev/null \ | openssl x509 -noout -issuer -dates 最后一步应从另一台机器执行。服务器本地文件的日期正确，不代表公网入口已经加载了新证书。
把验证也纳入自动化，往往比单纯增加续期频率更有效。</description></item><item><title>最近重新开始读纸质书</title><link>https://notes.aceo.top/posts/reading-paper-books-again/</link><pubDate>Wed, 23 Sep 2026 22:00:00 +0800</pubDate><guid>https://notes.aceo.top/posts/reading-paper-books-again/</guid><description>电子书可以随身携带，查找和做标记也很方便，所以过去几年里，我很少认真读完一本纸质书。最近从书架上拿下一本放了很久的散文集，才发现纸张带来的并不只是怀旧。
阅读速度自然慢下来 屏幕上的内容很容易被快速滑过。纸质书没有消息提醒，也没有可以立刻跳转的链接。一页读完之后，手要做一次翻页的动作，这个很小的停顿会让上一段话多停留一会儿。
我开始在书里夹一张普通卡片，只记录页码和几个关键词。没有复杂的笔记系统，也不急着把每句话整理成结论。读书重新变成一件可以暂时没有产出的事情。
固定一个容易坚持的时间 我没有设置每天必须读多少页，只把书放在睡前最容易拿到的位置。多数时候读十几分钟，有时只有两三页。关键不是速度，而是让这件事自然进入每天的节奏。
电子阅读依然是主要方式，但纸质书提供了另一种注意力。两者没有必要互相替代，只要知道自己此刻需要的是效率，还是一段慢下来的时间。</description></item><item><title>新服务器启用后的基础检查</title><link>https://notes.aceo.top/posts/server-first-check/</link><pubDate>Mon, 21 Sep 2026 10:30:00 +0800</pubDate><guid>https://notes.aceo.top/posts/server-first-check/</guid><description>拿到一台新服务器时，我通常不会立刻安装应用，而是先确认系统边界和当前状态。
先看清环境 cat /etc/os-release uname -a free -h df -h ss -lntup 这几条命令分别用于确认系统版本、内核、内存、磁盘和监听端口。先记录原始状态，后续出现问题时才有比较依据。
再处理访问入口 SSH 调整应该谨慎。添加新密钥后，先从另一个终端测试成功，再考虑关闭旧入口。防火墙同样应先允许当前连接需要的端口，避免把自己锁在服务器外。
最后建立维护习惯 开启安全更新； 为配置文件保留备份； 给关键服务增加健康检查； 记录域名、证书和续期方式； 定期验证备份确实能够恢复。 初始化的目标不是装得多，而是让后面的每一步都可解释、可验证、可回退。</description></item><item><title>雨后散步时，城市安静了十分钟</title><link>https://notes.aceo.top/posts/walk-after-rain/</link><pubDate>Sun, 20 Sep 2026 20:10:00 +0800</pubDate><guid>https://notes.aceo.top/posts/walk-after-rain/</guid><description>傍晚下了一场很短的雨。等雨停时，天还没有完全暗下来，我沿着平时买东西的那条路慢慢走了一圈。
雨后的声音和晴天不太一样。车轮经过积水时会拖出一阵细响，树叶上的水滴偶尔落在遮雨棚上。原本总有人说话的小店门口空了下来，老板坐在里面看手机，没有急着把摆在外面的椅子擦干。
熟悉的路也会变化 路灯刚亮，湿润的地面把光拉得很长。平常不会留意的招牌、窗台和墙面，因为反光突然显得清楚。走到街角时，还能闻到泥土、树叶和刚出炉面包混在一起的气味。
散步没有目的，也没有需要完成的路线。走得慢一点，才发现熟悉并不等于看见。每天经过的地方，仍然会因为天气、光线和心情变成不同的样子。
留下十分钟 回去时街上重新热闹起来，车流也恢复了平常的速度。那段安静大概只持续了十分钟，却足够让一天从忙乱里分开一条缝。
以后遇到这样的雨，还是应该出门走走。不是为了步数，也不是为了拍照，只是给自己留一点没有任务的时间。</description></item><item><title>为什么开始写这个博客</title><link>https://notes.aceo.top/posts/hello-blog/</link><pubDate>Fri, 18 Sep 2026 09:00:00 +0800</pubDate><guid>https://notes.aceo.top/posts/hello-blog/</guid><description>很多问题解决之后，很快就只剩下一句“以前好像遇到过”。聊天记录、临时文本和浏览器收藏夹都不是理想的长期存档。
这个博客因此建立。这里会保存一些实际操作后的笔记，也会记录对工具和生活的观察。文章不一定长，但尽量交代清楚背景、过程和结论。
记录的原则 只写自己真正使用或验证过的内容； 命令旁边说明用途，而不是单纯堆砌； 旧文章发现错误时及时修正； 不收集不必要的访问者信息。 希望几年以后回来，这里仍然是一个有用、安静的资料夹。</description></item><item><title>关于这个博客</title><link>https://notes.aceo.top/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://notes.aceo.top/about/</guid><description>这里是 时年小记，一个用于整理技术实践和日常观察的个人空间。
内容主要包括 Linux、开源软件、网络服务以及使用工具时遇到的问题。写下来的目的很简单：方便以后回顾，也希望偶尔能给路过的人一点参考。
站点不追求高频更新，只记录亲自实践过、值得留下的内容。</description></item><item><title>页面没有找到</title><link>https://notes.aceo.top/404.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://notes.aceo.top/404.html</guid><description/></item><item><title>隐私说明</title><link>https://notes.aceo.top/privacy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://notes.aceo.top/privacy/</guid><description>时年小记是一个静态个人博客，当前遵循尽量少收集数据的原则。
本站不做什么 不提供用户注册或评论功能； 不使用广告追踪代码； 不接入第三方行为分析脚本； 不出售或交换访问者数据； 不要求访问者提供姓名、邮箱或其他个人资料。 服务器日志 Web 服务器可能短期记录访问时间、请求路径、HTTP 状态和来源 IP，用于排查故障与滥用。日志仅用于站点运行维护，并按服务器维护策略轮转。
外部链接 文章可能包含其他网站的链接。离开本站后，对方网站的隐私规则由其自行负责。
如以后增加评论、统计或订阅服务，本页会在功能上线前同步更新。</description></item></channel></rss>