commit
This commit is contained in:
zhuyongxin
@@ -0,0 +1,289 @@
|
||||
# 服务不可用告警处理方案
|
||||
|
||||
## 告警名称
|
||||
- **告警名**: `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小时未恢复**: 启动最高级别应急响应
|
||||
|
||||
## 参考文档
|
||||
- [应急响应流程](internal-docs/emergency-response.md)
|
||||
- [故障处理手册](internal-docs/incident-handbook.md)
|
||||
- [高可用架构设计](internal-docs/ha-architecture.md)
|
||||
Reference in New Issue
Block a user