SuperBizAgent-java/aiops-docs/service_unavailable.md

服务不可用告警处理方案

告警名称

• 告警名: ServiceUnavailable
• 告警级别: 紧急
• 触发条件: 服务健康检查失败或错误率超过50%

问题描述

服务不可用是最严重的故障，会导致：

• 用户无法访问服务
• 业务完全中断
• 可能造成经济损失
• 影响公司声誉

排查步骤

步骤1: 获取当前时间

工具: get_current_time 目的: 记录故障发生时间，用于后续分析

步骤2: 查询服务状态日志

工具: query_logs 参数要求:

• 地域: ap-guangzhou
• 日志主题: application-logs
• 时间范围: 最近15分钟
• 查询条件: level:ERROR OR level:FATAL OR status:500

查询示例:

地域: ap-guangzhou
日志主题: application-logs
时间范围: [当前时间-15分钟] 到 [当前时间]
查询语句: (level:ERROR OR level:FATAL) AND service_name:*

步骤3: 查询系统事件日志

工具: query_logs 参数要求:

• 地域: ap-guangzhou
• 日志主题: system-events
• 查询条件: event:restart OR event:crash OR event:oom_kill

步骤4: 检查依赖服务状态

工具: query_logs 参数要求:

• 地域: ap-guangzhou
• 日志主题: application-logs
• 查询条件: downstream_service OR database OR redis OR mq

常见原因分析

原因1: 应用崩溃或无法启动

特征:

• 所有实例都无法响应
• 日志中有启动失败记录
• 可能有OOM或其他致命错误
• 健康检查全部失败

处理方案:

1. 立即回滚:

   • 如果是新版本发布后出现，立即回滚到上一个稳定版本
   • 使用蓝绿部署或金丝雀发布策略

2. 紧急修复:

   • 查看启动日志定位问题
   • 检查配置文件是否正确
   • 验证依赖服务是否可用
   • 修复后重新部署

3. 临时方案:

   • 启用备用服务
   • 显示维护页面
   • 通知用户服务异常

原因2: 数据库连接失败

特征:

• 日志中有数据库连接错误
• "Connection refused" 或 "Too many connections"
• 数据库服务异常
• 连接池耗尽

处理方案:

1. 检查数据库状态:

   • 确认数据库服务是否运行
   • 检查数据库连接数
   • 查看数据库错误日志

2. 恢复数据库连接:

   • 重启数据库（如果必要）
   • 增加最大连接数
   • 释放僵死连接
   • 检查网络连通性

3. 应用层处理:

   • 重启应用重建连接池
   • 调整连接池配置
   • 实现连接重试机制

原因3: 依赖服务故障

特征:

• 日志中有调用第三方服务失败
• Redis、MQ等中间件不可用
• 网络连接超时
• 级联故障

处理方案:

1. 快速降级:

   • 启用熔断机制
   • 跳过非关键依赖
   • 使用缓存数据
   • 返回降级响应

2. 恢复依赖服务:

   • 检查Redis、MQ等服务状态
   • 重启故障的依赖服务
   • 修复网络连接问题

3. 隔离故障:

   • 防止故障扩散
   • 限制重试次数
   • 实现超时控制

原因4: 配置错误

特征:

• 最近有配置变更
• 日志中有配置加载错误
• 特定环境变量缺失
• 启动参数错误

处理方案:

1. 回滚配置:

   • 恢复到上一个正确的配置
   • 检查配置文件语法
   • 验证环境变量

2. 修复配置:

   • 对比正确的配置文件
   • 修正错误的配置项
   • 重新加载配置

3. 配置管理:

   • 使用配置中心统一管理
   • 配置变更需要审批
   • 保留配置历史版本

原因5: 资源耗尽

特征:

• 磁盘空间满
• 文件描述符耗尽
• 端口被占用
• 内存不足导致OOM

处理方案:

1. 清理资源:

   • 清理磁盘空间（日志、临时文件）
   • 释放文件描述符
   • 杀死占用端口的进程

2. 扩容资源:

   • 增加磁盘空间
   • 调整系统限制（ulimit）
   • 增加内存配置

3. 优化使用:

   • 实现日志轮转
   • 及时关闭文件句柄
   • 优化内存使用

原因6: 网络故障

特征:

• 无法访问服务
• 网络连接超时
• 负载均衡器异常
• DNS解析失败

处理方案:

1. 检查网络:

   • 测试网络连通性（ping, telnet）
   • 检查防火墙规则
   • 验证安全组配置
   • 检查DNS解析

2. 修复网络:

   • 重启网络服务
   • 修正路由配置
   • 更新负载均衡器配置
   • 切换到备用网络

3. 流量切换:

   • 切换到备用地域
   • 使用备用域名
   • 启用CDN

紧急处理流程

第一时间（1分钟内）

1. 确认故障: 通过监控和日志确认服务确实不可用
2. 启动应急: 通知相关人员，启动应急响应流程
3. 止损措施:
   • 如果是部分实例故障，摘除故障实例
   • 如果是全部故障，启用备用服务或维护页面

5分钟内

1. 快速定位: 查看日志和监控，快速定位问题原因
2. 决策处理:
   • 如果能快速修复，立即修复
   • 如果无法快速修复，执行回滚
   • 如果是依赖故障，启用降级

15分钟内

1. 恢复服务: 通过回滚、修复或降级恢复服务
2. 验证功能: 确认核心功能可用
3. 监控观察: 持续监控服务状态

30分钟内

1. 全面验证: 验证所有功能正常
2. 通知用户: 如果影响用户，发布公告
3. 初步总结: 记录故障原因和处理过程

验证步骤

1. 健康检查: 确认所有实例健康检查通过
2. 功能测试: 测试核心业务功能
3. 性能验证: 确认响应时间和吞吐量正常
4. 错误率: 确认错误率降到正常水平（<1%）
5. 持续监控: 观察30分钟确保稳定

预防措施

1. 高可用架构:

   • 多实例部署
   • 多地域容灾
   • 数据库主从复制
   • 关键服务冗余

2. 监控告警:

   • 完善的健康检查
   • 实时监控告警
   • 自动故障转移
   • 异常自动恢复

3. 发布策略:

   • 灰度发布
   • 蓝绿部署
   • 金丝雀发布
   • 快速回滚机制

4. 容错设计:

   • 熔断降级
   • 限流保护
   • 超时控制
   • 重试机制

5. 演练测试:

   • 定期故障演练
   • 压力测试
   • 混沌工程
   • 应急预案演练

故障复盘

故障恢复后，必须进行复盘：

1. 故障时间线: 记录故障发生、发现、处理、恢复的完整时间线
2. 根因分析: 深入分析故障根本原因
3. 影响评估: 评估故障影响范围和损失
4. 改进措施: 制定防止类似故障的改进措施
5. 文档更新: 更新运维文档和应急预案

相关告警

• HighErrorRate: 错误率过高
• HealthCheckFailed: 健康检查失败
• AllInstancesDown: 所有实例下线
• DatabaseConnectionFailed: 数据库连接失败

紧急联系方式

• 运维值班: 400-xxx-1111（24小时）
• 开发值班: 400-xxx-2222（24小时）
• DBA值班: 400-xxx-3333（24小时）
• 网络团队: 400-xxx-4444
• 安全团队: 400-xxx-5555

升级机制

• 15分钟未恢复: 升级到技术总监
• 30分钟未恢复: 升级到CTO
• 1小时未恢复: 启动最高级别应急响应

参考文档

• 应急响应流程
• 故障处理手册
• 高可用架构设计