# 服务不可用告警处理方案

## 告警名称
- **告警名**: `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)