云服务器故障如何复盘

云服务器故障复盘是一项系统性工作，核心目标是还原真相、定位根源、落实改进，避免同类问题再次发生。以下是一套标准化的复盘流程与关键要点，适用于云服务器（含ECS、虚拟机、容器实例等）的故障场景：
### 一、复盘前准备：快速响应与信息收集
故障发生后，需先完成应急响应（止损、恢复业务），再启动复盘。复盘前需收集以下关键信息：
#### 1. 故障基本信息
- 时间线：故障发生时间、发现时间、恢复时间、总耗时（MTTR：平均恢复时间）。
- 影响范围：受影响的服务器实例（ID、地域、可用区）、业务系统（如电商交易、API服务）、用户群体（C端/B端、地域分布）、业务损失（如订单量下降、用户投诉数）。
- 故障现象：服务器状态（宕机、卡顿、网络不通）、错误日志（系统日志、应用日志、云服务监控告警）、用户反馈（如“无法访问页面”“接口超时”）。
#### 2. 技术数据收集
- 云厂商监控数据：CPU/内存/磁盘/网络使用率、云服务器实例状态（运行中/停止/重启）、存储卷状态（是否挂载、IO异常）、网络连通性（VPC、安全组、负载均衡配置）。
- 应用层数据：应用日志（如Java的GC日志、Nginx访问日志）、依赖服务状态（数据库、缓存、消息队列是否正常）、变更记录（故障前是否有代码发布、配置修改、资源扩容）。
- 操作记录：云平台操作日志（谁在何时做了什么操作，如重启实例、修改安全组）、运维操作记录（如手动部署、脚本执行）。
#### 3. 相关人员同步
- 召集参与应急响应的人员：云运维工程师、应用开发、业务负责人、云厂商技术支持（若涉及云平台问题）。
- 提前同步故障背景，确保大家对基本信息有一致认知。
### 二、复盘核心步骤：5Why分析法+故障树
复盘会议需围绕“发生了什么？为什么发生？如何改进？”展开，推荐用5Why分析法（连续追问“为什么”）或故障树分析（FTA） 定位根因。
#### 步骤1：还原故障时间线（客观事实，不追责）
用时间轴清晰呈现关键节点，避免主观猜测：
<br>| 时间 | 事件描述 | 操作人/系统 |<br>|------------|--------------------------------------------------------------------------|-------------------|<br>| 14:00:00 | 业务监控告警：API接口成功率从99.9%降至20% | 监控系统 |<br>| 14:02:00 | 运维人员登录云平台，发现3台ECS实例（华东1区）CPU使用率100% | 运维A |<br>| 14:05:00 | 检查应用日志，发现某定时任务死循环导致CPU占满 | 开发B |<br>| 14:10:00 | 临时终止定时任务进程，CPU恢复正常，接口成功率回升至99% | 运维A |<br>| 14:30:00 | 重启异常实例，确认业务完全恢复 | 运维A |<br>
注意：时间线需基于客观数据（监控、日志），避免“可能是”“应该是”等模糊表述。
#### 步骤2：定位根因（5Why分析法示例）
以“ECS实例CPU占满导致业务不可用”为例：
- Why 1：为什么CPU占满？→ 某定时任务进程占用100% CPU。
- Why 2：为什么定时任务会死循环？→ 任务逻辑中未处理“数据为空”的边界情况，导致无限循环。
- Why 3：为什么未处理边界情况？→ 开发时未考虑该场景，测试用例未覆盖。
- Why 4：为什么测试未覆盖？→ 测试环境数据量小，未模拟“数据为空”的场景。
- Why 5：为什么未模拟？→ 需求评审时未明确边界条件，测试方案缺失。
根因结论：定时任务逻辑缺陷（未处理空数据边界）+ 测试覆盖不足（未模拟极端场景）。
#### 步骤3：区分“直接原因”与“根本原因”
- 直接原因：触发故障的 immediate 事件（如“CPU占满”“磁盘满了”）。
- 根本原因：导致直接原因的深层问题（如“代码逻辑缺陷”“监控缺失”“流程漏洞”）。
避免停留在直接原因（如“因为CPU满了”），需深挖到可改进的根本点。
#### 步骤4：评估故障影响
- 业务影响：量化损失（如“故障30分钟，导致订单量减少500单，损失约10万元”）。
- 用户影响：用户投诉量、舆情反馈（如社交媒体是否有负面评论）。
- 信任影响：客户对服务的信任度下降（如B端客户询问SLA补偿）。
### 三、输出复盘文档：结构化记录
复盘需形成正式文档，便于后续跟踪与知识沉淀。文档模板参考：
<br># 云服务器故障复盘报告<br>## 1. 故障概述<br>- 故障名称：华东1区ECS实例CPU占满导致API不可用<br>- 发生时间：2024-05-20 14:00 ~ 14:30（MTTR=30分钟）<br>- 影响范围：3台ECS实例（华东1区）、电商API服务、C端用户约10万<br>- 业务损失：订单量减少500单，损失约10万元<br>## 2. 故障时间线<br>（见上文时间轴表格）<br>## 3. 根因分析<br>- 直接原因：定时任务死循环导致CPU占满<br>- 根本原因：<br>1. 代码层面：定时任务未处理“数据为空”边界条件，触发无限循环；<br>2. 测试层面：测试用例未覆盖空数据场景，测试环境数据量不足；<br>3. 监控层面：未对“CPU使用率超80%”设置提前告警，导致故障发现延迟2分钟。<br>## 4. 改进措施（核心！）<br>需明确**责任人、完成时间、验收标准**，分“短期止损”和“长期预防”：<br>| 改进项 | 类型 | 责任人 | 完成时间 | 验收标准 |<br>|----------------------------|------------|--------|------------|------------------------------|<br>| 修复定时任务逻辑，增加空数据判断 | 短期止损 | 开发B | 2024-05-21 | 代码合并至生产，测试通过 |<br>| 补充测试用例，覆盖空数据场景 | 长期预防 | 测试C | 2024-05-25 | 测试用例库更新，回归测试通过 |<br>| 调整CPU监控告警阈值（80%触发） | 长期预防 | 运维A | 2024-05-22 | 告警规则生效，测试告警触发 |<br>| 增加定时任务执行日志与异常捕获 | 长期预防 | 开发B | 2024-05-30 | 日志可追踪，异常自动告警 |<br>## 5. 经验总结与知识沉淀<br>- 教训：定时任务需严格处理边界条件，避免无限循环；<br>- 最佳实践：核心任务需增加“执行超时”“异常中断”机制；<br>- 知识库更新：将本次故障案例录入内部知识库，供团队学习。<br>
### 四、关键注意事项
#### 1. 避免“追责文化”，聚焦“改进”
复盘的核心是解决问题，而非指责个人。例如：不说“运维A没及时发现告警”，而说“监控告警阈值设置不合理，导致发现延迟”。
#### 2. 覆盖“云平台侧”故障场景
若故障由云厂商导致（如可用区断电、网络故障、存储异常），需：
- 收集云厂商的故障公告与RCA（根因分析）报告；
- 评估是否需调整架构（如多可用区部署、跨云容灾）；
- 与云厂商确认SLA补偿（如服务抵扣券）。
#### 3. 验证改进措施的有效性
改进措施完成后，需回归验证：
- 例如：修复代码后，模拟空数据场景测试是否还会死循环；
- 调整监控后，人为触发CPU超80%验证告警是否及时。
#### 4. 定期回顾复盘案例
将复盘报告纳入团队知识库，定期（如每月）回顾历史故障，避免“重复踩坑”。
### 五、常见云服务器故障场景与根因参考
| 故障场景 | 常见根因 | 改进方向 |
|------------------------|-------------------------------------------|-----------------------------------|
| 实例宕机 | 硬件故障、内核崩溃、资源超卖（云厂商侧） | 多可用区部署、内核版本升级、监控硬件状态 |
| 网络不通 | 安全组配置错误、VPC路由表异常、DDoS攻击 | 安全组定期审计、DDoS防护、网络监控 |
| 磁盘IO过高 | 磁盘满、数据库慢查询、日志未轮转 | 磁盘容量监控、慢查询优化、日志轮转策略 |
| 实例重启后业务无法启动 | 启动脚本依赖缺失、配置文件丢失、端口冲突 | 启动脚本测试、配置文件备份、端口预检查 |
通过以上流程，云服务器故障复盘可从“被动救火”转向“主动预防”，逐步提升系统的稳定性与可靠性。