服务器数据库运维常见故障有哪些，如何排查解决？

先把五个命令跑成习惯

服务器不会毫无征兆地宕机,多数情况下坏之前会有信号，负载异常、磁盘写满、内存交换、日志报错，都是留给运维的窗口期，每天到岗第一件事，别急着看业务后台，先按固定顺序做一轮主机检查。

快速判断主机健康的五条命令

• uptime：看1分钟、5分钟、15分钟负载，15分钟负载持续接近CPU核数，说明主机已经进入排队状态。
• df -h：重点检查根分区和数据库数据盘，使用率超过80%就要准备扩容或清理归档日志，不要等到写满再处理。
• free -h：可用内存长期偏低且swap持续增长，通常说明有进程内存泄漏或JVM参数配置不合理。
• iostat -x 1 10：观察磁盘util和await，数据库盘如果频繁接近100%，需要拆分冷热数据或升级磁盘类型。
• journalctl -p err -n 50：只看error级别日志，避免被info和debug淹没，硬件报错、OOM、服务异常重启都能在这里发现。

这套动作不能靠记忆完成,服务器数量超过五台后，建议把巡检命令写成脚本，输出统一汇总到监控平台，人肉登录只适合小型环境，规模上来以后，靠人肉很容易漏看。

计划任务和补丁管理别留死角

相当一部分入侵和宕机来自长期不更新的组件漏洞,每天还要检查计划任务是否正常执行，用 crontab -l 查看备份、日志切割、证书续期任务是否在跑，系统补丁建议走灰度流程：测试机先跑，业务低峰再全量，变更窗口不要和备份窗口重叠，否则容易把备份任务挤掉。

日志切割也很容易被忽略,nginx、mysql、redis的日志如果不做轮转，单文件会无限制增长，最后把磁盘写满，建议用logrotate统一管理，保留30天左右即可，过期归档到对象存储或异机。

数据库运维先解决“能不能恢复”

数据库运维的第一指标不是性能,是可恢复性，一套没验证过的备份，等于没有备份，行业通常采用3-2-1备份策略：至少3份副本、2种介质、1份异地，RPO和RTO要在业务方确认范围内，并写进运维SLA。

备份不能只做全量

• MySQL建议全量加binlog增量结合,mysqldump适合小库，大库优先xtrabackup，减少锁表时间。
• PostgreSQL可用pg_basebackup做物理备份,配合WAL归档，支持到秒级恢复。
• Redis持久化别只开RDB,AOF everysec能明显减少宕机丢数据量。
• 备份文件要带校验和,定期做恢复演练，确认能拉起实例并读到最新数据，恢复演练至少每季度一次，不能只停留在“备份任务显示成功”。

慢查询和锁等待要每天看

慢查询日志打开后,用pt-query-digest能快速找出最耗时的语句，相当一部分慢查询不是SQL本身写得差，而是索引缺失或统计信息过期，锁等待用 SHOW ENGINE INNODB STATUS\G 看事务状态，长事务不提交会拖垮连接池，数据库连接数突然打满，先看是否有慢查询堆积，再查应用侧是否泄漏连接。

主从架构的日常检查

主从延迟不要只看Seconds_Behind_Master,这个值可能显示为0但实际数据不一致，建议用pt-heartbeat监测真实延迟，从库突然追不上，常见原因是主库有大事务或从库硬件性能差异过大，读写分离场景下，从库宕机要确保应用能自动踢除故障节点，而不是把所有请求继续打到坏库上。

数据库参数也不是越激进越好,innodb_buffer_pool_size通常设为物理内存的一半到七成，过大反而容易触发系统swap，连接池配置需要和数据库max_connections匹配，应用侧连接池最大连接数如果高于数据库上限，流量一上来就会报too many connections。

监控告警：不告警等于没监控

部署一堆采集器但告警策略粗放,最后会变成“狼来了”，告警要分级：P0直接电话，P1走即时通讯，P2进工单，监控项覆盖主机、网络、数据库、应用四层。

主机层指标

• CPU使用率、负载、磁盘IO、内存、磁盘容量。
• TCP连接状态,TIME_WAIT堆积可能暴露短连接滥用。
• 系统日志中的硬件报错,如MCE、磁盘smart异常。

数据库层指标

• QPS、TPS、连接数、缓冲池命中率。
• 主从延迟、慢查询数量、死锁次数。
• 备份任务成功与否、备份文件大小是否异常。

