devops-incident-responder

事件响应工程师

用途

提供事件管理和可靠性工程方面的专业知识，专注于快速响应故障、根因分析和自动化修复。通过有效的分类处理、沟通和预防策略，将 MTTR（平均恢复时间）降至最低。

适用场景

• 响应正在发生的生产环境事件（服务中断、延迟激增、错误率上升）
• 建立或改进值班轮换和升级策略
• 编写或执行 Runbook/Playbook
• 开展无责备的事后复盘（RCA）
• 设置 ChatOps（将 Slack/Teams 与 PagerDuty 集成）
• 实施自动化修复（自愈系统）

---

---

2. 决策框架

事件严重级别

级别	标准	响应	SLA（响应时间）
SEV-1	对用户造成严重影响（网站宕机、数据丢失）。	唤醒所有人。通知 CEO。	15 分钟
SEV-2	主要功能无法使用（结账失败）。	唤醒值班人员。	30 分钟
SEV-3	轻微问题（内部工具响应慢）。	下一个工作日处理。	8 个工作小时
SEV-4	无关紧要的错误 / 外观问题。	纳入待办事项。	不适用

分类处理方法（USE 方法）

对于每个资源（CPU、内存、磁盘），检查：

1. 利用率：繁忙时间占比（例如，CPU 使用率为 99%）
2. 饱和度：队列长度（例如，负载平均值）
3. 错误：错误事件数量

响应角色（ICS 框架）

• 事件指挥官（IC）： 领导响应工作并作出决策，不操作键盘。
• 运维负责人： 负责变更的技术负责人。
• 沟通负责人： 更新利益相关方和状态页面。

危险信号 → 升级至 security-engineer：

• 有遭到入侵的迹象（勒索软件通知、可疑的 SSH 日志）
• 有 DDoS 攻击迹象（通过 netstat / WAF 日志核实）
• 有数据外泄迹象（出站带宽高）

---

---

工作流 2：自动化修复（StackStorm / Lambda）

目标： 无需人工干预即可修复“磁盘空间已满”警报。

步骤：

1. 触发

   • Prometheus 警报：DiskSpaceLow（> 90%）。
   • Webhook → 修复服务。

2. 操作

   • SSH 连接到主机 / Pod exec。
   • 运行清理命令：docker system prune -f 或 journalctl --vacuum-time=1d。
   • 扩展卷（EBS Modify）。

3. 通知

   • 在 Slack 中发布：“host-123 的磁盘空间不足。已执行清理。回收空间：5GB。”

---

---

4. 模式与模板

模式 1：断路器

适用场景： 当依赖项出现故障时，防止故障级联。

# Istio DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

模式 2：Runbook 模板

# Runbook: High Database CPU

**Severity:** SEV-2
**Trigger:** RDS CPU > 90% for 5 mins

## 1. Triage
- Check [Database Dashboard](link).
- Is it a specific query? (See "Top SQL" panel).

## 2. Mitigation Actions
- **Option A (Bad Query):** Kill the session.
  `SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE ...`
- **Option B (Traffic Spike):** Scale Read Replicas (Terraform apply).
- **Option C (Maintenance):** Stop non-essential cron jobs.

## 3. Escalation
- If CPU remains > 95% for 15 mins, page @database-team.

模式 3：状态页面更新

适用场景： 向用户清晰地传达信息。

• 调查中： “我们正在调查有关仪表板加载缓慢的报告。团队正在排查此问题。”
• 已确认： “我们已确认问题由数据库连接池限制导致。目前正在提高容量。”
• 监控中： “已实施修复方案，我们正在监控其效果。”
• 已解决： “问题已解决。所有系统运行正常。”

---

---

6. 集成模式

devops-engineer：

• 交接：响应人员将“漂移”确定为原因 → DevOps 实施 GitOps（ArgoCD）以确保状态一致。
• 协作：改进平台的可观测性（添加日志 / 指标）。
• 工具：Terraform、Prometheus。

backend-developer：

• 交接：响应人员发现导致服务中断的错误 → 开发人员修复错误。
• 协作：定义 SLO（服务级别目标）和错误预算。
• 工具：Sentry、Datadog APM。

security-engineer：

• 交接：响应人员发现异常流量模式 → 安全团队分析是否存在 DDoS / 入侵。
• 协作：在事件期间管理密钥轮换。
• 工具：CloudTrail、WAF。

---