4.0 KiB
4.0 KiB
title, tags, created
| title | tags | created | |||||
|---|---|---|---|---|---|---|---|
| Kill Switch (应急切断开关) |
|
2026-04-25 |
Kill Switch (应急切断开关)
Kill Switch（应急切断开关）是 Feature Flag 的一种紧急用法——在生产环境出现故障时，无需重新部署代码即可绕过或关闭故障组件的机制。Kill Switch 是 High Availability 的软件层保障。
Definition
Kill Switch 是部署在关键系统路径上的功能开关，用于在紧急情况下将流量切换到备用路径、备用组件或降级服务，从而实现秒级 RTO。
Core Use Cases
| 场景 | Kill Switch 动作 | RTO |
|---|---|---|
| 支付网关异常 | 切换到备用支付提供商 | 秒级 |
| 搜索结果异常 | 回退到旧搜索算法 | 秒级 |
| AI 模型产生幻觉 | 切换回上一版本模型 | 秒级 |
| 数据库迁移造成延迟 | 禁用新迁移相关功能 | 秒级 |
| 第三方 API 超时 | 切换到缓存数据或模拟响应 | 秒级 |
与传统回滚的对比
| 维度 | 传统部署回滚 | Kill Switch |
|---|---|---|
| 触发时间 | 分钟到小时 | 秒级 |
| 数据影响 | 可能丢失新事务数据 | 不触碰数据层 |
| 故障窗口 | 整个回滚期间用户受影响 | 切换完成后立即恢复 |
| 操作复杂度 | 需要 CI/CD 流程重新部署 | 配置变更，点击开关 |
| 适用范围 | 全局，影响所有用户 | 可定向（地区/用户群/设备） |
Kill Switch 的价值
"Instead of debugging under pressure while users suffer, you flip a switch and fix the problem properly later. Everybody wins."
传统方式：在压力下调试 → 用户持续受损 → 时间窗口内无法保证修复质量
Kill Switch 方式：立即止血 → 切换到安全状态 → 有时间从容分析问题根源
设计原则
1. 识别关键路径
- 支付流程
- 用户认证
- 核心数据写入
- 第三方依赖调用
2. 预设备用路径
- 备用支付提供商
- 旧版本算法
- 缓存数据
- 降级服务（Degraded Mode）
3. 可观测性优先
- Kill Switch 切换前需要明确知道发生了什么
- 监控指标、告警、日志必须到位
- 切换后需要持续监控备用路径的健康状态
4. 文档化
- 每个 Kill Switch 的触发条件需要事先定义
- 团队成员需要知道开关在哪里、如何使用
- 定期演练（Chaos Engineering）
Kill Switch 与 RTO/RPO
Kill Switch 直接影响 RTO 和 RPO：
- RTO：从小时级降至秒级（配置变更，不需要代码部署）
- RPO：保持近零（不触发数据回滚，不丢失新事务）
Kill Switch vs. Circuit Breaker
| 维度 | Kill Switch | Circuit Breaker |
|---|---|---|
| 触发方式 | 手动（人为决策） | 自动（基于错误率阈值） |
| 适用场景 | 已知故障、有预案 | 未知故障、无预期 |
| 灵活性 | 高（可指定备用路径） | 中（自动跳转到 fallback） |
| 协同需求 | 需要备用方案就绪 | 自动感知系统压力 |
实践建议
- 不要过度设计 Kill Switch：每个关键路径设计 1-2 个关键开关即可
- 开关命名要语义化：
kill_payment_v2而非flag_42 - 测试 Kill Switch：定期在非紧急情况下测试开关是否正常工作
- 监控开关状态：确保知道哪些开关处于开启/关闭状态
Related Concepts
- Feature Flag — Kill Switch 是 Feature Flag 的紧急用法
- RTO — Kill Switch 将 RTO 从小时降至秒级
- RPO — Kill Switch 保护 RPO（不丢失数据）
- High Availability — Kill Switch 是 HA 的软件层保障
- Disaster Recovery — Kill Switch 是现代灾备的重要工具
- Micro-Recovery — Kill Switch 实现 feature 级别的精准恢复