emergency-rescue

核心用法

Emergency Rescue Kit 是一套面向开发者的系统性灾难恢复指南，采用诊断→修复→验证的标准化流程。内容涵盖 Git 灾难（force-push、误删提交、错误分支合并）、凭证泄露应急处理（API 密钥、密码清理）、磁盘空间紧急清理、进程管理（僵尸进程、端口占用）、数据库故障恢复（迁移失败、表误删、死锁）、部署回滚、SSH 访问恢复及网络故障排查等 9 大紧急场景。每个场景提供具体的命令行操作示例，强调非破坏性操作优先，破坏性操作均带有明确警告标识。

显著优点

1. 流程标准化：严格遵循 diagnose→fix→verify 三段式流程，避免盲目操作导致二次损害。
2. 场景覆盖全面：从代码仓库到生产环境，从本地开发到云服务器，覆盖开发者 90% 以上的"事故现场"。
3. 安全设计：默认使用非破坏性命令（如 git reflog、truncate 而非 rm），危险操作（如 git push --force）均带 ⚠️ 警示。
4. 实用性强：提供具体可执行的命令，如凭证泄露时强调"先撤销密钥再清理历史"的关键顺序，避免用户陷入"清理了历史但密钥仍有效"的陷阱。
5. 验证机制完善：每个修复步骤后都提供验证命令，确保恢复成功而非虚假安心。

潜在缺点与局限性

1. 来源可信度有限：T3 级社区来源（个人账号维护），虽内容可审计但缺乏企业级背书。
2. 需人工判断执行：纯文档型工具，无法自动检测故障或执行修复，依赖用户准确判断场景并手动输入命令。
3. 操作不可逆风险：部分高级操作（如 git filter-repo 清理历史、docker system prune）一旦执行无法撤销，误操作代价高。
4. 环境差异：命令主要面向 Linux/macOS，Windows 环境部分命令需调整；特定数据库（PostgreSQL/MySQL）的恢复需额外依赖二进制日志或 WAL 配置。

适合的目标群体

• 后端开发者：处理 Git 历史重写、数据库迁移失败、凭证泄露等代码相关灾难。
• DevOps/运维工程师：应对磁盘爆满、SSL 证书过期、容器无法启动、SSH 锁死等基础设施故障。
• 全栈开发者：解决本地开发环境进程卡死、端口占用、网络诊断等日常紧急问题。
• 技术团队负责人：作为团队应急响应手册，统一故障处理流程，减少"救火"时的混乱。

使用风险

1. 命令误用风险：文档包含 kill -9、rm -rf、git push --force 等高危命令，未充分理解含义直接复制执行可能导致数据丢失或服务中断。
2. 凭证处理窗口期：凭证泄露场景中，文档强调"撤销优先于清理"，但用户若跳过顺序，可能在清理历史的几分钟内被自动化爬虫窃取密钥。
3. Docker 清理误伤：docker system prune -a 等命令会清除所有未使用镜像和卷，可能误删需要保留的构建缓存或数据卷。
4. 数据库操作风险：手动修改迁移表状态或直接操作生产数据库时，缺乏事务保护可能导致数据不一致，建议在执行前进行完整备份。
5. 依赖工具缺失：部分高级恢复（如 git-filter-repo、BFG、extundelete）需额外安装，紧急时刻若未预装可能延误恢复时机。