Kennethfeh/incident-response-automation

# 事件响应自动化 黑色星期五教会我们，即使是经验丰富的响应人员，当需要同时兼顾 PagerDuty、AWS 控制台、Runbook 和 Slack 时，也会陷入忙乱。我构建了这个自动化层来集中处理纷繁的信息，为值班工程师提供一个指挥中心。 ## 组件 - **Terraform** 负责部署 Lambda 修复器、与 PagerDuty Webhook 关联的 EventBridge 规则，以及 IAM 角色/权限。 - **Lambda 处理器** 检查事件负载，与 Auto Scaling 交互，并将详细更新发布回 Slack。 - **Runbook + ChatOps 记录** 记录人工步骤，确保自动化与手动操作保持同步。 - **模拟脚本** 让我们每周重现事件，而无需等待生产环境故障。 - **CI 流水线** 在每个 PR 上运行 pytest + Terraform plan，让响应人员对发布的代码充满信心。 ## 运作方式 1. PagerDuty 事件触发 → EventBridge 使用负载调用 Lambda。 2. Lambda 检查严重性 + 元数据。如果事件包含 ASG 标记，我们可以自动隔离该组。 3. Slack Bot 发布采取的操作、Runbook 片段，并提醒人员更新时间线。 4. 在复盘期间，我们使用 `scripts/simulate_event.sh` 重现事件，并确认自动化按预期执行。 5. 每周的混沌演练使用相同的工具，因此响应人员总是有备无患。 ## 成效 - MTTR（平均响应时间）从约 18 分钟降至约 6 分钟，因为响应人员不再需要在多个工具之间来回切换。 - 新工程师只需一次演练即可完成入职；每个命令 + 脚本都存在于源代码控制中。 - 合规团队很高兴，因为每一个自动化操作都像应用程序代码一样进行了版本控制和同行评审。 ## 试用 ``` python3 -m pytest -q lambda/tests cd terraform && terraform init -backend=false && terraform plan bash scripts/simulate_event.sh checkout "simulated latency spike" ``` 你需要 AWS 凭证和 Slack webhook 才能真正端到端地运行自动化，但代码和测试可以在本地运行。

标签：Auto Scaling, AWS Lambda, ChatOps, ECS, EventBridge, MTTR, PagerDuty, pytest, Python, Slack, SRE, Terraform, 二进制发布, 偏差过滤, 告警管理, 开源工具, 故障演练, 无后门, 混沌工程, 网络调试, 自动化, 运维开发, 运维自动化, 逆向工具