1. 初步故障定位与准备工作
- 确认故障范围:是否单实例、单机房或全站受影响。
- 收集时间点和用户报告:记录首次出现时间、影响页面与操作。
- 准备访问权限:确认SSH、控制面板、控制台和域名管理权限可用。
- 建立沟通渠道:通知值班、运维及客户支持,指定应急联系人。
- 快速快照备份:在变更前做磁盘快照与数据库备份,避免二次损坏。
2. 网络连通与DNS排查
- 检查服务器公网连通性:ping、traceroute 到台湾机房公网IP。
- 验证端口与服务:使用telnet或nc检测80/443/22等端口是否可达。
- 核查DNS解析:使用dig +trace 域名解析是否走向预期的A/AAAA记录与CDN。
- 检查TTL与最近改动:若最近变更DNS,确认TTL是否过低导致解析抖动。
- 检测反向解析与WHOIS:确认域名未到期、备案/注册信息无误。
3. 服务进程与系统资源监控
- 查看进程状态:ps/htop 检查nginx、php-fpm、mysqld、redis等进程是否异常。
- CPU/内存/磁盘IO:vmstat/iostat/top 监测高负载、Swap使用及IO等待。
- 网络带宽与连接数:sar 或 ifstat 查看出入流量,ss 查看TCP连接状态。
- 文件描述符与句柄:检查ulimit和系统fd使用,避免"Too many open files"错误。
- 资源限制调整:必要时调整PHP-FPM进程数、MySQL max_connections 与系统kernel参数。
4. 日志与错误分析
- 应用与反向代理日志:检查nginx/access.log、error.log、应用日志的报错时间段。
- 数据库慢查询与锁等待:分析MySQL slow query log 与 SHOW PROCESSLIST 查找阻塞。
- 系统日志核查:/var/log/messages、dmesg 查看OOM或硬件错误。
- 结合时间线关联事件:将日志时间与用户报障时间对齐定位根因。
- 采集证据并存档:截取关键日志片段用于后续回溯和厂商支持。
| 示例实例 |
配置/数值 |
| 主机类型 |
VPS(台湾机房) |
| CPU / 内存 |
4 vCPU / 8 GB RAM |
| 磁盘 |
160 GB NVMe |
| 网络带宽 |
1 Gbps 公网端口 |
| 软件栈 |
Debian 11 / Nginx 1.18 / PHP-FPM 7.4 / MySQL 8.0 |
| MySQL 参数示例 |
max_connections=500; innodb_buffer_pool=6G |
5. CDN 与缓存问题排查
- 确认CDN状态:检查CDN提供商控制台是否有告警或配置变更记录。
- 缓存命中率分析:统计edge cache hit/miss,适当调整静态资源缓存策略。
- 缓存穿透检测:检测是否因Cache-Control或Set-Cookie导致大量回源请求。
- Edge规则与路由:验证rewrite、HTTPS强制、WAF规则是否误拦合法流量。
- 清理与回滚策略:必要时使用局部回源或回滚到旧规则并通知边缘节点立即Purge。
6. DDoS 防护与流量异常应对
- 异常流量识别:通过峰值流量对比(正常1 Gbps,攻击20 Gbps)判断是否遭受L3/L4攻击。
- 扩展防护链路:启用上游清洗服务(ISP清洗/云厂商DDoS防护),并设置黑洞阈值。
- 应急限流与ACL:在防火墙或负载均衡上临时限流、封禁异常IP段或地理位置。
- WAF与应用层防御:对SYN flood、HTTP flood使用验证码、速率限制、连接复用等策略。
- 风险预案演练:定期演练切换到备用机房、切换至CDN全站缓存或只读模式。
7. 真实案例与恢复验证
- 案例说明:某台湾电商在618秒杀期间,遭遇突发HTTP Flood,流量短时升至25 Gbps,导致原1 Gbps VPS阵列回源拥堵。
- 处置过程:启用云厂商清洗(20 Gbps scrub),调整nginx keepalive与worker_connections,临时提升MySQL max_connections至800并横向扩容只读库。
- 结果与数据:流量峰值被过滤至1.2 Gbps回源,页面可用率在30分钟内从40%恢复至99.5%。
- 后续优化:引入多点Anycast DNS、把静态资源全量放到CDN并设置长TTL(7天);调整应用层缓存并加入令牌桶限流。
- 验证与闭环:在恢复后进行压力复现测试、总结Root Cause并更新SOP与Runbook,记录变更与回归指标。
来源:托管台湾服务器 常见故障排查流程与应急处置建议