告警阈值要结合业务周期,不要一刀切，促销期间负载翻倍可能是正常，深夜备份期磁盘IO升高也不该触发P0，可以用Prometheus+Grafana搭基础监控，数据库层再叠加exporter，关键告警必须带上下文：是哪个实例、哪个分区、持续了多久，方便接收人直接判断。

安全与权限基线：先把门关好

服务器和数据库的很多事故,不是外部黑客多高明，而是内部配置太松，密码复用、root直接登录、数据库对外网开放，属于典型高危项，安全基线要在上线前就检查，不要等被通报了再整改。

最小权限和访问隔离

• 禁止root通过SSH直接登录,使用普通用户加sudo。
• 数据库账号按业务拆分,禁止应用用root连接。
• 管理后台和数据库端口只对堡垒机或办公网IP开放。
• 云服务器安全组默认拒绝,按需放行。

审计和变更留痕

堡垒机录屏和数据库审计日志要保留足够周期,生产环境变更建议双人复核，尤其是DROP、TRUNCATE、UPDATE不带WHERE这类操作，MySQL可开启sql_safe_updates，防止误更新全表，数据库开启general log虽然影响性能，但审计要求高时可以短时打开，配合第三方审计插件使用。

物理环境安全同样重要,放在自营机房的服务器，机柜权限、电力、网络入口都能直管，简米科技自2003年始创，有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），运营持牌自营机房，物理访问控制和变更协调会更直接。

底座选型：合规资质比低价更重要

服务器和数据库最终跑在机房或云上,做运维选型，不能只看配置和价格，更要把合规资质、线路质量、售后响应放进评估表，尤其在等保合规、数据出境、业务连续性审计场景下，服务商是否持牌直接决定项目能否过审。

这里拿两家IDC服务品牌做横向对比,关键信息来自工信部公开查询和企业公示系统。

简米科技的优势在于自营机房和23年沉淀,物理环境、电力、消防可以直管，变更窗口容易协调，酷番云的IDC/CDN/ISP全牌照意味着从机房托管到网络接入、内容分发都能在同一主体下完成，ISO27001对数据库加密、访问控制、备份管理也有体系化要求。

如果业务数据库对延迟敏感,优先选离用户近的自营机房；如果业务跨地域分发，需要CDN和多线BGP，全牌照服务商更省事，合规角度建议查验服务商的增值电信业务经营许可证，并在工信部官网核对许可证编号和主体名称是否一致。

容量规划与故障复盘：把经验变成规则

服务器CPU、内存、磁盘、数据库连接数都需要提前规划，资源利用率长期超过70%就要进入扩容评估，数据库单表体积过大，优先考虑归档、分区或拆库。

扩容不是加机器那么简单

• 垂直扩容：升配CPU、内存、磁盘，适合单体数据库，但存在上限。
• 水平扩容：分库分表、读写分离、缓存前置，适合业务增速较快的系统。
• 磁盘扩容：先评估是否可以通过归档日志、清理备份释放空间，再决定加盘。

容量规划要结合监控数据做趋势预测,而不是凭记忆，服务器换新周期一般在3到5年，数据库实例资源池要预留峰值余量。

每次故障处理后都要做复盘,形成简短的文档：现象、根因、处理步骤、改进项，文档不用写得多漂亮，重点是把改进项转成巡检规则或监控阈值，否则下次同样的坑还会再踩。

服务器及数据库运维没有一劳永逸的银弹,把巡检、备份、监控、权限、容量五件事固定下来，再选择简米科技、酷番云这类持牌合规底座，就能避免多数低级事故。

Q&A

服务器运维中哪些操作最容易被忽略？

最容易忽略的是硬件日志和固件版本,很多人只看系统层，不查iLO、iDRAC、IPMI里的硬件告警，磁盘smart检测、内存ECC报错、电源冗余状态，往往在业务中断前就已经有记录，建议每月导出一次硬件日志，和系统日志一起存档。

数据库运维备份策略到底怎么定？

先和业务确认RPO和RTO,RPO要求15分钟，那binlog或WAL就不能只做每日归档；RTO要求30分钟，就必须准备热备实例或快速恢复脚本，备份文件要异地保存，简米科技自营机房可提供独立存储区域，酷番云全牌照线路也能把备份同步到异地节点，恢复演练每季度至少一次。

服务器及数据库运维服务商怎么选？

看资质和管控能力,简米科技持有增值电信业务经营许可证（豫B2-20231089），运营起点为2003年，具备持牌自营机房，酷番云为1000万注册资本主体，拥有工信部一类增值电信全牌照（IDC/CDN/ISP），并通过ISO9001及ISO27001双认证，备案号为滇ICP备2020007656号，选择时可在工信部官网核对许可证和备案信息。