接手华为云Stack运维的这两年里我处理过大大小小几十起故障从底层物理机磁盘写满到上层数据库实例直接卡死踩过的坑攒起来能写满好几页笔记。不少同行找我要应急预案模板但说实话应急预案这东西最怕照搬——每个环境的物理拓扑、版本补丁、业务模型都不一样真正能救命的不是模板里的漂亮表格而是故障现场那些从实战里磨出来的判断逻辑和处置套路。这篇内容我就结合自己的实操经历把从IaaS到PaaS的典型故障场景、恢复步骤和避坑要点系统梳理一遍给正在玩华为云Stack的朋友一个可以直接落地的参考。先交代下我这套方案适用的环境基于华为云Stack 8.x版本FusionSphere/OpenStack架构计算采用KVM虚拟化存储以OceanStor/FusionStorage为底座PaaS侧以RDSMySQL、DCSRedis、CSE微服务和容器集群为主。如果你的版本或组件有差异命令细节可能需要微调但排查思路和恢复逻辑是通用的。下面按“整体设计 → IaaS场景 → PaaS场景 → 工具与人 → 坑位总结”这条线来讲。1. 华为云Stack应急预案的整体设计思路1.1 IaaS与PaaS两类故障域两种处置哲学很多人做应急预案时习惯把所有故障混在一起写这是第一个大坑。IaaS和PaaS虽然跑在同一朵云上但故障的影响模型和处置逻辑几乎完全不同。IaaS层本质是资源抽象与隔离故障落脚点是“资源不可用”。比如计算节点宕机虚拟机起不来存储池容量满了卷无法创建网络节点异常租户VPC互不通。这一层的恢复手段相对粗暴——切换、重建、迁移、扩容。只要控制面没问题数据面挂了就用冗余去顶重点在于“快”。PaaS层则是平台服务能力故障落脚点是“业务不可用”。数据库写不进、缓存连接超时、消息积压、服务注册中心脑裂随便一个都会直接打到应用侧。PaaS的恢复不能无脑重启因为涉及到数据一致性、服务发现、状态同步处置重点从“快”转向“稳”。有时候宁可让业务多抖一两分钟也要先确认数据状态和主从关系防止二次伤害。我自己的习惯是应急预案从设计上就把两者拆开IaaS 一套文档PaaS 一套文档甚至故障值班时叫人也分开——IaaS问题找基础设施组PaaS问题找中间件组避免鸡同鸭讲。1.2 预案先分级、再定策略的四个核心要素写预案的第一步不是列场景而是定分治规则。推荐先建立故障定级标准用“影响范围 业务损失”两个维度交叉定级P0核心业务整体不可用比如控制台挂了、所有租户ECS无法操作、数据库集群全挂。P1部分租户或非核心业务受影响但有绕过方案或临时降级窗口。P2资源容量预警、性能劣化、单节点异常尚未形成实质业务影响。定完级再选恢复策略。恢复策略基本就是三种思路的排列组合冗余切换靠HA、主备、多副本机制把流量切到健康节点。恢复最快但要依赖架构的冗余度。实例重建资源彻底损坏时用镜像、备份、配置模板重新拉起。时间中等核心是保证配置和数据的可获取性。降级/隔离故障无法快速消除时先把故障点隔离掉牺牲非核心功能保住核心链路。比如MySQL只读、缓存空窗、熔断下游依赖。所有预案都要围绕一组明确的目标参数来写没有目标的预案就是废纸。建议给每个场景明确两个数字RTO最多能恢复多久和RPO最多能丢多少数据。比如核心数据库的RPO0不能丢数RTO30分钟半小时内恢复服务。有了锚点后面所有步骤的优先级就能自动排出来。另外还有一个很容易忽略的要素——入口。预案第一步永远写清楚“故障从哪里被感知”是ManageOne告警是租户电话投诉还是监控平台邮件报警感知入口不同后续的初始动作路径也不一样。我见过有人在告警还没确认时就跑去重启服务结果把自动恢复中的实例又拽了下来多花两小时复盘。提示定级表和策略表不要塞进长文档里做成贴在电脑上的速查卡故障时人脑是记不住复杂表格的。2. IaaS层故障场景与恢复实操2.1 计算节点宕机的快速疏散与HA切换物理机宕机是IaaS层最常见的P1级故障。表现是ManageOne上出现主机故障告警租户侧某个或某几个ECS状态异常甚至直接失联。遇到这种场景第一步不是急着操作而是先判断虚拟机的真实状态——确认底层物理机是否真的彻底失联还是仅仅管理面断连。我遇到过物理机只是带外网络抖动但控制面误判为宕机结果手动触发HA迁移把正常运行的业务打了个措手不及。正确的排查链路是先看CPS或ManageOne上的主机状态确认物理机是否心跳丢失再通过带外管理比如iBMC/SMM确认电源和系统状态然后登录CPS使用cps host list看控制面视角最后确认存储网络是否正常存储是共享的如果存储链路也断了即使主机活着也无法完成迁移。确认物理机确实宕机后如果该主机上的虚拟机配置了HA策略系统会自动在其他健康节点拉起实例。这里有个关键点HA拉起的虚拟机不保证内存状态相当于一次强制重启。对无状态业务还好对有状态业务比如数据库就容易出现数据文件不一致后续要配合PaaS层做恢复校验。手动疏散的命令是走CPS命令行# 查看计算节点列表 cps template-instance list --service nova # 查询节点上的虚拟机 nova --os-compute-api-version 2.11 hypervisor-servers hypervisor_hostname # 疏散节点上的所有虚拟机 nova host-evacuate hypervisor_hostname疏散时要控制并发数不要一次性打满目标宿主机否则新的宿主机会因为资源争抢出现新的故障。我习惯100台虚拟机分批疏散每批间隔几十秒同时盯住目标宿主机的CPU内存水位。恢复之后还有一个容易漏的环节故障物理机重新上线后记得回到CPS里检查该主机的服务状态、存储多路径是否恢复、虚拟化软件服务是否都拉起再让租户侧做业务验证。别以为机器通了就完事我踩过物理机回来后网卡bond模式异常导致虚机网络丢包的坑。2.2 存储容量爆满不能只盯着“删数据”这一个动作存储容量爆满几乎是每个云运维都会遇到的头疼问题。华为云Stack上常见的表现有存储池或数据盘空间使用率超过阈值有时到达90%或95%后触发告警分布式存储拒绝新卷创建。问题更进一步时会触发“只读”保护数据库中落盘失败、应用写入超时。很多人第一反应是“删日志清数据”。但直接删要冒风险找到真正吃掉空间的元凶才是正经事。排查时要分两条线并行。一条看业务侧登录告警对应的租户资源用df -h查分区挂载点使用率用du -sh定位大目录。另一条看存储侧在CPS/存储管理面检查存储池容量报表确认是某个租户卷异常膨胀还是存储硬件容量整体规划不足。以最常见的MySQL实例不管RDS还是自建磁盘打满为例典型的排查顺序如下# 查看磁盘分区使用率 df -h # 查看数据库数据目录大小 du -sh /var/lib/mysql # 查看binlog实际占用空间 find /var/lib/mysql -name binlog.* -exec ls -lh {} \; # 查看慢日志/错误日志大小 ls -lh /var/log/mysql/如果确认是binlog膨胀可以安全清理但要注意主从复制进度不能在从库还没拉完时就删# 检查从库复制状态确认没有落后 SHOW SLAVE STATUS\G # 确认安全后清理超过3天的旧binlog PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;清理只是救急更重要的是扩容。华为云Stack的块存储支持在线扩容直接在控制台对数据盘做LVM级别的扩容云平台会把新容量下发到裸分区。注意扩容文件系统前先确认文件系统类型不同文件系统的在线扩容参数不同。这里说一个实战教训存储池容量超过80%就建议开始规划扩容不要等到告警阈值再动手。分布式存储一旦接近写满性能会断崖式下跌而且数据重建速度会变得极慢——节点故障后的数据均衡可能拖好久都完不成等于把一个小故障拖成大故障。2.3 网络分区与租户侧通信异常的排查链路网络故障在IaaS层是最难处理的原因在于网络数据面是分布式的故障点可能藏在物理交换机、虚机安全组、分布式路由、甚至云平台的流表里。典型场景某租户报告两台ECS之间ping不通或者对外访问偶发中断。我的排查顺序固定是从底层向上反过来容易在业务层绕圈。第一步先确认租户侧的虚拟机状态和所在物理节点排除宿主机负载过高导致的网络丢包。第二步检查网络节点Neutron L3 Agent状态看分布式路由和DHCP服务是否正常。第三步检查安全组规则——相当一部分“网络不通”其实是安全组默认拒绝、或者改规则时手误放错了方向。最后再深入到物理交换机的互联链路和流表状态这步通常需要网络团队介入。# 查看网络节点Agent状态 neutron agent-list # 查看租户网络 neutron net-list # 查看分布式路由器 neutron router-list # 查看某个端口的详细信息确认IP和MAC绑定 neutron port-show port_id如果确认是网络节点宕机导致的路由中断处理手段通常是重启网络服务或把网络节点在不同物理机间切换# 在CPS中查看网络节点分布 cps template-instance-list --service neutron # 重启某个网络服务(在对应节点执行) systemctl restart neutron-server但这里有个重要的坑不要同时重启所有网络服务的实例。Neutron Server是有状态的服务全部同时重启会导致DHCP/路由状态短暂丢失租户侧连接会出现大面积中断。逐个重启确认一个恢复再动下一个。实在需要整体切换的先和业务侧沟通好维护窗口。网络接口类的故障排查时留意华为云Stack的二层VXLAN隧道模式。我曾经遇到过一个案例物理交换机上一个端口组配置错误导致VXLAN流量在跨机架时出现丢包表现在租户侧就是间歇性网络超时。这种问题靠控制台基本看不出来只能靠底层多路径排查所以平时做好物理交换机配置的基线备份非常重要关键时候能靠diff对比快速定位。3. PaaS层故障场景与恢复实操3.1 MySQL磁盘爆满导致实例只读的完整处置现在把视角转到PaaS层。结合网上常说的“MySQL三大故障场景”我先从磁盘爆满说起——这是最典型、也最容易被运维在最后一刻才发现的故障之一。华为云Stack上不管是RDS托管实例还是租户ECS里自建的MySQL磁盘满之后的表现基本都是应用侧写入报错错误信息类似ERROR 1021 (HY000): The table is full或者是read-only提示数据库状态看df -h显示某分区 100%。这里最关键的动作是先确认实例是否处于只读状态只读时要先解除只读才能恢复写入。华为云RDS通常会在磁盘达到90%时自动切换为只读保护防止数据写一半损坏文件。处置思路分四个环节第一步临时止血。先确认磁盘空间究竟被什么占据通常三大来源binlog、慢日志/错误日志、undo/tmp文件。第二步清理。binlog 按前面讲的方式清理到保留窗口内大日志文件可以直接 truncate线上建议先备份归档再清免得事后要排查问题却没日志。第三步扩容。数据盘直接扩容量扩完记得看实例的磁盘大小同步更新。第四步解除只读并验证。在华为云控制台或数据库参数组中将实例的read_only改回OFF再确认应用写入恢复。注意MySQL还可能出现因为磁盘满导致无法启动的“冷死”状态。此时不要只扩文件系统需要检查数据目录和日志文件是否有损坏必要时先用备份做数据文件校验再拉起实例。直接重启满盘状态的MySQL大概率会触发崩溃恢复InnoDB redo日志回放这个过程在磁盘空间不足时会异常缓慢。3.2 主从复制中断与延迟的排查与恢复MySQL 三大故障场景里主从复制中断或延迟排第二。表现在业务上是读多写少的架构里从库数据滞后导致页面显示和最新数据不一致严重时会主从切换失败、数据丢失风险。排查时先看复制状态SHOW SLAVE STATUS\G重点看Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running三个字段。如果Slave_IO_Running是 No说明从库和主库的网络连接或认证有问题如果Slave_SQL_Running是 No则可能是回放SQL时报了错常见是主键冲突、表不存在、或者数据不一致。恢复手段如下-- 临时跳过错误仅限可接受丢失的场景 STOP SLAVE SQL_THREAD; SET GLOBAL sql_slave_skip_counter 1; START SLAVE SQL_THREAD; -- 或者更稳妥重新同步异常的表 -- 1. 主库导出表数据 mysqldump -u root -p --single-transaction --master-data2 dbname table_name table_backup.sql -- 2. 从库导入 mysql -u root -p dbname table_backup.sql -- 3. 从库重新开启复制 START SLAVE;这里要特别提醒sql_slave_skip_counter是应急手段不是说跳就跳。跳过错误的前提是你已经明确知道了出错原因并且确认跳过的数据不会对业务产生不可接受的损失。乱跳多次会导致主从数据长期分叉后续再想修复就要花数倍时间。如果复制延迟持续增高且从库CPU/IO正常大概率是主库上出现了大事务或批量DDL。这时候与其在从库上折腾不如回主库看有没有长事务先kill掉再等复制追平。从库追平期间可以临时把部分读流量切走降低从库负载。华为云Stack的RDS实例一般都有自动HA机制主从状态由平台管理遇到复制中断时先在控制台“实例详情”看主备关系和状态如果显示“主备正常”但业务侧仍读到旧数据可能是延迟而非故障检查参数组中slave_parallel_workers等参数是否合理或者确认是否有大事务拖慢回放。3.3 容器平台节点异常与中间件故障的应急处理容器平台故障是另一套逻辑。华为云Stack上的容器服务如CCE集群故障场景通常是节点失联、镜像拉取失败、Pod驱逐、中间件Redis、Kafka、RabbitMQ异常。先讲节点异常。当集群里有节点NotReady首选确认是物理机问题还是kubelet假死。在集群节点上执行# 查看节点状态 kubectl get nodes # 查看节点详细信息找到 NotReady 的原因 kubectl describe node node_name # 查看 kubelet 状态 systemctl status kubelet # 查看容器运行时状态常见docker/containerd systemctl status containerdkubelet假死是常见坑。有时候kubelet的 goroutine 卡死光systemctl restart kubelet没用需要先 kill 掉进程再重启否则拉起后还是老状态。如果 containerd 假死在重启前先确认没有正在进行的容器迁移否则容易造成Pod二次损坏。Pod 被驱逐或频繁重启时先kubectl describe pod看事件注意OOMKilled和BackOff两类。OOMKilled通常就是内存限额太小或者节点内存压力大前者调整limit后者先把干扰性的Pod先调度走。BackOff一般是镜像拉取失败或健康检查失败看前一两条事件基本能定位。中间件里Redis故障最典型的是缓存雪崩——大量缓存同时失效请求直接打到数据库数据库瞬间连接数打满。处理方式没有太高深的先加锁或限流避免数据库被打死然后让缓存重建缓慢进行别用满并发去回填。同时在Redis侧确认是否开启了持久化、慢查询和内存淘汰策略是否合理Redis的maxmemory打满后如果策略配置错误会直接拒绝写入影响比雪崩还剧烈。Kafka消息积压也常见。如果消费者组消费滞后先看消费者日志有没有频繁rebalance如果有可能是消费者线程异常或Broker端分区故障。命令上先用kafka-consumer-groups.sh --describe查看lag再用kafka-topics.sh --describe查看分区副本状态。如果Broker节点宕机确实会有部分分区处于UnderReplicated状态等副本重新同步完再恢复消费不要在副本没同步时强行切主否则会丢消息。4. 故障恢复的工具链与日常准备4.1 华为云Stack运维常用的工具与命令手册预案写得再细工具链跟不上也是白搭。我平时把华为云Stack运维工具分成三类告警发现、日志取证、控制面操作。告警发现首选 ManageOne。所有平台的告警都会汇总到这里包括计算、存储、网络、数据库、容器。关键在于别只看“告警列表”要养成看“告警详情-根源对象-关联资源”的习惯很多故障的真正触发点是隐藏在关联资源里的。比如ECS宿主机报警关联的存储卷可能有异常一步跳转就能看到根因。日志取证是故障处理的核心。华为云Stack各服务日志分布在CPS节点和各组件节点上一般路径在/var/log/cps、/var/log/nova、/var/log/neutron、/var/log/mysql等。管理面提供了“日志中心”可以按维度下载但很多关键时刻还是得直接在节点上抓# 查看CPS整体健康状态 cps health-check # 抓取nova相关日志 tail -100 /var/log/nova/nova-compute.log # 抓取mysql错误日志 tail -100 /var/log/mysql/mysqld.log控制面操作常用cps命令来做服务编排和状态检查配合各OpenStack组件的命令行工具# 查看所有服务状态 cps service list # 查看某个服务的实例分布 cps template-instance list --service openstack-nova # 查看CPS整体告警 cps alarm list这里要强调一个习惯任何时候做变更前先对关键配置做备份或者至少把变更命令和当前状态截图存档。华为云Stack很多组件都有自带的操作审计但审计日志的粒度不一定能满足排查需要自己留一手永远没有坏处。4.2 故障演练把“预案”变成“肌肉记忆”文档沉淀再多如果不演练真出故障时照样手忙脚乱。我特别建议至少每季度做一次故障演练时间不用长1-2小时就行。选几个高频场景比如“存储池容量告警”“MySQL磁盘满变只读”“某计算节点宕机”按规定流程走一遍重点不是最终恢复成功而是看过程中的判断是否准确、沟通是否顺畅、步骤是否有遗漏。演练时可以故意设置若干干扰项比如在主机宕机模拟时把另一台健康节点也标记为维护状态检验应变能力。这一套其实就是混沌工程的思想在运维排练中的应用。演练结束后一定做复盘把发现的问题回填到应急预案里逐渐收敛步骤。另外应急预案的“版本管理”非常重要。华为云Stack升级、扩容、变更架构后预案里的命令、路径、角色名都可能失效。我吃过一次亏一次平台升级后cps命令的参数选项发生了变化文档没同步更新故障时照着旧命令敲了半天报错才发现。从那之后我把“预案版本”和“平台版本”绑定起来升级必定触发预案审查。5. 常见问题与排查技巧实录5.1 故障现场的五个常见误判这几年处理故障我总结出运维人员最常犯的几个误判每一个都用时间代价换来的。第一个误判是跳过现象直接上命令。看到服务异常就先重启完全不看告警详情和日志。故障现场的“第一现场”证据比如日志中的堆栈、状态码输出、时间点前后的监控曲线是最宝贵的重启会把现场破坏掉。正确的做法是先收集信息再做动作哪怕多花十分钟观察也比重启后一无所获强。第二个误判是混淆控制面和数据面故障。有时候控制台登录不了、API超时很多人立刻认为是核心业务故障兴师动众去切换集群结果只是控制面某个服务模块重启了而已。判断控制面还是数据面故障可以看租户侧业务是否真的受影响——如果租户虚拟机还在正常对外服务优先怀疑控制面。第三个误判是忽视半连接状态。主机和网络设备的状态不是只有“通”和“不通”两种还有“半通”——比如管理面通但业务面不通、磁盘写不进去但不报错、网络单通。这种半连接状态最坑人因为它不会触发明显的告警只会表现为间歇性异常。第四个误判是迷信自动恢复。HA、自动迁移这些机制确实能省很多事但自动化机制有时会掩盖问题。比如一台虚拟机被HA拉起后没有根本解决存储链路的问题后续还是会反复抖动。自动恢复之后一定要继续做根因分析直到确认故障源被移除。第五个误判是灾难时做太复杂的操作。真遇到紧急故障时间窗口极短能做60分的简单操作就不要做85分的复杂操作。比如不确定是内存泄漏还是缓存问题先重启实例恢复业务再在低峰期慢慢分析内存不要在高峰期对着进程调参数把故障时间拉长。5.2 应急预案文档的持续维护机制预案不是一次性工作而是需要持续更新维护的“活文档”。我们团队的做法有几条一是故障即更新。每次线上故障处理结束后处理人必须在三天内把复盘结论转成预案修订建议至少要更新故障描述、排查链路、恢复步骤三个部分。领导可以不写工程师必须写。二是月度巡检对照。巡检时除了看资源水位还要把预案里的关键命令跑一遍确保命令和脚本在现有版本下还能正常执行。很多命令会因为平台小版本更新而废弃或加参数每月的“假动作”能提前暴露。三是责任人轮换。应急预案的维护不能只一个人负责否则这个人休假就没人懂得怎么改。我建议每个场景配两位责任人一主一备并且每半年轮换一次场景。这样既保证了覆盖也让团队里不同的人都能接触不同场景。四是外部依赖清单。华为云Stack故障处理经常要联系厂商支持预案里应该附带联系人列表、工单入口、以及“什么情况下需要升级给厂商介入”的触发条件。别等故障发生再到处找人。写在最后预案的终点是“不用预案”回头看我这几年的体会最大的转变是应急预案做得越细反而越希望它永远用不上。因为预案本质上是把“不确定性”变成“确定性”的工具如果平台架构健康、容量规划合理、日常巡检到位很多故障在变成事故之前就已经被拦截了。我自己现在花在预案上的时间大头不是在写步骤而是在研究怎么通过监控、告警和自动化手段把故障扼杀在萌芽状态。如果你正在搭建或优化华为云Stack的应急预案我的建议是先别急着写几十页的长文档从你最常遇到的三个故障场景开始写清楚现象、判断、操作、回滚跑通一次演练再逐步扩展开来。要记住云平台的故障处理没有“银弹”只有对架构的深刻理解和对故障的持续敬畏才能让每一次危机都变成可掌控的流程。