运行手册创建

概览

创建全面的运行手册，提供常见运维任务、事件响应和系统维护的逐步操作程序。

何时使用

事件响应程序
标准操作程序（SOPs）
值班手册
系统维护指南
灾难恢复程序
部署运行手册
升级程序
服务恢复指南

事件响应运行手册模板

# 事件响应运行手册

## 快速参考

**严重性级别：**
- P0（严重）：完全中断，数据丢失，安全漏洞
- P1（高）：主要功能故障，显著用户影响
- P2（中）：次要功能退化，有限用户影响
- P3（低）：外观问题，最小用户影响

**响应时间：**
- P0：立即（24/7）
- P1：15分钟（工作日），1小时（非工作时间）
- P2：工作日4小时
- P3：下一个工作日

**升级联系人：**
- 值班工程师：PagerDuty轮换
- 工程经理：+1-555-0100
- 副总裁工程：+1-555-0101
- CTO：+1-555-0102

## 目录

1. [服务中断](#服务中断)
2. [数据库问题](#数据库问题)
3. [高CPU/内存使用](#高CPU内存使用)
4. [API性能下降](#API性能下降)
5. [安全事件](#安全事件)
6. [数据丢失恢复](#数据丢失恢复)
7. [回滚程序](#回滚程序)

---

## 服务中断

### 症状
- 健康检查端点返回500错误
- 用户无法访问应用程序
- 负载均衡器显示所有实例不健康
- 警报：`service_down`, `health_check_failed`

### 严重性：P0（严重）

### 初始响应（5分钟）

1. **确认事件**
   ```bash
   # 在PagerDuty中确认
   # 在#incidents Slack频道发布

创建事件频道

创建Slack频道：#incident-YYYY-MM-DD-service-down
发布事件详情和状态更新

评估影响

# 检查服务状态
kubectl get pods -n production

# 检查最近的部署
kubectl rollout history deployment/api -n production

# 检查日志
kubectl logs -f deployment/api -n production --tail=100

调查步骤

检查应用健康

# 1. 检查Pod状态
kubectl get pods -n production -l app=api

# 预期输出：所有Pods运行中
# NAME                   READY   STATUS    RESTARTS   AGE
# api-7d8c9f5b6d-4xk2p   1/1     Running   0          2h
# api-7d8c9f5b6d-7nm8r   1/1     Running   0          2h

# 2. 检查Pod日志中的错误
kubectl logs -f deployment/api -n production --tail=100 | grep -i error

# 3. 检查应用端点
curl -v https://api.example.com/health
curl -v https://api.example.com/api/v1/status

# 4. 检查数据库连接
kubectl exec -it deployment/api -n production -- sh
psql $DATABASE_URL -c "SELECT 1"

检查基础设施

# 1. 检查负载均衡器
aws elb describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:... \
  --query 'TargetHealthDescriptions[*].[Target.Id,TargetHealth.State]' \
  --output table

# 2. 检查DNS解析
dig api.example.com
nslookup api.example.com

# 3. 检查SSL证书
echo | openssl s_client -connect api.example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# 4. 检查网络连接
kubectl exec -it deployment/api -n production -- \
  curl -v https://database.example.com:5432

检查数据库

# 1. 检查数据库连接
psql $DATABASE_URL -c "SELECT count(*) FROM pg_stat_activity"

# 2. 检查锁
psql $DATABASE_URL -c "
  SELECT pid, usename, pg_blocking_pids(pid) as blocked_by, query
  FROM pg_stat_activity
  WHERE cardinality(pg_blocking_pids(pid)) > 0
"

# 3. 检查数据库大小
psql $DATABASE_URL -c "
  SELECT pg_size_pretty(pg_database_size(current_database()))
"

# 4. 检查长时间运行的查询
psql $DATABASE_URL -c "
  SELECT pid, now() - query_start as duration, query
  FROM pg_stat_activity
  WHERE state = 'active'
  ORDER BY duration DESC
  LIMIT 10
"

解决方案

选项1：重启Pods（快速修复）

# 重启所有Pods（滚动重启）
kubectl rollout restart deployment/api -n production

# 观察重启进度
kubectl rollout status deployment/api -n production

# 验证Pods健康
kubectl get pods -n production -l app=api

选项2：扩展（如果过载）

# 检查当前副本
kubectl get deployment api -n production

# 扩展
kubectl scale deployment/api -n production --replicas=10

# 观察扩展
kubectl get pods -n production -l app=api -w

选项3：回滚（如果部署错误）

# 检查部署历史
kubectl rollout history deployment/api -n production

# 回滚到上一个版本
kubectl rollout undo deployment/api -n production

# 回滚到特定版本
kubectl rollout undo deployment/api -n production --to-revision=5

# 验证回滚
kubectl rollout status deployment/api -n production

选项4：数据库连接重置

# 如果数据库连接池耗尽
kubectl exec -it deployment/api -n production -- sh
kill -HUP 1  # 重新加载进程，重置连接

# 或重启数据库连接池
psql $DATABASE_URL -c "SELECT pg_terminate_backend(pid)
  FROM pg_stat_activity
  WHERE application_name = 'api'
  AND state = 'idle'"

验证

# 1. 检查健康端点
curl https://api.example.com/health
# 预期：{"status": "healthy"}

# 2. 检查API端点
curl https://api.example.com/api/v1/users
# 预期：有效的JSON响应

# 3. 检查指标
# 访问 https://grafana.example.com
# 验证：
# - 错误率 < 1%
# - 响应时间 < 500ms
# - 所有Pods健康

# 4. 检查日志中的错误
kubectl logs deployment/api -n production --tail=100 | grep -i error
# 预期：无新错误

沟通

初始更新（5分钟内）：

🚨 事件：服务中断

状态：调查中
严重性：P0
影响：所有用户无法访问应用程序
开始时间：2025-01-15 14:30 UTC

我们正在调查用户无法访问应用程序的报告。
我们的团队正在努力确定根本原因。

下一次更新在15分钟内。

进度更新（每15分钟）：

🔍 更新：服务中断

状态：已识别
根本原因：数据库连接池耗尽
行动：重启应用程序Pods
预计时间：5分钟

我们已经识别了问题，并正在实施修复。

解决更新：

✅ 解决：服务中断

状态：已解决
解决方案：重启应用程序Pods，重置数据库连接
持续时间：23分钟

服务现已完全运行。我们正在密切监控
并将进行事后分析，以防止未来发生。

事后

创建事后文档
- 事件时间线
- 根本原因分析
- 预防再次发生的行动项
更新监控
- 为此场景添加警报
- 提高检测时间
更新运行手册
- 记录任何新发现
- 添加快速解决方案的快捷方式

数据库问题

高连接数

症状：

数据库拒绝新连接
错误：“连接太多”
警报：db_connections_high

快速修复：

# 1. 检查连接数
psql $DATABASE_URL -c "
  SELECT count(*), application_name
  FROM pg_stat_activity
  GROUP BY application_name
"

# 2. 终止空闲连接
psql $DATABASE_URL -c "
  SELECT pg_terminate_backend(pid)
  FROM pg_stat_activity
  WHERE state = 'idle'
  AND query_start < now() - interval '10 minutes'
"

# 3. 重启连接池
kubectl rollout restart deployment/api -n production

慢查询

症状：

API响应时间 > 5秒
数据库CPU达到100%
警报：slow_query_detected

调查：

-- 查找慢查询
SELECT
  pid,
  now() - query_start as duration,
  query
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY duration DESC
LIMIT 10;

-- 检查缺失索引
SELECT
  schemaname,
  tablename,
  seq_scan,
  seq_tup_read,
  idx_scan
FROM pg_stat_user_tables
WHERE seq_scan > 0
ORDER BY seq_scan DESC
LIMIT 10;

-- 终止长时间运行的查询（如有必要）
SELECT pg_terminate_backend(12345);  -- 替换为实际PID

高CPU/内存使用

症状

Pods被OOMKilled
响应时间增加
警报：high_memory_usage, high_cpu_usage

调查

# 1. 检查Pod资源
kubectl top pods -n production

# 2. 检查资源限制
kubectl describe pod <pod-name> -n production | grep -A 5 Limits

# 3. 检查内存泄漏
kubectl logs deployment/api -n production | grep -i "out of memory"

# 4. 应用分析（如有必要）
kubectl exec -it <pod-name> -n production -- sh
# 运行分析器：node --inspect, py-spy等

解决方案

# 选项1：增加资源
kubectl set resources deployment/api -n production \
  --limits=cpu=2000m,memory=4Gi \
  --requests=cpu=1000m,memory=2Gi

# 选项2：水平扩展
kubectl scale deployment/api -n production --replicas=6

# 选项3：重启问题Pods
kubectl delete pod <pod-name> -n production

回滚程序

应用回滚

# 1. 列出部署历史
kubectl rollout history deployment/api -n production

# 2. 检查特定版本
kubectl rollout history deployment/api -n production --revision=5

# 3. 回滚到上一个
kubectl rollout undo deployment/api -n production

# 4. 回滚到特定版本
kubectl rollout undo deployment/api -n production --to-revision=5

# 5. 验证回滚
kubectl rollout status deployment/api -n production
kubectl get pods -n production

数据库回滚

# 1. 检查迁移状态
npm run db:migrate:status

# 2. 回滚上一次迁移
npm run db:migrate:undo

# 3. 回滚到特定迁移
npm run db:migrate:undo --to 20250115120000-migration-name

# 4. 验证数据库状态
psql $DATABASE_URL -c "\dt"

升级路径

一级 - 值班工程师（你）
- 初始响应和调查
- 尝试运行手册中的标准修复
二级 - 高级工程师
- 如果30分钟内未解决，则升级
- 如果问题复杂/不清晰，则升级
- 通过PagerDuty或Slack联系
三级 - 工程经理
- 如果1小时内未解决，则升级
- 如果需要跨团队协调，则升级
四级 - 副总裁工程/CTO
- 对于超过2小时的P0事件升级
- 对于安全漏洞升级
- 对于数据丢失升级

有用命令

# Kubernetes
kubectl get pods -n production
kubectl logs -f <pod-name> -n production
kubectl describe pod <pod-name> -n production
kubectl exec -it <pod-name> -n production -- sh
kubectl top pods -n production

# 数据库
psql $DATABASE_URL -c "SELECT version()"
psql $DATABASE_URL -c "SELECT * FROM pg_stat_activity"

# AWS
aws ecs list-tasks --cluster production
aws rds describe-db-instances
aws cloudwatch get-metric-statistics ...

# 监控URL
# Grafana: https://grafana.example.com
# Datadog: https://app.datadoghq.com
# PagerDuty: https://example.pagerduty.com
# 状态页面: https://status.example.com

最佳实践

✅ 做

在顶部包含快速参考部分
提供确切的运行命令
文档预期输出
包括验证步骤
添加沟通模板
明确定义严重性级别
文档升级路径
包括有用链接和联系人
保持运行手册最新
定期测试运行手册
包括屏幕截图/图表
文档常见陷阱

❌ 不做

使用模糊的指令
跳过验证步骤
忘记文档先决条件
假设工具知识
跳过沟通指南
忘记在事件后更新