先确认真实现象
不要一看到告警就猜原因。
运维人员
“审计平台没有新日志了。”
小白
“从什么时候开始？”
运维人员
“10:20以后。”
师傅
“客服系统有没有同时出现异常？”
小白
“查询变慢，但业务还没有完全中断。”
【 第 11 步 】
故障处置室
师傅：“系统已经稳定运行一段时间，今天运维大屏突然显示数据库审计日志停止采集，同时客服反映查询速度明显变慢。遇到故障时最重要的不是马上重启，而是按照七步故障分析法处理：先确认现象，再界定影响范围，随后保留证据，检查近期变更、网络、资源、依赖和产品日志来分析原因；
确定方案后在授权范围内实施回退、恢复或调整，再做恢复验证，最后填写故障单并完成故障复盘。如果一开始就删除日志或重新安装，虽然可能暂时恢复服务，却可能把真正的原因和重要证据一起覆盖掉。”
01 · 现场对话
故障处置室的知识任务
先保留现场
处理前留下证据。
小白
“要不要先重启审计服务？”
师傅
“先保存日志、错误信息、配置和监控曲线。”
小白
“还要记录最近有没有变更。”
师傅
“对。先保留现场，再做批准的操作。”
从外到内排查
逐步缩小问题范围。
小白
“网络正常，磁盘也没有满。”
师傅
“继续看产品服务和数据库连接。”
运维人员
“上午刚修改过一条采集配置。”
小白
“那这个变更值得重点检查。”
师傅
“对，但仍然要用证据确认。”
恢复后再验证
服务恢复还不能立即结束。
运维人员
“回退配置以后，日志重新进来了。”
师傅
“检查业务查询。”
小白
“速度恢复正常，日志时间也连续。”
师傅
“最后形成故障单，写清根因、影响、处置和改进措施。”
02 · 小白做现场笔记
重要概念及注释
故障分析
- 正式含义
- 系统或安全产品出现异常时，通过有序收集现象和证据，判断影响范围、分析原因并恢复运行的过程。
- 七步故障分析法
- 确认现象 ↓ 界定范围 ↓ 保留证据 ↓ 分析原因 ↓ 授权处置 ↓ 验证恢复 ↓ 记录复盘这是教材明确采用的基础故障处理路线。
先弄清发生了什么，再动手处理。
确认现象
- 正式含义
- 记录故障发生的时间、用户反馈、系统表现和告警信息。
- 现场记录
- 什么时候开始 谁发现 出现什么错误 哪些功能异常 有没有告警
先描述事实，不要一上来就猜原因。
影响范围
- 正式含义
- 确定故障影响的是一个账号、一项服务、一台设备、一个区域还是整个业务系统。
- 面包厂场景
- 只有审计日志停止？ 还是 会员系统也变慢？ 只有一台服务器？ 还是 所有门店都受到影响？
先判断问题有多大，再决定处理力度。
证据保留
- 正式含义
- 故障处理前保存可能帮助定位问题的日志、配置、错误信息和监控数据。
- 保存内容
- 日志 配置快照 错误信息 监控曲线 版本 近期变更记录直接重启、删除日志或重新安装可能覆盖真正原因。
重大操作以前，先把现场留下来。
排查顺序
- 基础路线
- 用户现象 ↓ 网络与 DNS ↓ 端口与服务 ↓ 应用和产品日志 ↓ 依赖服务、数据库和存储 ↓ 近期配置与资源变化 ↓ 根因教材建议按照“从外到内”逐步缩小范围。
按顺序一层一层缩小范围，比到处乱改配置更容易找到原因。
根因分析
- 正式含义
- 继续追查造成故障的深层原因，而不是只处理最表面的症状。
- 示例
- 日志停止采集 ↓ 磁盘已满 ↓ 保留策略没有生效 ↓ 配置变更后没有验证 ↓ 变更检查表缺少存储检查项
- 易混辨析
- 临时措施：
清理磁盘，让日志重新运行。
永久措施：
修正规则、基线和变更流程，避免再次发生。
恢复服务解决眼前问题，根因分析解决为什么会再次发生。
恢复验证
- 正式含义
- 处置完成后重新检查业务、安全功能、日志和告警，确认系统真正恢复正常。
- 验证对象
- 业务功能 安全策略 日志采集 告警 数据完整性 性能
服务启动了，不等于故障已经处理完成。
故障单与复盘
- 正式含义
- 用统一记录保存故障全过程，并在故障结束后分析原因和改进措施。
- 故障单内容
- 故障编号与时间 故障现象 影响范围 证据 根因 临时措施 永久措施 恢复验证 责任人与期限教材要求故障单同时记录直接原因、深层原因和改进措施。
故障处理一次，最好留下办法让同样的问题少发生一次。
03 · 经验和难点
小结
这一站，小白按照确认现象、界定范围、保留证据、分析原因、实施处置、验证恢复和记录复盘的顺序完成了一次基础故障处理。最值得记住的经验是：重大操作前先保留证据，恢复以后还要验证业务和安全功能。初学者最容易遇到的难点，是为了尽快恢复服务直接重启、清日志或重装系统，从而破坏故障分析需要的现场信息。