故障响应流程
故障响应规范
响应时间要求
不同优先级的响应时间：
P1 故障（业务中断）：
接报后 15 分钟内：电话回拨确认
接报后 1 小时内：远程接入开始排查
接报后 4 小时内：现场工程师到达（省会城市）
目标：4 小时内恢复业务
P2 故障（业务降级）：
接报后 30 分钟内：电话回拨
接报后 2 小时内：远程排查
目标：8 小时内恢复
P3 故障（非核心功能）：
接报后 2 小时内：响应
目标：2 个工作日内解决故障处理 SOP
P1 故障处理 SOP
P1 故障处理标准操作流程：
T+0：接到故障报告
- 记录故障时间、报告人、联系方式
- 初步了解故障现象
- 立即升级通知（TAC 主管 + 客户经理）
T+15分钟：电话回拨客户
- 确认故障现象
- 了解影响范围
- 获取远程访问权限
T+30分钟：远程接入排查
- 登录管理平台，查看系统状态
- 收集日志和告警信息
- 初步判断故障原因
T+1小时：故障定位
- 确定故障根因
- 制定修复方案
- 评估修复风险
T+2小时：执行修复
- 按修复方案操作
- 实时与客户沟通进展
- 记录所有操作步骤
T+4小时：业务恢复
- 验证业务恢复
- 客户确认
- 发送故障通报
T+24小时：RCA 报告
- 根因分析
- 改进措施
- 发送给客户常见故障排查
CloudOS 管理平台不可用
bash
# 排查步骤
# 1. 检查 VIP 是否正常
ping <management-vip>
ip addr show | grep <vip>
# 2. 检查 Keepalived 状态
systemctl status keepalived
journalctl -u keepalived -n 50
# 3. 检查 HAProxy 状态
systemctl status haproxy
haproxy -c -f /etc/haproxy/haproxy.cfg
# 4. 检查 API 服务
systemctl status openstack-nova-api
systemctl status openstack-keystone
systemctl status openstack-neutron-server
# 5. 检查数据库
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_%';"
# wsrep_cluster_size 应为 3
# wsrep_local_state_comment 应为 Synced
# 6. 检查消息队列
rabbitmqctl cluster_status
rabbitmqctl list_queues | grep -v "^0" # 查看积压队列
# 常见修复操作
# 重启 API 服务
systemctl restart openstack-nova-api
systemctl restart openstack-keystone
# 修复 Galera 集群（谨慎操作）
# 找到最新节点（seqno 最大）
cat /var/lib/mysql/grastate.dat
# 在最新节点上引导集群
galera_new_cluster虚拟机无法创建
bash
# 排查步骤
# 1. 查看 Nova 日志
tail -f /var/log/nova/nova-conductor.log | grep ERROR
tail -f /var/log/nova/nova-scheduler.log | grep ERROR
# 2. 检查计算节点状态
openstack compute service list
# 确认所有 nova-compute 服务状态为 up
# 3. 检查资源是否充足
openstack hypervisor stats show
# 查看 free_vcpus, free_ram_mb, free_disk_gb
# 4. 检查镜像是否可用
openstack image show <image-id>
# 状态应为 active
# 5. 检查网络是否正常
openstack network list
openstack subnet list
# 6. 手动测试创建（带详细日志）
openstack server create \
--flavor c1.small \
--image <image-id> \
--network <network-id> \
--debug \
test-debug-vm
# 7. 查看 VM 错误信息
openstack server show <vm-id> | grep fault存储 IOPS 下降
bash
# 排查步骤
# 1. 检查 Ceph 集群状态
ceph status
ceph health detail
# 2. 检查 OSD 性能
ceph osd perf
# 关注 commit_latency_ms 和 apply_latency_ms
# 正常值：< 10ms，异常：> 100ms
# 3. 检查是否有数据重建
ceph pg stat | grep -v "active+clean"
# 4. 检查 OSD 磁盘健康
for osd in $(ceph osd ls); do
smartctl -H /dev/$(ceph osd metadata $osd | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('devices','').split(',')[0].split('/')[-1])")
done
# 5. 检查网络
# 存储网络丢包会严重影响 Ceph 性能
ping -c 100 <storage-node-ip> | tail -5
# 6. 检查 OSD 日志
journalctl -u ceph-osd@0 -n 100 | grep -E "slow|warn|error"
# 常见修复
# 重启性能异常的 OSD
systemctl restart ceph-osd@<osd-id>
# 调整 OSD 内存（如内存不足）
ceph config set osd osd_memory_target 4294967296 # 4GB网络不通
bash
# VM 网络故障排查
# 1. 确认 VM 内部网络配置
# 登录 VM
ip addr show
ip route show
cat /etc/resolv.conf
# 2. 检查安全组规则
openstack security group rule list <sg-id>
# 3. 检查 OVS 状态（在宿主机上）
ovs-vsctl show
# 确认 VM 的 tap 接口已连接到 br-int
# 4. 检查 OVS 流表
ovs-ofctl dump-flows br-int | grep <vm-mac>
# 5. 检查 Neutron 代理
openstack network agent list
# 确认所有代理状态为 alive
# 6. 抓包分析
# 在宿主机上抓 VM 的流量
tcpdump -i <tap-interface> -n -w /tmp/vm-traffic.pcap
# 7. 检查 VxLAN 隧道
ovs-vsctl show | grep -A5 "type: vxlan"
# 确认隧道端点 IP 正确
# 常见修复
# 重启 Neutron 代理
systemctl restart neutron-openvswitch-agent
systemctl restart neutron-l3-agentRCA（根因分析）报告
根因分析报告模板：
故障编号：INC-2024-0115-001
故障时间：2024-01-15 14:30 - 16:45（持续 2 小时 15 分钟）
影响范围：生产环境所有 VM 无法创建
严重程度：P1
一、故障描述
2024-01-15 14:30，客户反映无法创建新虚拟机，
已有 VM 运行正常，管理平台可以访问。
二、时间线
14:30 - 客户发现问题，联系 H3C TAC
14:45 - TAC 工程师远程接入
15:00 - 定位到 Nova Scheduler 服务异常
15:30 - 发现 RabbitMQ 消息队列积压
16:00 - 重启 RabbitMQ 集群
16:30 - 验证 VM 创建恢复正常
16:45 - 客户确认，故障关闭
三、根本原因
RabbitMQ 节点2 磁盘空间不足（/var/lib/rabbitmq 占用 98%），
导致消息无法写入，Nova Scheduler 无法接收调度请求。
四、直接原因
RabbitMQ 日志文件未配置轮转，持续增长占满磁盘。
五、修复措施
临时措施：清理 RabbitMQ 日志，重启服务
永久措施：
1. 配置 RabbitMQ 日志轮转（logrotate）
2. 增加 /var/lib/rabbitmq 磁盘告警（阈值 80%）
3. 扩展 RabbitMQ 节点磁盘容量
六、预防措施
1. 完善磁盘使用率监控（所有关键目录）
2. 定期检查日志配置
3. 建立磁盘容量规划流程
七、经验教训
中间件服务的磁盘监控不能只监控根分区，
需要针对关键目录单独设置告警。