上一篇
三台虚拟主机坏了一台
目前共有三台虚拟主机运行，现其中一台出现故障，已定位问题并紧急抢修，其余两台暂未受影响，业务可通过另外两
事件背景与现状
1 基础架构概况
| 项目 | 详情 |
|---|---|
| 总虚拟主机数 | 3台 |
| 部署模式 | 分布式负载均衡（通过反向代理分发请求） |
| 用途 | Web应用托管、数据库服务、文件存储 |
| 运行环境 | Linux系统 + Nginx/Apache + PHP/Python + MySQL |
2 故障表现
故障主机特征：编号为VM-02的虚拟主机无法响应外部请求，SSH连接超时，控制台显示“实例已停止”。
关联现象：负载均衡器自动剔除该节点，剩余两台主机（VM-01、VM-03）承担全部流量，导致响应延迟上升约30%。
日志关键错误：kernel panic not syncing: VFS: Unable to mount root fs（提示文件系统挂载失败）。
直接影响范围
1 业务层面
| 受影响模块 | 具体表现 | 严重程度 |
|---|---|---|
| 动态网页渲染 | 高并发场景下偶发504网关超时 | ️ 中度 |
| 用户会话保持 | 跨主机会话同步中断，约5%用户需重新登录 | ️ 轻度 |
| 后台任务队列 | Celery任务积压，执行效率下降40% | ️ 中度 |
2 技术层面
资源压力：存活主机CPU利用率峰值达85%，内存占用率超70%；
潜在风险：若另一台主机故障将触发雪崩效应，导致全站不可用；
数据安全：未及时同步的缓存数据存在丢失风险。
应急处理流程
| 阶段 | 操作步骤 | 责任人 | 耗时 |
|---|---|---|---|
| 快速定位 | 查看云平台告警记录 检查系统日志/dmesg输出 |
运维工程师 | 10分钟 |
| 临时修复 | 强制重启故障主机 验证基础服务状态 |
系统管理员 | 15分钟 |
| 流量转移 | 调整负载均衡权重至存活主机，开启健康检查间隔 | DevOps | 5分钟 |
| 根因分析 | 磁盘SMART检测 内核模块完整性校验 |
技术专家 | 2小时 |
| 永久修复 | 更换故障硬盘→重装系统→恢复快照→加入集群 | 全体团队 | 4小时 |
根本原因追溯
直接诱因：VM-02使用的SSD出现坏道，导致系统启动失败；
️ 深层因素：
- 未启用RAID冗余,单盘故障即引发整机宕机；
- 监控阈值设置过高,未能提前预警磁盘异常；
- 自动快照策略缺失,延误故障恢复进度。
改进实施方案
1 短期措施（72小时内）
️ 对所有主机执行smartctl -a /dev/sdX检测磁盘健康度；
️ 修改负载均衡策略为“最少连接数”模式；
️ 启用每日增量备份+每周全量备份。
.2 长期规划（1个月内）
构建Prometheus+Grafana监控系统,重点监控：
- 磁盘I/O延迟（>10ms触发告警）
- 内存交换区使用率（>20%预警）
- 服务进程存活状态；
实施LVM逻辑卷管理，实现磁盘热备替换；
编写Ansible剧本标准化环境重建流程。
相关问题与解答
Q1: 如果另外两台主机也相继故障怎么办？
A: 应立即激活灾备方案：①切换至备用数据中心；②启用CDN静态资源加速；③通过DNS轮询分流用户至合作方站点,建议日常维护至少2个地理上分散的可用区。
Q2: 如何判断是否需要扩容而非仅仅修复？
A: 根据以下指标决策：
| 指标 | 扩容阈值 | 当前值 |
|———————|—————————|————–|
| 日均PV/单机承载量 | >80%持续3天 | 72% |
| 突发流量峰值响应时间 | >2秒且QPS>设计值的120% | 1.8秒/110% |
| 未来3个月增长预测 | 预计超过现有容量的150% | 130% |
当前可暂不扩容，但需在下季度前完成
