年终服务器检查清单：10项必备设置

年终需要检查的服务器设置 10 项

(为了防止任何意外发生)

“年终就特别需要检查吗？” 结论是需要。

年终并不会让服务器变得特殊，但人会变得特殊。

节假日人手减少
流量模式失常
紧张感放松

因此年终往往成为事故概率与风险最高的时期。本文不是“年终一定要做”的强迫性清单，而是 在假期期间确保一切顺利的现实检查列表。

1. 磁盘使用量与日志增长速度

年终并不会让日志量下降。

尤其要检查：

/var/log 使用量
应用日志轮转设置
Docker 容器日志大小（json 日志是否无限增长）

磁盘满的服务器会无预警停机。平时能忍受的情况，在假期也可能直接导致故障。

2. 备份是否“存在”而非“可恢复”

备份文件是否存在比备份本身更重要。

“这真的能恢复吗？”

年终前至少做一次以下操作：

确认最近的备份文件是否存在
简单验证压缩文件是否损坏
在测试环境直接恢复

避免新年第一天发现“备份损坏”。

3. SSL/TLS 证书到期日

年末年初是证书到期事故频发期。

Let’s Encrypt 自动续期是否正常
cron 或 systemd timer 是否被禁用
最近续期日志是否有错误

“自动续期没问题”往往是年终最常见的故障触发器。

4. 防火墙规则与“临时”开放设置

一年运营下来会积累许多临时配置。

测试用开放的端口
临时开放的 IP
已不再使用的服务端口

这些临时设置随着时间会变成没人记得的安全漏洞。年终是整理它们的最佳时机。

5. SSH 访问方式与密钥管理

假期期间的攻击往往被延迟发现。

因此 SSH 设置要特别保守。

是否禁用密码登录
删除未使用的 SSH 密钥
移除离职员工或外包人员的密钥
管理员账号是否仅拥有最低权限

“服务器没人关心”是安全方面的常见错误假设。

6. cron/调度器的悄悄失败

cron、systemd timer、作业调度器 即使失败也会悄悄失效。

最近执行日志是否有错误
长期失败的作业是否存在
不再需要的作业是否仍在运行

年终出现的调度器故障会在新年继续存在。

7. 资源使用量以“峰值”而非“平均”衡量

年终流量波动更大。

某段时间流量激增
机器人/爬虫异常访问
某国假期模式

监控时应查看峰值而非平均值。

CPU、内存峰值
DB 连接数、队列长度
并发用户数、会话数

“平时没问题”在年终往往不成立。

8. 应用依赖服务状态

服务器本身正常，但依赖服务宕机也会导致整体停机。

例如：

Redis / Memcached
消息代理（Kafka、RabbitMQ、SQS 等）
外部 API（支付、认证、通知等）
文件/图片存储

年终这些服务也会频繁检查、部署、定期任务。故障时常出现“日志干净但服务停了”的情况。建议同时检查依赖服务的状态页面或故障通知渠道。

9. 错误通知是否真正“到达”

拥有错误通知系统与通知实际到达是两回事。

人为触发一次错误
邮件/Slack/Webhook 是否真正收到
严重度过滤是否导致被忽略

年终故障的最大问题往往是没人知道。

“没人知道故障发生了”

10. “出现问题时从哪里开始”整理好的文档

最后一项是文档，而非设置。

主要服务列表
服务器/容器登录方式
日志位置（nginx、app、DB、队列等）
重启/回滚方法
紧急响应顺序

有无这份文档决定了年终故障响应难度是硬模式 ↔ 普通模式。