服务稳定性通常不是从增加更多工具开始，而是从统一问题的描述方式开始。对大多数小型服务而言，延迟、流量、错误和饱和度已经足以覆盖第一阶段的判断。 延迟 同时记录平均值和高分位值。平均延迟适合观察趋势，P95 与 P99 更容易暴露少量请求被阻塞的问题。 流量与错误 请求总量需要和错误率一起观察。只有错误数量而没有总请求量，无法区分一次偶发失败和系统性故障。 饱和度 CPU 使用率不是唯一指标。内存、文件描述符、连接数、磁盘空间和 I/O 等待都可能先于 CPU 到达限制。 监控的目标不是收集尽可能多的数据，而是在故障发生时快速回答：问题从何时开始、影响了什么、资源是否到达边界。
内容更新频率不高、没有用户登录和实时写入需求时，动态应用往往增加了不必要的维护面。静态生成器把模板和内容在构建阶段合成为普通文件，生产环境只负责读取和发送。 更小的运行边界 线上不需要数据库、脚本解释器、包管理器或管理后台。减少组件数量，也减少了需要持续修复的入口。 更清晰的发布过程 构建产物可以独立校验、打包和回滚。迁移时只需要复制静态文件和 Web 服务器配置，不涉及数据迁移。 仍然需要的防护 静态并不代表无需维护。Web 服务器、TLS 证书、安全响应头、访问日志和源代码依赖仍需要定期检查。
TCP 超时看起来只有一个结果，但可能发生在完全不同的位置。先区分 DNS、路由、握手和应用响应，通常比反复重启服务更快。 从客户端确认路径 先记录解析结果，再分别测试 IP 和域名。ping 只能说明 ICMP 的结果，不能证明 TCP 端口可达。使用 traceroute、nc 和 openssl s_client 可以把问题分别定位到路由、TCP 和 TLS。 在服务器确认监听 ss -lntp 用于确认地址和端口。只监听 127.0.0.1 的服务不会接受公网连接；监听正常时，再检查防火墙计数和服务日志是否出现对应来源。 避免过早归因 同一服务器从一个网络可达、另一个网络超时，往往说明问题在中间路径。保留不同运营商和境外探针的结果，有助于区分服务器故障与线路问题。
Restart=always 可以提高短暂故障后的恢复速度，也可能把配置错误变成持续的重启循环。服务单元需要同时考虑重启策略、频率限制和资源上限。 区分退出原因 对网络服务通常使用 Restart=on-failure，并通过 RestartPreventExitStatus 排除明确不应重试的退出码。启动前增加配置检查，可以避免错误配置进入循环。 限制重启频率 StartLimitIntervalSec 和 StartLimitBurst 应根据服务启动时间设置。限制触发后保留失败状态，比每秒重启一次更利于排查。 留出诊断空间 资源限制不能只写最大文件描述符。内存上限、任务数量和日志速率都应结合正常峰值设置，并在修改后做一次故障演练。
DNS 切换本身很快，真正不可控的是各层缓存。迁移前一天降低 TTL，只对尚未缓存的新记录有效，因此必须提前安排。 切换前 在旧服务器继续提供服务的前提下，将记录 TTL 降到五分钟左右。新服务器使用临时域名或本地 hosts 完成证书、健康检查和数据校验。 切换时 保留旧服务器，不立即删除配置。修改记录后从多个递归 DNS 和不同网络检查解析，同时观察新旧两端访问日志。 切换后 至少等待原 TTL 和本地缓存窗口结束，再停止旧服务。稳定运行一天后恢复较长 TTL，减少权威 DNS 的查询压力。
备份文件存在不代表数据可恢复。数据库版本、扩展、角色和权限都可能让恢复过程失败，因此恢复演练应成为备份任务的一部分。 选择备份格式 小型数据库可以使用自定义格式的 pg_dump，便于选择对象和并行恢复。实例级角色需要使用 pg_dumpall --globals-only 单独保存。 在隔离环境恢复 恢复目标不能覆盖生产库。创建临时数据库，先恢复角色与扩展，再导入数据，最后运行表数量、关键行数和业务查询检查。 记录恢复时间 备份策略还需要回答恢复需要多久。随着数据增长，原本十分钟的恢复可能变成数小时，应定期记录耗时并调整 RTO。
容器宿主机磁盘不足时，直接执行清理命令容易误删仍在使用的数据。先区分镜像、容器可写层、卷和日志，处理才能可控。 查看真实占用 docker system df -v 提供对象视角，du 则能看到文件系统中的实际大小。两者差异较大时，应检查日志目录和已删除但仍被进程打开的文件。 设置日志轮转 默认 json-file 日志可能持续增长。通过 daemon 配置设置 max-size 和 max-file，并在重启 Docker 前确认对现有业务的影响。 不要清理未知卷 没有容器引用的卷不一定无用，可能属于暂停的迁移或备份流程。删除前应结合 Compose 文件和挂载点确认所有权。
证书自动续签经常在部署当天显示正常，却在两个月后因为端口、DNS 或权限变化而失败。最有效的检查不是查看 timer 状态，而是运行完整的模拟续签。 验证挑战路径 HTTP-01 依赖公网 80 端口和正确解析，DNS-01 依赖有效的 API 凭据。选择方式后，要明确哪个进程在验证期间占用端口。 验证部署钩子 证书文件更新后，Web 服务通常还持有旧证书。续签成功必须触发平滑 reload，并确认 reload 失败能够在日志和监控中暴露。 提前告警 除了检查任务退出码，还应直接读取线上证书的剩余有效期。这样即使续签程序本身异常，也能在到期前留下处理窗口。
Linux 会主动利用空闲内存缓存文件，因此 used 很高通常是正常现象。判断是否紧张，应优先观察 available、交换活动和内存压力。 区分页缓存与匿名内存 页缓存在需要时可以回收，应用堆和匿名映射通常不能直接回收。/proc/meminfo、smem 和 cgroup 指标可以帮助确认内存由谁持有。 观察压力而不只是容量 持续 swap in/out、直接回收和 PSI memory pressure 比单个使用率更能反映实际影响。如果服务有 cgroup 限制，还需要同时查看容器内部和宿主机。 为故障保留证据 OOM 后应查看内核日志中的被杀进程、RSS 和 cgroup。只重启服务会丢失最有价值的容量信息。
公网 SSH 被持续扫描是常态。加固重点不是隐藏端口，而是确保扫描者无法完成认证，同时保留管理员自己的恢复路径。 只保留密钥认证 确认新密钥可以登录后，再关闭密码认证和空密码。直接修改配置前运行 sshd -t，并保持当前会话不退出，避免配置错误导致失联。 控制认证压力 合理设置 MaxAuthTries、LoginGraceTime 和并发握手限制。Fail2ban 可以降低日志噪音，但不能替代密钥认证。 准备恢复路径 云平台控制台、独立管理网络或备用端口必须至少保留一种。修改防火墙后应从外部重新连接验证，而不是只看服务器本机监听状态。