读技术文档时,先确认版本和前提条件
教程中的软件版本、系统发行版和网络模式,决定了命令能否直接使用。本文整理两个容易忽略的环节,作为日常使用时的检查参考。 相同命令可能对应不同环境教程中的软件版本、系统发行版和网络模式,决定了命令能否直接使用。尤其容器路径、宿主机路径与服务名容易混淆,照抄之前先标出这些条件。 把示例当作起点示例为了简洁,可能省略权限、错误处理和持久化。实际应用时要理解每个参数的作用,再补上备份、验证与回退。遇到报错时,保留完整上下文比只搜索最后一行更有效。 日常使用的小结好文档可以节省时间,但最终判断仍来自自己的运行结果。记录哪些前提与环境不同,下一次排查就会快很多。
迁移网站前,给域名与证书留一条退路
复制内容、配置服务和准备证书之后,使用指定解析方式测试新服务器。本文整理两个容易忽略的环节,作为日常使用时的检查参考。 先让新服务器独立可用复制内容、配置服务和准备证书之后,使用指定解析方式测试新服务器。这样可以在不影响现有访客的情况下验证页面、资源链接与后端接口。 切换后继续观察旧入口不同访客的 DNS 缓存到期时间不同,短期内新旧服务器可能同时收到请求。动态站点还要考虑数据写入去向,不能让两个数据库各自接收更新。 日常使用的小结保留旧配置、旧镜像与数据备份,明确回滚时哪些数据需要合并。把域名改回去很简单,恢复迁移期间新增的数据则未必简单。
给个人资料做备份,从一张清单开始
备份的第一步不一定是购买硬盘,而是确认哪些东西丢了无法重新获得:照片、原创文档、账号恢复信息,以及服务的配置与数据。 先分清同步和备份同步把最新状态传播到其他设备,误删也可能被同步。备份则需要保留历史版本,让人能够回到错误发生之前。只有另一份实时同步目录,并不足以应对所有情况。 用 3-2-1 作为起点常见做法是保留三份数据,使用两种介质,并有一份异地副本。这是规划思路,不是机械达标:对重要文件,版本历史、隔离程度和恢复速度同样关键。 数据库备份要考虑一致性运行中的数据库可能同时写入主文件与日志。直接复制某一个文件,不一定得到可恢复的备份。应优先使用数据库原生备份方式,或在停写后做一致性快照。 加密之后,密钥也需要管理上传到外部存储前加密,可以减少存储端泄露的影响。但如果解密密钥只保存在同一台电脑上,设备损坏后备份也可能无法使用。应单独保存恢复材料,并限制访问权限。 恢复演练比“任务成功”更有说服力定期随机挑一个文件恢复;网站与数据库则应在隔离环境试恢复。确认文件能打开、数据条数合理、应用能启动,才能证明备份真正有用。 可以从一张简单清单开始:资料位置、备份频率、保存期限、恢...
静态博客的日常写作流程,可以有多简单
文章保存在 Markdown,主题配置决定展示方式,生成目录负责对外提供页面。本文整理两个容易忽略的环节,作为日常使用时的检查参考。 内容和生成结果分开文章保存在 Markdown,主题配置决定展示方式,生成目录负责对外提供页面。把三者分开,修改主题时就不容易误伤原稿,也更方便迁移到其他框架。 发布前做一个小检查检查标题、链接、封面、摘要与移动端阅读。图片采用本地文件时,应确认它们进入构建产物。日期变化可能改变固定链接,已公开的旧链接需要考虑重定向。 日常使用的小结保留源文件备份比只保留 HTML 更重要。日常写作不需要复杂流水线,但发布过程最好能重复执行,并能恢复到上一个版本。
让脚本成为一个可管理的 systemd 服务
一个长期运行的脚本需要的不只是后台符号。本文整理两个容易忽略的环节,作为日常使用时的检查参考。 先明确服务的运行方式一个长期运行的脚本需要的不只是后台符号。运行用户、工作目录、环境变量和退出后的行为,都应写进 unit 文件。优先使用普通账号运行,只有确有需要时再授予额外权限。 重启策略要留出缓冲Restart=on-failure 适合异常退出后恢复,配合 RestartSec 可以避免连续启动失败时占满日志。更改 unit 后运行 systemctl daemon-reload,再启动并查看 journalctl。enable 表示开机启用,不等同于立即启动。 日常使用的小结把日志交给 journal 管理,通常比自行拼接日志文件更容易检索。配置中的路径建议写绝对路径,减少交互式终端与服务环境的差异。
小型 VPS 监控,先看哪些指标最有用
网站是否可访问、响应是否变慢、证书是否快到期,往往比单纯显示 CPU 曲线更直接。本文整理两个容易忽略的环节,作为日常使用时的检查参考。 先观察用户会感知的结果网站是否可访问、响应是否变慢、证书是否快到期,往往比单纯显示 CPU 曲线更直接。基础资源监控则帮助解释问题发生的原因。 告警要有处置动作磁盘容量、内存压力与错误率应设置有持续时间的阈值,避免瞬时波动触发大量通知。每条告警最好对应一个可执行检查步骤,否则通知越多越容易被忽略。 日常使用的小结监控服务与被监控机器最好不要完全共用故障点。保留外部探测,可以在整台 VPS 失联时仍然发现异常。
挑选开源工具时,我会先看什么
搜索一个开源项目时,Star 数很容易成为第一判断标准。但真正决定工具能否长期使用的,往往是更细小的东西:文档是否清楚、升级是否可靠、数据能否导出。 先确认解决的是同一个问题功能列表很长,不代表适合自己的工作流。先列出三项必须满足的需求,再用一组小数据试跑,通常比浏览十个展示页面更有效。 阅读许可证源码可见与开源许可不是一回事。使用前应阅读 LICENSE,尤其在修改、分发或商业使用时。主题、字体、图片与插件也可能采用不同许可证,不能默认跟随主项目。 看维护方式,而不只看提交频率成熟项目可能更新不频繁。更值得看的是安全问题如何处理、Issue 是否有人回应、版本是否有发布说明,以及升级失败时有没有清晰的回退路径。 估算完整使用成本自建软件可能免费,但服务器、备份、域名、升级和排错都消耗资源。小型站点不一定需要数据库和复杂后台;反过来,多人编辑也不适合强行用手动上传文件解决。 数据出口决定选择自由试用前就看看能否导出 Markdown、JSON、数据库备份或标准格式。能迁走的数据,才不会把一次工具选择变成长期绑定。 最好的工具不一定拥有最多功能,而是能稳定完成目标、维护负担可接...
SSH 密钥登录:把日常连接整理得更顺手
SSH 密钥认证使用公钥和私钥配对。本文整理两个容易忽略的环节,作为日常使用时的检查参考。 密钥与密码的区别SSH 密钥认证使用公钥和私钥配对。公钥放在服务器,私钥留在自己的设备。为私钥设置口令,可以在设备文件被复制时再增加一道保护。不要把私钥当作普通配置文件上传到代码仓库。 按步骤验证再切换先用 ssh-keygen 生成独立密钥,把公钥加入目标账号的 authorized_keys,并检查目录与文件归属。保留当前连接,在第二个终端验证密钥能登录,再考虑关闭密码认证。这样可以避免一次配置失误把自己锁在服务器外。 日常使用的小结给每台常用主机设置 SSH config 别名,把端口、用户名和密钥路径放在一起。设备停用时,记得从服务器删除对应公钥。
HTTPS 上线之后,还需要维护什么
浏览器出现锁形标记,只说明这次连接满足了相应的 HTTPS 条件。证书续期、域名解析和代理配置仍然需要持续维护。 证书自动续期不是“申请成功”的附带结果证书工具可以申请证书,但定时任务是否安装、验证路径是否保持可达、续期后服务是否重新加载,都需要单独确认。设置自动续期后,还应使用工具支持的测试模式检查整个流程。 HTTP 验证路径要能被访问HTTP-01 通常通过 80 端口下的 /.well-known/acme-challenge/ 验证域名控制权。反向代理、强制认证或错误的站点匹配,都可能使这个路径失效。使用 DNS-01 时,则需维护 DNS API 凭据与自动化配置。 续期成功后,服务可能还在用旧证书部分 Web 服务需要 reload 才会读取更新后的文件。证书工具与 Web 服务在不同容器中时,还要检查挂载路径、权限,以及复制后的文件是否真正更新。 域名验证与协议验证分别进行请求域名时应检查证书主机名、有效期和信任链。TLS 1.3 与 HTTP/2 是独立的协商结果:启用了其中一个,不代表另一个必然可用。 保留最小变更与回滚文件编辑 Nginx 配置...
容器里的 DNS:为什么宿主机正常,应用却解析失败
同一台服务器上,宿主机能访问网站,容器里的程序却提示域名解析失败,并不矛盾。容器有自己的文件系统与网络配置,需要独立确认解析链路。 从 resolv.conf 开始先看宿主机的 /etc/resolv.conf,再运行 docker exec 容器名 cat /etc/resolv.conf。这里的 nameserver 指定解析服务器。如果文件没有有效解析器,不同语言运行时可能使用不同的默认行为。 localhost 的含义取决于网络模式桥接网络里的 127.0.0.1 指向容器自身。把宿主机的本地 DNS 地址照搬进去,经常会失败。host 网络共享宿主机网络空间,但仍要检查容器内的解析配置文件是否有效。 分清 DNS 与 HTTPS 故障“lookup failed”通常发生在建立连接之前;“certificate verify failed”发生在 TLS 校验阶段;“connection refused”则表示连接目标没有接受请求。把这些错误混为一谈,会导致改错配置。 先验证,再持久化可以先在容器内做解析与 HTTPS 请求测试。确认可用后,把 DNS 配置写入 C...