核心用法
Emergency Rescue Kit 是一套面向开发者的灾难恢复手册，覆盖最常见的"oh no"时刻。所有场景遵循诊断→修复→验证三段式流程，命令默认为非破坏性，危险操作明确标注⚠️。
覆盖场景矩阵
| 类别 | 典型危机 | 关键恢复手段 |
|:---|:---|:---|
| **Git灾难** | force-push覆盖历史、rebase丢失提交、分支误操作、仓库损坏 | `git reflog`回溯、`git filter-repo`清洗历史、强制推送保护 `--force-with-lease` |
| **凭证泄露** | API key/密码提交到公开仓库、.env文件泄露、CI日志暴露 | **立即撤销凭证**→清洗历史→通知协作者重新克隆 |
| **磁盘爆满** | 系统/容器无法写入、Docker吞噬空间、日志膨胀 | `docker system prune -a`、日志truncate（非删除）、包管理器缓存清理 |
| **进程失控** | 端口冲突、僵尸进程、OOM killer、内存耗尽 | `lsof`定位占用、`kill -9`阶梯式终止、内存限制配置 |
| **数据库危机** | 迁移失败、误删表/库、死锁、连接池耗尽 | 框架回滚命令、事务包裹、PgBouncer连接池、锁查询终止 |
| **部署紧急** | 故障上线需回滚、容器无法启动、SSL证书过期 | git revert/Kubernetes rollback/ECS revision切换、certbot续期 |
| **访问封锁** | SSH锁定、sudo权限丢失 | 云厂商控制台逃生舱（Session Manager/串口）、单用户模式修复 |
显著优点
1. 时效性优先的安全设计 — 凭证泄露场景明确将"撤销密钥"置于清洗历史之前，对抗自动化爬虫的分钟级响应窗口
2. reflog为中心的Git恢复哲学 — 将git reflog定位为"30天内的万能撤销按钮"，降低心理门槛
3. 云原生逃生路径 — 每个访问封锁场景都列出AWS Session Manager、GCP浏览器SSH、Azure串口控制台等无SSH恢复通道
4. 破坏性操作的梯度防护 — --force-with-lease替代裸--force、truncate替代删除、事务包裹DDL操作
5. 一键诊断脚本 — 提供系统级健康检查的bash脚本，覆盖磁盘/内存/CPU/网络/服务状态，解决"不知道哪坏了"的茫然
潜在局限与风险
- 权限依赖：部分修复需要root/管理员权限或云控制台访问，纯开发者权限下某些场景（如网络层故障）无法独立解决
- 云厂商锁定：逃生舱口仅覆盖AWS/GCP/Azure/DigitalOcean，小众云或私有IDC需自行补充
- Docker核选项的模糊性：
docker system prune -a --volumes会删除所有未使用卷，可能误删有状态数据，文档标注⚠️但无二次确认机制 - 历史清洗的协作成本：
git filter-repo或BFG重写历史后，必须通知所有协作者重新克隆，文档强调但无自动化通知方案 - 数据库恢复的假设前提：时间点恢复(PITR)依赖预配置的WAL归档/binary log，未配置则方案降级为"从备份恢复"或无解
适合人群
- 全栈开发者：需要同时处理代码、基础设施、部署管道的独立开发者或小团队
- SRE/平台工程师：需要标准化应急响应手册的运维团队
- 技术Lead：需要向团队传授故障排查思维，而非仅提供命令复制
- 云服务用户：深度使用Docker/Kubernetes/主流云平台的现代应用开发者
常规风险
- 凭证泄露的窗口期悖论：即使立即撤销，泄露到撤销的几分钟内可能已被利用，文档建议撤销但未涵盖事后审计（如检查CloudTrail日志）
- 强制推送的连锁覆盖：
--force-with-lease防止并发冲突，但若多人同时force-push仍可能丢失中间状态 - Docker清理的生产误伤：开发机器安全的
prune -a在生产环境可能删除必要镜像，文档区分场景但依赖读者判断力 - sudo丢失的物理访问假设：单用户模式修复需要控制台/KVM访问，云实例通常无此能力，需依赖云厂商API
使用建议
将此skill视为保险单而非日常工具——安装后无需交互，但在force-push失误、凌晨3点证书过期、或误删生产表的时刻，按图索骥可节省数小时的恐慌搜索。建议团队共享此skill并演练关键场景（如凭证泄露响应流程）。