运维不是救火，是防火

苏州工业园区一家做工业物联网的公司，服务器三年没出过一次故障。他们IT主管跟我说了句话：运维做得好，就是让你感觉没事干。听起来矛盾，其实是最高境界。

太多苏州中小企业没有专职运维，服务器扔在机房就不管了，出事才找人救火。姑苏区一家餐饮连锁的官网服务器，两年没人维护，磁盘满了导致MySQL崩溃，丢了3个月的数据。这种事完全可以避免。

下面这份清单是我们服务苏州企业多年总结出来的，按日、周、月三个频率执行，照着做基本不会出大问题。

每天花10分钟做这5件事

1、看服务器负载。SSH上去执行top命令，看load average。这个值长期超过CPU核数×0.7就该关注了。8核服务器load超过5.6就要查原因。

2、检查磁盘空间。df -h看各分区使用率。超过80%就该清理了。苏州很多企业日志不轮转，/var/log一个月就能撑爆磁盘。昆山一家电子厂就因为日志文件占满了根分区，导致整个系统无法登录。

3、看关键服务状态。systemctl status nginx mysqld php-fpm，确认核心服务都在跑。建议装个监控脚本，服务挂了自动重启并发钉钉通知。盛泽一家纺织电商用了个简单的shell脚本，凌晨数据库崩了，3秒内自动拉起，老板第二天看日志才知道。

4、检查异常登录。last命令看最近登录记录，lastb看失败登录。如果发现凌晨3点有陌生IP尝试SSH登录，赶紧改密码封IP。太仓一家德资企业的服务器被暴力破解了root密码，就是因为没装fail2ban、没改SSH端口。

5、看备份是否成功。异地备份每天跑一次，执行完检查备份文件大小和时间戳。苏州BioBay一家生物医药公司的做法很规范：备份脚本执行完自动发邮件，附件是备份文件的大小和MD5校验值。大小异常或校验不对，立刻报警。

每周做一次的深度检查

周检比日检深入，花30分钟左右。

看慢查询日志。MySQL开slow_query_log，阈值设1秒。每周看一次，慢查询多的就优化。吴中一家机器人公司的订单查询SQL从2.3秒优化到0.04秒，就是靠周检发现并加索引解决的。

检查安全更新。yum check-update或apt list --upgradable看有哪些待更新补丁。重要的安全补丁及时打，非紧急的选维护窗口统一打。工业园区一家SaaS公司固定每周日凌晨2点做更新维护，客户提前收到通知，几乎零投诉。

分析访问日志。看流量趋势、异常请求、爬虫占比。苏州一家做周庄民宿预订的平台发现百度蜘蛛每天抓1.2万次页面，占带宽40%，配了robots.txt限频后带宽费用降了三成。

检查SSL证书有效期。这事儿特别容易被忽略。常熟一家服装批发商的网站SSL证书过期了3天才发现，浏览器报不安全，客户不敢下单，损失了好几万。设个日历提醒，过期前30天续办。

测试灾备恢复。别只备份不恢复。每周抽一个备份文件做恢复测试，确保数据完整可用。张家港一家钢材贸易商第一次做恢复测试就发现备份文件损坏——备份脚本半年前就报错了，没人看通知邮件。

每月的系统性体检

月检是全面体检，花1-2小时。

做一次完整性能评估。用top、iostat、vmstat、sar收集一周的性能数据，分析趋势。CPU、内存、磁盘IO、网络流量这四个核心指标如果呈持续上升趋势，说明要扩容了。提前规划比临时救急从容得多。

清理冗余数据。旧日志、临时文件、废弃的数据库表、过期的备份文件。苏州很多企业服务器上堆着3年前的日志和测试数据，占了40%的磁盘空间。写个清理脚本，定期跑。

审查用户权限。检查系统用户、数据库用户、FTP用户，删除离职人员和废弃账号。工业园区一家SaaS公司去年审查发现，3个离职员工的SSH密钥还能登录服务器，吓出一身冷汗。

更新文档。服务器拓扑图、IP分配表、服务清单、应急预案，这些文档要跟实际保持一致。出了事翻文档照着操作，比临时抓瞎快10倍。

做一次安全扫描。用Nessus或者开源的OpenVAS扫一遍漏洞，用nmap扫一遍开放端口。发现问题及时处理。苏州本地有安全公司提供一次性扫描服务，费用2000-5000元，比被攻击了再补救便宜得多。

统计当月故障和告警。分析故障原因和频率，找出薄弱环节做针对性改进。昆山一家电子厂统计发现80%的故障发生在月底——因为月底跑批量报表导致资源耗尽，后来把报表任务错峰到凌晨3点执行，故障率降了90%。

运维这活儿说白了就是：不偷懒就不会出大事。清单贴在工位上，照着做，10分钟的事能避免10小时的故障。苏州很多中小企业不舍得在运维上投入，等到服务器挂了、数据丢了、客户跑了，才发现省的那点运维费根本不够赔。