# 服务响应时间过长告警处理方案

## 告警名称
- **告警名**: `SlowResponse`
- **告警级别**: 警告
- **触发条件**: P99响应时间持续5分钟超过3秒

## 问题描述
当服务的响应时间持续超过阈值时，会导致：
- 用户体验下降
- 请求堆积
- 可能触发超时错误
- 影响下游服务

## 排查步骤

### 步骤1: 获取当前时间
**工具**: `get_current_time`
**目的**: 确定告警发生的准确时间

### 步骤2: 查询应用性能日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `application-logs`
- **时间范围**: 最近30分钟
- **查询条件**: `response_time:>3000 OR slow_query:true`

**查询示例**:
```
地域: ap-guangzhou
日志主题: application-logs
时间范围: [当前时间-30分钟] 到 [当前时间]
查询语句: response_time > 3000 AND level:WARN
```

### 步骤3: 查询数据库慢查询日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `database-slow-query`
- **时间范围**: 与告警时间一致
- **查询条件**: `query_time:>1000`

### 步骤4: 查询系统资源使用情况
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `system-metrics`
- **查询条件**: `cpu_usage OR memory_usage OR disk_io`

## 常见原因分析

### 原因1: 数据库慢查询
**特征**:
- 慢查询日志中有大量记录
- 数据库CPU使用率高
- 特定SQL执行时间长
- 数据库连接池接近满载

**处理方案**:
1. **立即优化**: 
   - 找出最慢的SQL语句
   - 检查是否缺少索引
   - 查看执行计划（EXPLAIN）
   - 临时添加索引或优化SQL

2. **短期措施**:
   - 增加数据库连接池大小
   - 启用查询缓存
   - 考虑读写分离

3. **长期优化**:
   - 定期分析慢查询日志
   - 优化数据库表结构
   - 建立合适的索引策略
   - 考虑分库分表

### 原因2: 外部API调用超时
**特征**:
- 日志中有第三方API调用记录
- 特定接口响应时间长
- 可能有网络超时错误
- 下游服务响应慢

**处理方案**:
1. **设置合理超时**:
   - 调整HTTP客户端超时时间
   - 避免无限等待
   - 设置连接超时和读取超时

2. **实施降级策略**:
   - 启用熔断机制
   - 返回默认值或缓存数据
   - 异步处理非关键调用

3. **优化调用方式**:
   - 并行调用多个API
   - 使用批量接口减少调用次数
   - 增加本地缓存

### 原因3: 代码性能问题
**特征**:
- CPU使用率高
- 特定代码路径执行慢
- 日志中有性能警告
- 无明显外部依赖问题

**处理方案**:
1. **性能分析**:
   - 使用APM工具定位慢方法
   - 查看火焰图找出热点
   - 分析代码执行路径

2. **代码优化**:
   - 优化循环和递归
   - 减少不必要的对象创建
   - 使用更高效的数据结构
   - 避免重复计算

3. **异步处理**:
   - 非关键逻辑异步执行
   - 使用消息队列解耦
   - 实现异步响应

### 原因4: 缓存失效或缓存穿透
**特征**:
- 缓存命中率突然下降
- 数据库查询量激增
- 特定时间点响应变慢
- 日志中有缓存miss记录

**处理方案**:
1. **缓存预热**:
   - 重启后立即预热热点数据
   - 定时刷新缓存
   - 避免缓存同时失效

2. **防止缓存穿透**:
   - 对空值也进行缓存
   - 使用布隆过滤器
   - 参数校验防止恶意查询

3. **优化缓存策略**:
   - 设置合理的过期时间
   - 使用多级缓存
   - 实现缓存更新机制

### 原因5: 系统资源不足
**特征**:
- CPU或内存使用率高
- 磁盘IO繁忙
- 网络带宽占用高
- 系统负载过高

**处理方案**:
1. **资源扩容**:
   - 增加实例数量（水平扩展）
   - 升级实例规格（垂直扩展）
   - 优化资源分配

2. **负载均衡**:
   - 检查负载均衡配置
   - 确保流量均匀分布
   - 移除异常实例

3. **限流降级**:
   - 启用限流保护
   - 降级非核心功能
   - 优先保证核心业务

### 原因6: 网络问题
**特征**:
- 跨地域调用延迟高
- 网络丢包率增加
- 特定时间段网络拥堵
- 日志中有网络超时错误

**处理方案**:
1. **网络优化**:
   - 使用CDN加速
   - 优化网络路由
   - 启用HTTP/2或QUIC

2. **就近访问**:
   - 部署多地域实例
   - 智能DNS解析
   - 边缘计算

3. **压缩传输**:
   - 启用GZIP压缩
   - 优化数据传输格式
   - 减少传输数据量

## 紧急处理措施

### 立即操作（5分钟内）
1. **扩容**: 如果是资源不足，立即增加实例
2. **限流**: 保护系统不被压垮
3. **降级**: 关闭非核心功能
4. **重启**: 如果是内存泄漏等问题，重启受影响实例

### 短期措施（30分钟内）
1. **定位根因**: 通过日志分析找出慢的环节
2. **临时优化**: 
   - 增加缓存
   - 优化慢SQL
   - 调整超时时间
3. **监控观察**: 持续观察响应时间变化

### 长期优化
1. **性能优化**: 代码层面的性能优化
2. **架构优化**: 引入缓存、消息队列等
3. **监控完善**: 增加更细粒度的性能监控
4. **压力测试**: 定期进行性能压测

## 验证步骤
1. 确认P99响应时间降到正常水平（<1秒）
2. 检查错误率是否下降
3. 观察用户投诉是否减少
4. 持续监控30分钟确保稳定

## 性能优化检查清单
- [ ] 数据库查询是否有索引
- [ ] 是否有N+1查询问题
- [ ] 缓存策略是否合理
- [ ] 外部API调用是否有超时设置
- [ ] 是否有不必要的同步等待
- [ ] 日志级别是否过于详细
- [ ] 是否有大对象序列化
- [ ] 网络调用是否可以批量化

## 相关监控指标
- **响应时间**: P50, P90, P99, P999
- **吞吐量**: QPS, TPS
- **错误率**: 4xx, 5xx错误比例
- **资源使用**: CPU, 内存, 网络, 磁盘IO
- **数据库**: 慢查询数量, 连接池使用率
- **缓存**: 命中率, 失效率

## 相关告警
- `HighCPUUsage`: CPU使用率过高
- `HighMemoryUsage`: 内存使用率过高
- `DatabaseSlowQuery`: 数据库慢查询
- `HighErrorRate`: 错误率过高
- `ServiceTimeout`: 服务超时

## 联系方式
- **运维团队**: ops-team@company.com
- **开发团队**: dev-team@company.com
- **DBA团队**: dba-team@company.com
- **紧急电话**: 400-xxx-xxxx

## 参考文档
- [性能优化最佳实践](internal-docs/performance-optimization.md)
- [数据库优化指南](internal-docs/database-optimization.md)
- [缓存使用规范](internal-docs/cache-best-practices.md)