🚨

事件管理与响应

📂 devops ⏱ 2 min 237 words

事件管理与响应

事件管理流程

检测 → 分类 → 响应 → 恢复 → 复盘

事件分级

级别	影响	响应时间	升级路径
P0	核心业务不可用	5分钟	CTO
P1	核心功能受损	15分钟	VP Engineering
P2	非核心功能受损	1小时	Engineering Manager
P3	轻微影响	4小时	Team Lead

告警配置

# PagerDuty集成
groups:
  - name: critical
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Service {{ $labels.instance }} is down"
        pagerduty:
          service_key: xxx

---
# Slack集成
- alert: HighErrorRate
  expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "High error rate on {{ $labels.service }}"
    runbook_url: "https://wiki.example.com/runbooks/high-error-rate"

事件响应模板

# Incident Report

## 事件摘要
- **事件ID**: INC-2024-001
- **严重级别**: P1
- **开始时间**: 2024-01-01 12:00 UTC
- **结束时间**: 2024-01-01 14:30 UTC
- **持续时间**: 2.5小时
- **影响范围**: 所有用户无法登录

## 时间线
| 时间 | 事件 |
|------|------|
| 12:00 | 告警触发：登录服务不可用 |
| 12:05 | 值班工程师确认问题 |
| 12:10 | 升级为P1事件 |
| 12:15 | 开始调查 |
| 12:30 | 定位问题：数据库连接池耗尽 |
| 13:00 | 实施修复：增加连接池大小 |
| 13:30 | 服务恢复 |
| 14:30 | 确认完全恢复 |

## 根本原因
数据库连接池配置不当，在高并发时耗尽。

## 影响
- 用户影响：约10,000用户无法登录
- 数据影响：无数据丢失
- SLO影响：可用性从99.9%降至99.5%

## 改进措施
- [ ] 调整连接池配置
- [ ] 添加连接池监控告警
- [ ] 更新Runbook

Runbook模板

# Runbook: High Error Rate

## 描述
服务错误率超过5%，可能影响用户体验。

## 诊断步骤

### 1. 确认问题
```bash
# 查看错误率
curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~'5..'}[5m]))/sum(rate(http_requests_total[5m]))"

2. 检查服务状态

kubectl get pods -n production
kubectl logs -f deployment/myapp -n production

3. 检查依赖服务

kubectl get svc
curl -s http://api-service/health

修复步骤

如果是代码问题

回滚到上一版本

kubectl rollout undo deployment/myapp -n production

如果是基础设施问题

扩容

kubectl scale deployment/myapp --replicas=5 -n production

如果是依赖服务问题

联系依赖服务团队
启用熔断器


## 事后复盘

```markdown
# 事后复盘会议

## 参与者
- 事件指挥官
- 值班工程师
- 相关团队负责人
- SRE团队

## 议程
1. 事件回顾（15分钟）
2. 根本原因分析（30分钟）
3. 改进措施讨论（30分钟）
4. 行动项分配（15分钟）

## 输出
- 完整的事件报告
- 改进措施清单
- 负责人和截止日期

最佳实践

建立事件响应流程
定义清晰的职责
维护Runbook
定期演练
持续改进

总结

事件管理是运维的核心能力。通过建立完善的响应流程和复盘机制，可以快速恢复服务并持续改进系统可靠性。