290 lines
7.3 KiB
Markdown
290 lines
7.3 KiB
Markdown
# 服务不可用告警处理方案
|
||
|
||
## 告警名称
|
||
- **告警名**: `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)
|